Технический контекст
Я зацепился за этот кейс не из-за драмы вокруг инструментов, а из-за очень знакомого паттерна: как только 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 под ваш реальный стиль работы, а не под красивую демку.