Промптинг — це вже базовий навик, а не конкурентна перевага. Що далі

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт! Мене звати Артем. Я VP of Software Architecture та Platform Engineer у Techstack, і останні роки більша частина моєї роботи — інтеграція AI-інструментів у реальні інженерні процеси: Claude Code, Cursor, MCP-інтеграції, агентні пайплайни. У квітні ми провели вебінар «Next Gen AI: чому простого промптингу вже недостатньо» з live демо мультиагентної системи в дії, у цій статті — основні тези.

57% організацій мають AI-агентів у продакшені

За даними LangChain State of AI Agents Survey 2026, більше половини організацій вже запустили AI-агентів у продакшн. Ринок агентів зараз оцінюється в $7.84 млрд і росте з CAGR 46% — до $52 млрд до 2030 року (MarketsandMarkets). Gartner прогнозує, що до кінця 2026 40% корпоративних додатків матимуть task-specific AI-агентів, хоча на початку 2025 їх було менше 5%.

Ці цифри підкріплені конкретними кейсами. Klarna зекономила $60 млн на підтримці клієнтів. Amazon мігрував 50 тисяч Java-систем — процес, який раніше займав 50 днів, тепер займає кілька годин. GitHub Copilot перетнув 20 млн користувачів і давно вже не просто автодоповнення — це повноцінний agent mode.

Вміти писати промпти в цьому контексті — це приблизно як вміти писати SQL-запити. Необхідна база, але не те, що дає перевагу.

Еволюція: від мистецтва запитувати до системної інженерії

У 2022 Prompt Engineering був революційним. Правильно сформулював — отримав хорошу відповідь.

У 2023 з’явились RAG і Function Calling. Модель отримала доступ до зовнішніх даних і здатність викликати функції. Перший крок від «розумного генератора тексту» до «системи, що може діяти».

2024: Workflows. Замість одного виклику моделі — ланцюжки викликів, оркестровані через код. Prompt chaining, routing, паралелізація.

2025–2026: Agent Engineering. Системи, які самостійно міркують, планують, обирають інструменти і коригують підхід.

Ключовий зсув: це дисципліна системної інженерії, а не промптування. Ми проєктуємо системи, а не формулюємо запити.

Workflows vs Agents і чому складність має бути виправдана

Anthropic у гайді «Building Effective Agents» розмежовує два підходи.

Workflows — LLM оркестровані через заздалегідь визначені шляхи в коді. Шлях передбачений, детермінований. Як CI/CD пайплайн: кроки визначені заздалегідь.

Agents — LLM динамічно керує власним процесом. Сам вирішує, які інструменти використати, в якому порядку, скільки ітерацій зробити.

Принцип, який варто тримати в голові: починайте з простих промптів, додавайте агентні системи лише тоді, коли простіші рішення не справляються. Мультиагентна оркестрація для задачі, яку вирішує один промпт із Function Calling — це архітектурний надлишок.

Три патерни, перевірені в роботі: Prompt Chaining (послідовні виклики з верифікацією кожного кроку), Tool Use (динамічний виклик API через function calling) і ReAct (reasoning + acting у циклі). Reflection, мультиагентна оркестрація і Plan-and-Execute готові до продакшену, але ще формуються. Повністю автономні агенти з довгим горизонтом — поки що експериментальна зона. Головна проблема це накопичення помилок: за 10 кроків з error rate 5% ймовірність коректного результату вже 60%, за 20 — 36%.

Context Engineering важливіше за промптинг

Prompt Engineering — це як написати правильний лист колезі. Context Engineering — це перед тим, як він вийде на роботу, підготувати йому стіл, розкласти потрібні документи, налаштувати доступи і показати де лежать довідники.

Контекст агента складається з: system prompt (хто він і як поводитися), доступних інструментів, пам’яті (коротко- і довгострокової), документів із RAG, історії розмови і схем структурованого виводу.

Агент із сильним промптом, але поганим контекстом, провалиться. Агент із нормальним промптом, але відмінним контекстом, працюватиме добре.

Якщо ви робили CLAUDE.md у проєкті з описом архітектури, конвенцій і поведінки агента — ви вже займались context engineering. Якість description кожного tool в MCP-сервері — теж context engineering. Це не нова концепція, це назва для того, що досвідчені люди робили інтуїтивно.

MCP: один сервер — всі клієнти

Без MCP кожен AI-інструмент потребував окрему інтеграцію з кожним сервісом. N клієнтів × M сервісів = N×M інтеграцій. З MCP: кожен сервіс пише один сервер — і він працює з усіма AI-клієнтами. N + M замість N×M.

Anthropic представив MCP у листопаді 2024. У грудні 2025 протокол передали до Linux Foundation, співзасновниками стали Anthropic, Block і OpenAI, підтримку дали Google, Microsoft, AWS, Cloudflare. Зараз: більше 10 тисяч публічних серверів, 97 млн щомісячних завантажень SDK. Впроваджено в ChatGPT, Claude, Gemini, Microsoft Copilot, VS Code, Cursor.

Паралельно Google у квітні 2025 представив A2A (Agent-to-Agent Protocol) для комунікації між агентами, і теж передав до Linux Foundation у червні. Якщо MCP це вертикаль (агент + інструменти), то A2A це горизонталь (агент + агент). Обидва на JSON-RPC 2.0, обидва під Linux Foundation. Це стандартний стек мультиагентних систем 2026.

