Агентна інженерія дорослішає: від «попроси агента написати код» ми переходимо до фабрик — конвеєрів, де команда AI-агентів проводить проєкт повним циклом: вимоги → специфікації → тести → імплементація → адверсарне рев'ю → докази якості. У доповіді розберемо, з чого така фабрика складається насправді: оркестратор і спеціалізовані субагенти, детерміновані quality gates, ланцюг трасування від вимоги до тесту, петлі верифікації замість «здається, працює». Головний виклик автономної розробки — не змусити агентів писати код, а не дати фабриці впевнено рапортувати успіх там, де його немає. Розберемо типові механізми самообману конвеєра: «м'які» правила в промптах, що зникають під тиском реального проєкту; перевірки, які тихо пропускають відсутні докази; вимоги, чий метод приймання ніколи не існував у вигляді коду. Ілюструватиму живим матеріалом — зокрема кейсом, де фабрика пройшла всі гейти «на зелено» й видала продукт, що не відповідав ключовій вимозі, і тим, що знадобилося, аби той самий прогін став чесно червоним. Окрема частина — про самовдосконалення: як побудувати цикл, у якому кожен виявлений провал стає новим гейтом, який наступний проєкт вже не зможе оминути. Три-значна семантика перевірок (PASS / NOT-EARNED / FAIL), реєстр процес-дефектів, бібліотека «уроків», що успадковується кожним новим проєктом. Все — на реальних артефактах: коміти, метрики, вимірювані результати. Про що поговоримо: Анатомія agentic-фабрики: оркестратор, субагенти, детерміновані гейти, ланцюг трасування Механізми самообману конвеєра — і форензика реального «фальшивого done» Maker ≠ checker на практиці: адверсарне рев'ю, яке реально ловить дефекти Цикл самовдосконалення: correction → retro → новий гейт → урок для наступного проєкту Скільки це коштує: про токени, час і де фабрика (поки) програє людині Кому буде корисно: інженерам і тимлідам, які вже використовують AI-агентів у розробці й хочуть перейти від «іноді спрацьовує» до передбачуваного конвеєра з доказами якості.

Розробка AI зараз впливає на всіх — тож давайте зануримось у неї разом. Усі хочуть, щоб AI-агенти замінили звичні інтерфейси. У цій доповіді я розповім про еволюцію нашого мультиінструментального AI-агента, створеного на Node.js поверх Google Vertex AI. Я поділюся нашим шляхом вибору правильних моделей та масштабування розробки за допомогою CI/CD, TDD і моніторингу продуктивності. Але виникає питання: чи взагалі можливо досягти стабільних результатів у AI-проєктах, де моделі можуть галюцинувати та повертати різні відповіді? Цікаво, що з часом ми вирішили відмовитися від MCP-серверів і валідації схем через Zod — технологій, які часто вважають «стандартом» для таких задач. Хочете дізнатися, чому ми відійшли від них? Приходьте на мою доповідь, щоб отримати ці інсайти та поставити свої запитання наживо.

Готові зруйнувати стіни між девелоперами та DevOps і прибрати із себе частину роботи? В своєму quick talk хочу поділитись своїм досвідом про те, як ми покращили співпрацю між командами та яку частину роботи можна і навіть корисно передавати девелоперам.

We’ll code dive on one of our products to learn how we added AI to it.