Технічний контекст
Я зачепився за цей кейс не через драму навколо інструментів, а через дуже знайомий патерн: щойно AI automation у розробці стає занадто багатослівною, лічильник токенів злітає, а контроль у людини просідає. Тут це видно майже під мікроскопом.
Сценарій простий. Задача локальна: перевести збереження в Elasticsearch-репозиторії на bulk API, сам репозиторій близько 500 рядків, плюс трохи коду навколо. А далі Superpowers розкручує це в специфікацію на 2700 рядків, з прикладами коду, тестів, питаннями, TDD-ритуалом та 14 комітами приблизно за 2 години.
І ось тут я б теж пригальмував. Не тому що TDD поганий, а тому що рев'юїти 2700 рядків заради зміни середнього розміру, м'яко кажучи, не подарунок. Формально агент молодець, практично я вже плачу не тільки токенами, а й увагою команди.
В альтернативному підході, який користувач описав через навички Matt Pocock та перехід на Codex, ритм інший: короткий план, коротка ітерація, перегляд підсумкового коду, розбір незрозумілих місць з агентом. Я сам цей режим вважаю більш стійким, коли потрібно утримувати архітектуру в руках, а не приймати чергову акуратно запаковану чорну скриньку.
Так, збоку це виглядає повільніше, ніж кинути велику спеку й піти пити каву. Але на практиці короткий контекст майже завжди дешевший, більш передбачуваний і краще лягає в AI integration всередині живого проєкту, де код вже обріс історією, компромісами та дивними краями.
Окремо важливий момент: прямих бенчмарків тут немає, і я б не вдавав, що це лабораторна істина. Поки що це здебільшого сильні спостереження користувачів, але вони добре збігаються з тим, що я бачу в реальних агентних пайплайнах.
Що це змінює для бізнесу та автоматизації
Виграють команди, яким потрібен не «автопілот за будь-яку ціну», а керована AI solution development: менше контексту, швидше рев'ю, нижча вартість кожного циклу. Особливо там, де важливіші часті безпечні правки, ніж демонстративно автономний агент.
Програють сценарії, де агенту дають занадто багато свободи на маленьких задачах. Тоді дорога ретельність з'їдає ефект, а людина все одно зобов'язана перевірити результат.
Я б сформулював так: verbose TDD-підхід хороший, коли задача реально велика і її потрібно формалізувати майже як мініпроєкт. Для повсякденної продуктової розробки компактні ітерації частіше виявляються банально вигіднішими.
Ми в Nahornyi AI Lab якраз розбираємо такі вузькі місця в командах: де потрібен агент, де вистачить хорошого циклу з коротким контекстом, а де AI architecture вже почала палити бюджет без користі. Якщо у вас схожа історія з дорогими та неповороткими агентами, давайте подивимось на процес разом і зберемо AI automation під ваш реальний стиль роботи, а не під красиву демку.