Технічний контекст
Я зачепився не за черговий фреймворк, а за дуже приземлений робочий патерн: write spec - plan - subagent-driven development. Суть проста і, чесно, болісно знайома. Якщо кодогенерація пішла шкереберть, рятує не новий промпт, а жива спека, яку можна відкрити та перезібрати рішення майже з нуля.
У цьому кейсі фігурує change_spec.md як опорний файл, що живе поруч із кодом. Не документ для галочки, а джерело істини: що змінюємо, які обмеження, що вважаємо успішним результатом. Коли кодова база «забруднилася» або агенти почали тягнути рішення не туди, я можу повернутися до специфікації та перегенерувати гілку без ворожіння на кавовій гущі.
Особливо сподобалася оцінка часу: на велике завдання йде 2-3 дні на спеку і всього 0.5-1 день на генерацію коду. Тобто 70-80% зусиль з'їдає не програмування, а формалізація задачі. Звучить майже образливо, доки сам не впрешся в мультиагентну систему, яка ідеально швидко робить не те.
Технічно це дуже схоже на нормальну ієрархію. Один агент або людина формує spec через brainstorming, далі планувальник ріже її на кроки, потім субагенти беруть вузькі шматки: backend, frontend, тести, валідацію. Такий підхід я вважаю дорослішим, ніж спроба запхати весь проєкт в один довгий контекст і сподіватися, що модель «сама зрозуміє».
Ще один сильний момент тут — у декомпозиції. Якщо спека стала занадто жирною, її треба не дописувати до нескінченності, а розбивати за природними межами: intake, analysis, execution, validation. І ось тут мультиагентність починає приносити користь, а не просто палити токени заради гарної схеми.
Що це змінює для бізнесу та автоматизації
Для бізнесу висновок жорсткий: основна невизначеність в AI-проєктах сидить не в моделі, а в постановці завдання. Якщо у вас немає живої специфікації, жодна автоматизація за допомогою ШІ не буде стабільною. Буде серія демонстрацій, після яких команда тихо ненавидить слово «агент».
Я це бачу на проєктах, де просять створити ШІ агента під внутрішні процеси. Майже завжди перший реальний прорив відбувається не після зміни моделі, а після того, як ми витягуємо з голів людей критерії результату, винятки, ролі, обмеження щодо даних та правила ескалації. Щойно це лягло в нормальну spec-структуру, архітектура ШІ-рішень стає набагато спокійнішою.
Хто виграє? Команди, у яких довгі R&D-цикли, багато неоднозначності та дорогі помилки: продуктова розробка, внутрішні платформи, складні інтеграції, enterprise-процеси. Хто програє? Ті, хто чекає миттєвої магії та вважає специфікацію бюрократією. Мультиагенти без хорошої спеки легко перетворюються на дорогий спосіб розпаралелити плутанину.
Я б не радив тягнути multi-agent setup у кожен кейс. Якщо задачу закриває один агент з нормальними tool calls, цього часто достатньо. Але коли контекст роздувається, етапів багато, а результат потрібно вміти перезбирати, spec-first підхід починає окупатися дуже швидко.
Ми в Nahornyi AI Lab такі штуки зазвичай збираємо через практичну зв'язку: жива специфікація, планувальник, ізольовані виконавці, контроль артефактів і зрозумілий контур рев'ю людиною. Це вже не «погратися з LLM», а нормальне впровадження ШІ в розробку та операційні процеси, де важлива повторюваність.
Я, Вадим Нагорний з Nahornyi AI Lab, дивлюся на такі патерни не як спостерігач, а як людина, яка регулярно збирає ШІ автоматизації, агентні пайплайни та кастомну AI-архітектуру під реальні завдання. Якщо хочете обговорити ваш кейс, замовити ШІ автоматизацію, розробку ШІ агента на замовлення чи n8n-автоматизацію, пишіть. Розберемо, де вам справді потрібен рій агентів, а де вистачить однієї чіткої спеки та хорошої збірки.