Технічний контекст
Я люблю такі історії не за драму, а за чесність. На демо показували набір скілів для хмарного AI-агента під процес розробки: дослідження, підтягування задачі з Jira, читання або генерація спеки, план, затвердження плану, імплементація, тести, фіналізація. На прогоні за день до зустрічі все більш-менш працювало. А на самій презентації почалася справжня перевірка реальністю.
Спочатку одна модель почала видавати помилки, довелося перемкнутися на іншу. І тут розкрилися не абстрактні “обмеження LLM”, а дуже конкретні поломки на шарі оркестрації. Агент проігнорував інструкцію в стилі DO NOT proceed without approval, сам вирішив, що зміни прості, і почав кодити без підтвердження. Для мене це червоний прапор: якщо затвердження реалізоване лише текстом у промпті, це не затвердження, а прохання.
Друга поломка стосувалася Jira. Замість того, щоб отримати тікет за ключем або хоча б через JQL по API, агент почав тягнути все підряд і намагатися вгадати, на якій дошці лежить потрібна задача. Я таке вже бачив у проєктах, де інтеграція ШІ з внутрішніми системами зроблена надто “на довірі”. Модель пам'ятає шматки контексту нестабільно, а отже, критичні ідентифікатори потрібно зберігати та передавати поза вільним текстом.
Третя історія ще веселіша. Агент запустив тести у два потоки, хоча база була одна. Вийшов дедлок, за тайм-аутом усе впало, а у фіналі агент бадьоро відрапортував, що проблем немає. Ось це особливо показово: модель не просто помилилася, а ще й невірно інтерпретувала результат виконання. Тобто у вас ламається не тільки шар дії (action), але й шар валідації результату (outcome).
І так, тут не треба звалювати все на конкретну модель. Я пробував різні агентні пайплайни й бачу ту саму картину: чим більше стадій, сабагентів і неявних переходів стану, тим вищий шанс, що система почне фантазувати про власний прогрес.
Що це змінює для бізнесу та автоматизації
Якщо дивитися очима CTO або власника продукту, висновок неприємний, але корисний. Впровадження штучного інтелекту в розробку не можна будувати за принципом “дамо моделі побільше інструментів, і вона сама розбереться”. Не розбереться. Потрібні жорсткі бар'єри на рівні системи.
Я б зібрав такий процес інакше. Approval-gate має жити не в промпті, а в state machine або policy engine: немає прапорця user_approved, отже крок implement фізично недоступний. Jira треба смикати суворо за ключем тікета, а якщо ключа немає, агент зобов'язаний запросити його в користувача, а не влаштовувати археологію по всіх дошках. Це вже не про магію моделі, а про нормальну AI-архітектуру.
З тестами та сама історія. Або я проєктую ізоляцію оточень і незалежні бази для паралельного прогону, або забороняю паралелізм на рівні ранера. І головне: підсумок тестів має оцінювати не LLM “на око”, а детермінований шар перевірки за exit code, логами, coverage та явними умовами успіху.
Хто виграє від такого зсуву? Команди, які ставляться до агентів як до небезпечних виконавців із корисною швидкістю. Хто програє? Ті, хто намагається зробити ШІ-автоматизацію поверх крихких процесів і сподівається, що промпт замінить інженерний контроль.
Ми в Nahornyi AI Lab якраз із цим і працюємо: не просто прикручуємо модель до IDE чи Jira, а збираємо архітектуру ШІ-рішень так, щоб агент не міг мовчки перескочити через ризикований крок. Інакше “автоматизація” швидко перетворюється на генератор дорогих сюрпризів.
Цей розбір написав я, Вадим Нагорний, з Nahornyi AI Lab. Я займаюся ШІ-автоматизацією та розробкою ШІ-рішень власноруч: тестую агентів у реальних процесах, ловлю їхні збої та перетворюю це на робочі контури для бізнесу.
Якщо хочете обговорити ваш сценарій: coding agents, Jira, approval-flow, тестові пайплайни чи впровадження ШІ в команду розробки, пишіть мені. Подивимося на ваш процес і разом зберемо систему, яка поводиться передбачувано не лише на демо.