Останні два роки я ставлю в продакшен 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 — повна поверхня агента, де всі проблеми з цієї статті випливають одразу.
