Агентам не нужен TDD Дядя Боб говорит, что TDD вообще-то для людей и агентам совсем не обязателен, ведь у агента дела с краткосрочной памятью обстоят куда лучше, чем у людей. А что нужно агентам? Юнит тест, CRAP метрика и мутационное тестирование... Кто-то считает CRAP и делает мутационные тесты? Если первое ещё иногда интересно, то второе довольно спорная техника - если практикуете расскажите. А по поводу TDD (его щас прям любят вайб кодеры тиражировать), то давно понятно, что классический TDD цикл (красный тест > код > зелёный тест > рефакторинг, причем мелкими итерациями) с агентами больше похож на прожигание токенов, чем на что-то полезное. Смысл имеет скорее разнообразные тест кейсы перед реализацией продумывать с агентом (включая интересные техники типа pairwise testing), сохранить их в маркдаун или (по BDD или нет - не принципиально). Ну и, конечно, одних лишь юнитов недостаточно совсем, они в принципе часто мало чего хорошего дадут проверить просто by design - идеально использовать умную связку из разных видов тестов - по пирамиде тестирования или лучше даже по трофею (статические проверки), ну или на худой конец хотя бы e2e или browser use/computer use. А когда вайб кодеры говорят про важность TDD часто просто имеют в виду, что нужно тестировать и верифицировать результат - что, конечно, бесспорно. Но Кент Бэк TDD это же не про это, это именно про красный тест > код > зелёный тест. Вот так начинают путаться классические термины с этими нашими вайб кодингами... В общем, если вы ещё используете TDD с агентами - скорее всего, он вам им не нужен. @ai_driven

Когда я был совсем юн, одно время ходил на курсы программирования. И когда для выполнения домашнего задания включал компьютер, мама говорила мне:

"Это зачем еще? Сначала напиши алгоритм на бумажечке, а потом уже переноси в компьютер."

Тогда это вполне имело смысл, ведь еще не было IDE с автоподстановками/автопроверками, программы занимали килобайты, не гигабайты, а в НИИ даже встречались перфокарты. Но важен еще один момент: чтобы писать код эффективнее, сначала нужна какая-то канва. Сначала обходились просто детальным ТЗ на работы. Затем придумали разные подходы, которые помогают создавать код не просто с чистого листа, а на какой-то основе. Я имею в виду Test-Driven Development (TDD), когда в основе правильного кода лежат успешные тесты, Behavior-Driven Development (BDD), когда в основе кода - конкретные сценарии. И прочие DD. Появление ИИ-помощников в работе повлияло на эти процессы. Несколько месяцев назад GitHub представил подход Spec-Driven Development (SDD). Суть в том, чтобы сначала создать спецификацию, затем скормить ее ИИ-агенту, на ее основе будет составлен план работ и потом строго по плану реализация.

Spec → Plan → Tasks → Implement

То есть теперь не просто пишем промпт "Нарисуй форму", а описываем цели, поведение, граничные условия, исключения и т.д. Для претворения этого дела в жизнь они опубликовали опенсорсный инструментарий - Spec Kit. Поддерживается 35 кодинговых агентов, имеет 138 расширений, может работать оффлайн. В репозитории есть ссылки на обзоры и сообщества. 123 тысячи звезд на Гитхабе, 257 контрибьюторов. #process