Практична порада: вчіть MCP зараз. A2A тримайте в полі зору. Перший MCP-сервер можна зробити за вихідні: Python або TypeScript, 100–200 рядків.

Human-in-the-Loop: чому 40% проєктів скасують

Gartner прогнозує, що більше 40% проєктів agentic AI буде скасовано до кінця 2027 року — через ескалацію витрат, незрозумілу бізнес-цінність і неадекватний контроль ризиків. Cisco опитав 8 тисяч senior IT-лідерів: 83% планують впроваджувати agentic AI, але лише 29% вважають безпеку пріоритетом.

Це класична помилка при впровадженні: компанія бачить демо, дає агенту повний доступ до продакшн-середовища без approve-гейтів і логування. Дослідниця безпеки з Meta виявила, що її агент автономно видалив всю поштову скриньку, проігнорувавши інструкцію «підтверджуй перед дією». Їй довелося фізично вимикати машину.

Рішення — не забороняти агентам діяти. Рішенням є градація контролю за принципом deny → ask → allow.

Читання автоматично. Дії з побічними ефектами (видалення файлів, відправка email, зміна конфігурації) тільки після підтвердження. У Claude Code це реалізовано через ієрархію правил із glob-pattern matching, яка каскадується від глобальних до проєктних. У версії 2.0 додались Hooks — shell-скрипти, що виконуються до і після кожного tool call: логування в SIEM, перевірка git diff перед комітом, Slack-сповіщення при видаленні файлів.

Правильна прогресія розгортання: Copilot (агент пропонує, людина виконує) → Guarded Automation (агент виконує з воротами підтвердження) → Supervised Autonomy (агент самостійний у чітких межах) → повна автономія тільки для ізольованих середовищ. Довіру до агента будують так само, як до нового інженера в команді: спочатку код-рев’ю, потім автономія.

Шість антипатернів, які я бачу постійно

Надмірна автономія без контрольних точок. Агент отримує повний доступ до продакшн-середовища без approve-гейтів і deny-правил. Результат передбачуваний.

«Жирні» промпти замість архітектури. Промпт на 3000 слів, де ви текстом намагаєтесь передбачити кожен edge case. Якщо system prompt більше однієї сторінки — потрібна не краща інструкція, а краща архітектура. Розбийте на спеціалізованих агентів, використайте routing, винесіть знання в RAG.

Детермінований підхід до стохастичної системи. LLM дає різні результати на той самий промпт. Якщо пайплайн ламається від неочікуваного формату відповіді — це проблема дизайну. Structured output, retry з fallback, валідація на кожному кроці.

Поганий дизайн циклів. Anthropic сформулював точно: «Більшість збоїв агентів — це збої дизайну циклу, а не моделі.» Без умов виходу і метрик прогресу агент або зависає, або зупиняється занадто рано. Якщо за три ітерації немає руху — ескалюй до людини.

Prompt injection без захисту. Вразливість № 1 за OWASP Top 10 for LLM Applications. Email із прихованою інструкцією, яку агент виконує як системну команду — реальний вектор атаки. Розділяйте інструкції від даних, використовуйте guardrails та input sanitization.

Lethal Trifecta (концепція Саймона Вілісона): доступ до приватних даних + доступ до зовнішніх інструментів + обробка ненадійного вхідного контенту. Якщо агент має всі три — мінімізуйте перетин або ставте HITL на кожну дію з побічним ефектом.

З чого почати інженеру, якщо хочеш будувати агентні системи

Фундамент: Python або TypeScript, async programming, базове розуміння теорії графів, більшість оркестраторів побудовані на графах.

AI-специфічні навички: Context Engineering, Agentic RAG (RAG як частина агентного циклу, а не окремий пошук), Tool Design (naming, descriptions, параметри так, щоб агент міг ефективно використати інструмент), Evaluation Design — класичний unit test тут не підходить.

Фреймворки: LangGraph 1.0 — продакшн-стандарт, починайте з нього. CrewAI — для прототипування. OpenAI Agents SDK — якщо хочете бути ближче до металу.

Перший крок: одна реальна задача з вашого робочого процесу. Не «побудуємо мультиагентну систему», а «агент, що перевіряє PR на типові помилки» або «агент, що аналізує логи і створює тікети». Один агент, два-три інструменти, ReAct-патерн, human-in-the-loop. Запустіть, поміряйте, ітеруйте. Складність додасте потім.

Різниця між «написати хороший промпт» і «побудувати агентну систему» це різниця між написати SQL-запит і спроєктувати схему бази даних. Обидва вміння потрібні, але саме друге визначає, що взагалі стане можливим.

Якщо хочеш побачити, як це виглядає в дії, то на вебінарі ми показували live демо мультиагентного пайплайну, який будує презентацію з нуля. Запис тут.

Ресурси:

• Anthropic «Building Effective Agents»: www.anthropic.com/...​building-effective-agents
• LangGraph: langchain-ai.github.io/langgraph
• MCP специфікація: modelcontextprotocol.io
• Antonio Gulli «Agentic Design Patterns», Springer, 2025