Последние два года я ставлю в продакшен AI-фичи в двух разных кодовых базах — одна на .NET, другая на TypeScript — и параллельно учу этому инженеров. Где-то на восемнадцатом месяце то, чем я занимаюсь каждый день, перестало быть похожим на prompt engineering и стало чем-то другим.
Это заметили и другие. «Context engineering» уже больше года тихо вытесняет «prompt engineering» в серьёзных разговорах про AI-инженерию, а в 2026 это уже мета-тема всей отрасли. Это тот пост, который я хотел бы прочитать в свой первый день. Не туториал — фрейм.
Тезис простой. Prompt engineering всегда был неудачным названием. Работа никогда не сводилась к подбору красивых слов. Она сводилась к решению: что именно модель увидит, когда запустится — и чего она не увидит. Это задача системного дизайна. И только этот навык масштабируется, когда вы переходите от демо к продукту.
Почему «prompt engineering» — неверное название
Промпт — это одна переменная в очень длинном выражении.
Когда настоящая продакшен-фича дёргает модель, на вход идёт сообщение пользователя — да. Но ещё системный промпт, схемы всех инструментов, кусок истории диалога, свежеподнятый набор документов, суммаризации старых ходов, профиль пользователя, текущее состояние задачи, возможно вывод планировщика, отработавшего две секунды назад, и набор ограничений, которые юристы записали в markdown три месяца назад. Реальная фраза пользователя — это процентов пять от того, что читает модель.
Остальные девяносто пять — это то, что определяет, работает фича или нет.
Называть это prompt engineering — всё равно что называть язык SQL «форматированием строк». Это просто мимо проблемы. Интересные вопросы не «как лучше сформулировать?». Они — «что должно быть в этом окне? что не должно? откуда оно берётся? когда устаревает? сколько я могу себе позволить?»
Это инженерные вопросы. У них теперь есть имя: context engineering.
Что такое контекст на самом деле
Полезный фрейм: контекст — это не одна вещь. Это минимум пять разных слоёв, и у каждого свой режим отказа, если вы его сломаете.
| Слой | Что это | Что ломается, если ошибиться |
|---|---|---|
| Система и роль | Постоянная идентичность, роль и ограничения модели | Модель «плывёт», игнорирует правила под давлением, идёт за пользователем сквозь ваши защитные рельсы |
| Инструменты | Функции, которые модель может вызвать, их схемы и описания | Срабатывает не тот инструмент, бесконечные циклы, инъекции в схему, дыры безопасности |
| Подгруженные знания | Документы, чанки, факты, поднятые под запрос (RAG) | Устаревшие ответы, уверенные галлюцинации, латентность, скачки стоимости |
| История диалога/агента | Что уже было сказано, что уже было сделано, что было решено | Потерянное состояние, повторная работа, противоречия, газлайтинг |
| Состояние задачи и пользователя | Текущая цель, данные пользователя, окружение, в котором модель действует | Общие ответы, отсутствие персонализации, пропущенный очевидный контекст |
Когда что-то ломается в продакшен-AI-фиче, ломается это почти никогда не потому, что промпт плохо сформулирован. Ломается потому, что один из этих пяти слоёв протёк, устарел, отсутствовал или был слишком большим. Инженеры, которые не умеют сказать какой слой отвалился, — это инженеры, которые всё ещё называют себя prompt engineers.
Четыре сложные задачи контекст-инжиниринга
Дисциплина сводится к четырём задачам, которые всплывают в любой нетривиальной AI-фиче. Ни одну из них не решить более красивым промптом. Все четыре — задачи системной инженерии.
Выбор: что попадает внутрь?
Окно контекста конечно. Даже на моделях с двумястами тысячами токенов нельзя засовывать туда весь свой корпус — не потому, что не влезет, а потому что внимание модели размазывается по нерелевантному, а ваш счёт уходит вертикально вверх.
Выбор — это retrieval-инжиниринг. Гибрид BM25 и плотных эмбеддингов, reranking, переписывание запроса, бусты по свежести, дедупликация, веса источников. Выбрать правильные восемь тысяч токенов из двухсоттысячного корпуса сложнее, чем выбрать правильный индекс под SQL-запрос, и ошибки тут гораздо изощрённее.
Команды, у которых AI-фичи стабильно работают, относятся к retrieval как к самостоятельной подсистеме со своими метриками, evals и дежурствами. У остальных это «как-нибудь», и потом они удивляются, почему качество ответов тихо деградирует.
Сжатие: как уместить больше без потери смысла
Длинные прогоны агента накапливают контекст быстрее, чем окно может вместить. Наивный ответ — обрезать. Взрослый ответ — суммаризировать, и рекурсивно, на структурированных чекпойнтах.
Звучит просто. Это не просто. Каждый шаг суммаризации лоссовый, и потери копятся. Решение «что стоит сохранить в саммари» — это ровно то решение, которое модель плохо принимает без присмотра. Ошибётесь — и агент в середине задачи забывает ограничение, которое получил пять минут назад.
Форма, которая работает на практике: структурированное состояние — факты, решения, открытые вопросы, текущая цель — которое пишет и обновляет сам агент, но по схеме, которую контролируете вы. Свободные саммари деградируют. Структурированное состояние выживает.
Маршрутизация: какой контекст какому шагу
Многошаговым агентам не нужен один и тот же контекст на каждом шаге. Шагу планирования нужна полная цель и доступные возможности; шагу исполнения инструмента нужен только срез, релевантный этому вызову; шагу синтеза — трасса планировщика и выводы инструментов.
Если на каждом шаге вы скармливаете объединение всего, вы платите за это в токенах, латентности и качестве. Модели теряют остроту в длинных недифференцированных окнах. Они сосредотачиваются в сфокусированных.
Маршрутизация контекста по шагам гораздо больше похожа на системный дизайн, чем на prompt design. Вы решаете, какая подсистема какой видит срез состояния. Это архитектурная задача.
Эвикция: что выкинуть и когда
Забывание — это фича. Сложно не запомнить, а решить, что безопасно забыть.
На практике вы приходите к ярусной памяти: горячий контекст в окне прямо сейчас, тёплый — суммаризованный и доставаемый по запросу, холодный — заархивирован, поднимается только при прямой ссылке. С выводами инструментов то же самое — полный вывод сразу следующим ходом, дайджест на следующем ходу, через три хода — «инструмент X был вызван в момент T с результатом формы Y».
Это та часть, которую большинство команд пропускают, пока один прогон агента не начинает стоить тридцать центов и занимать полторы минуты.
Ментальная модель: контекст как артефакт сборки
Вот сдвиг, который меняет то, как сеньорные инженеры думают об этом.
Перестаньте думать о промпте как о строке, которую вы пишете. Начните думать о контексте как об артефакте сборки, который ваш рантайм производит каждый ход из множества источников:
[ввод пользователя]
[саммари диалога] ──┐
[поднятые документы] │
[схемы инструментов] ├──► context assembler ──► модель
[системные правила] │
[состояние задачи] │
[свежие выводы tool] ──┘Context assembler — это софт, которым владеете вы. У него есть входы, трансформации, кеширование, наблюдаемость и тесты. Это самая важная компонента вашей AI-фичи, и в большинстве команд за неё формально никто не отвечает.
Промпт — это последний один процент конвейера, который на девяносто девять процентов состоит из системной инженерии.
Как только вы это увидите, остальное падает на свои места. Вы версионируете ассемблер. Вы пишете под него evals. Профилируете токены на выходе. Пишете интеграционные тесты, которые фиксируют конкретные формы контекста. Инструментируете каждый слой, чтобы когда качество деградирует, было видно, какой слой изменился. Ничего экзотического — обычная инженерия, применённая к тому слою, на котором prompt engineers и стояли, не замечая его.
Пять правил, которые я выучил в продакшене
Пронумерованы, потому что заслужены, а не выведены.
1. Относитесь к окну контекста как к иерархии памяти. Hot — то, что в окне сейчас. Warm — суммаризованное и доставаемое. Cold — заархивированное. Перемещайте между ярусами сознательно — по релевантности, возрасту, стоимости, — а не случайно. Большинство багов контекста — это замаскированные баги управления ярусами.
2. Мерьте токены так же, как мерите латентность. Токены теперь — несущая метрика производительности. У каждой фичи должен быть токен-бюджет на ход, на сессию, на пользователя-в-день. Без наблюдаемости тут стоимость и латентность ползут монотонно вверх, и вы узнаёте об этом от финансов, а не от инженеров.
3. Никогда не доверяйте модели управление собственным состоянием. Модели уверенно скажут, что помнят то, чего не помнят, и тихо отбросят ограничения, выданные пятнадцать ходов назад. Управление состоянием — это ваша работа. Модель исполняет, а не ведёт учёт.
4. Разделяйте контекст планирования и контекст исполнения. Планировщик видит цель и набор инструментов. Исполнитель видит текущую подцель и релевантный срез. Синтезатор видит трассу и выводы. Смешивание этих трёх в одно окно — самая частая причина регрессий качества, которую я видел в агентских системах.
5. Evals — на пайплайн, а не на промпт. Если ваш evaluation harness A/B-тестит только формулировки промпта, вы оптимизируете последний один процент. Стройте evals, которые варьируют recall ретривера, точность суммаризации, форму вывода инструментов и глубину истории. Вся реальная дисперсия качества — там.
Где prompt engineering всё ещё важен
Честный нюанс, потому что контр-фрейм — это фрейм, а не вся правда.
Формулировка на уровне промпта по-прежнему доминирует в:
- Одношаговая классификация и извлечение. Короткое, без инструментов, без истории, без поиска. Формулировка — переменная. Относитесь к этому случаю как к частному, каким он и является.
- Структурированный вывод с тугими схемами. Маршрутизация function-call, JSON-mode coercion, принуждение по схеме. Здесь слова двигают стрелку так, как контекст не двигает.
- Тон, персона и отказы. Тон — это в основном забота промпта. Отказы — забота промпт+система. Персона — почти полностью промпт-форма.
Но всё агентское, всё с поиском, всё многошаговое, всё с состоянием между ходами — контекст-инжиниринг выигрывает. А в 2026 это покрывает большую часть того, как продакшен-AI выглядит на самом деле.
Что это значит для вашей карьеры в 2026
Если вы middle-инженер, делающий AI-фичи, и хотите знать, во что инвестировать дальше, — вот короткая версия.
Описание вакансии сеньор-AI-инженера в 2026 — это не «prompt engineer». Это «context engineer». Скиллы, которые накапливаются: дизайн ретривера, evaluation harnesses, наблюдаемость токеномики, оркестрация агентов, дизайн схем для tool-call, стратегия суммаризации и дисциплина относиться к окну контекста как к управляемой среде, а не как к списку желаний.
Скиллы, которые тихо обесцениваются: умные заклинания в промптах, библиотеки prompt-шаблонов как продукт, фреймворки «prompt patterns» и предположение, что лучшие формулировки вытащат недоинженеренный пайплайн. Ничто из этого не бесполезно. Просто всё это сильно меньше, чем было два года назад.
80/20, если вы не прочтёте ничего больше: возьмите одну продакшен-AI-фичу, которую вы ведёте. Нарисуйте её контекстный пайплайн на доске от начала до конца — все источники, все трансформации, все ярусы. Инструментируйте токен-стоимость каждого слоя. Соберите eval-набор из пяти кейсов, который варьирует по одному слою за раз. За неделю вы обнаружите, что то, что выглядело как промпт-проблема, было проблемой ретривера, или управления состоянием, или маршрутизации. Это открытие и есть весь навык.
Более глубокая мысль
Сдвиг от prompt engineering к context engineering — это тот же сдвиг, который произошёл, когда «веб-программирование» стало «системным дизайном», а «написание SQL» стало «дата-инжинирингом». Интересная работа ушла с поверхности — со слов, запросов и строк — в пайплайн под ними.
Design-time-двойник этой дисциплины — spec-driven development: то, как команды на самом деле производят входы, которые потом гонят эти контекстные пайплайны. Это следующий пост.
Если хотите глубже, в курсах ниже — те части дисциплины, которые я преподаю чаще всего: Prompt Engineering & AI Workflow Automation для фундамента уровня промптов, Building LLM-Powered Apps: RAG & Agents для ретривера и многошаговой оркестрации, Building with Claude API: Production AI Apps для рантайм-стороны, и Building Agents with the Claude Agent SDK — полная поверхность агента, где все проблемы из этой статьи всплывают сразу.
