(java || kotlin) && devOps: post #625 — TG.ME

Агент работает по TDD, но делает ли он это с уважением правильно?

Недавно говорил с коллегой по поводу superpowers и TDD, и возник интересный вопрос.
Формально да, процесс идет по TDD - red-green-refactor - пишется тест, он падает, пишется код, тест зеленеет.
Но становится ли такой код качественнее, ведь LLM всегда может подогнать код под результат?

Давайте посмотрим на основные аргументы в пользу TDD.

1) TDD гарантирует нам, что тесты точно будут, покрытие растет, регрессионные баги находятся на этапе разработки.
С AI тесты точно будут, если поставить ей такую цель - через контекст, субагента или навык.
Скорость кодирования вырастает, агенту не важно что писать - код или тесты.
В этом плане точное следование TDD мало что дает - достаточно явных требований агенту и процедуры их валидации.

2) т.к. тесты пишутся до кода, то код гарантированно выставляет более согласованное и более тестируемое API.
Тут TDD помогает, с двумя ремарками:
а) модель может смухлевать и подогнать тесты под существующий код. Как с этим бороться - отдельная тема
б) если говорить про superpowers - он пишет сразу план с тестами и кодом.
Поэтому тот факт, что вначале идет тест, важен, но не так критичен.
AI работает в одной сессии, а при разработке человеком - сессии разные, между написанием кода и тестов могут пройти дни.
А т.к. сроки ограниченны => плохое API остается навсегда.

3) короткий цикл разработки, быстрая обратная связи, как итог - правильная декомпозиция задач.
Это очень важно, и TDD в исполнении AI агента тут помогает собственно AI разработке.
Если подзадачи мелкие - на них проще сделать evals (приемочные тесты), не забыть ничего.
Некоторые задачи можно распараллелить, если агент это поддерживает
И т.об. снизить время ревью человеком и превратить преимущество в скорости кодирования агента в уменьшение Lead Time.
Ремарка - блокер тут не только время ревью, но это оно оказывает существенное влияние.

4) благодаря TDD тесты становятся документацией.
Исходя из моего опыта с superpowers - "из коробки" это не так, нужно дополнительно настраивать контекст, чтобы тесты были читаемы.
И второй ключевой момент - задание evals со стороны разработчика на этапе проектирования.
Именно тесты, являющиеся приемочными - лучшая документация.

Вывод: да, с AI важность TDD меньше, чем без нее.
Но все равно TDD остается полезен если не забывать про evals (приемочные тесты) и донастроить обвязку под читаемость тестов и запрет хаков со стороны модели.
Главные плюсы: тесты как документация на основе заданных evals и короткие контролируемые циклы разработки.
Т.е. само написание тестов до кода тут не так важно, как качество тестов и написание их в одной сессии с кодом.
И да, при таком подходе тесты можно было бы писать после кода в одной сессии. Но зачем?)

#ai #ai_agents #tdd
July 30, 2026 121