Habr يصف إطار AI لـ Claude مع Clean Architecture ودورة TDD
نشر Habr تحليلًا لإطار AI يجعل Claude يكتب الكود باستخدام القصص وprogress files ودورات TDD. ويقول الكاتب إنه خلال 3.5 أشهر طبّق هذا النهج على 4 آلاف commit و1.5

На Habr вышел подробный разбор AI-фреймворка, который заставляет LLM писать код не в режиме свободного «вайб-кодинга», а по жёсткому инженерному процессу. Автор утверждает, что уже ведёт через этот подход почти всю свою разработку и опирается на Clean Architecture, TDD и обязательное человеческое ревью.
Как устроен поток В основе подхода простая идея: хороший софт — это не
набор файлов, а набор подтверждённых сценариев поведения. Поэтому работа начинается не с генерации кода, а с разбиения продукта на независимые истории, каждая из которых даёт отдельную пользовательскую ценность. Для каждой истории Claude сначала проходит этап спецификации: собирает интервью, формирует описание, критерии приёмки, проектирует API, делает макеты и только потом собирает список тест-кейсов.
Уже после этого начинается реализация. Автор пишет, что проверил этот процесс на практике за 3,5 месяца работы: через него прошло около 4 тысяч коммитов, 1500 тестов, примерно 350 e2e-проверок и около 25 тысяч строк продакшн-кода, не считая тестового слоя. Центральный элемент схемы — команда /continue.
Она смотрит на список историй и файл progress.md, определяет, на каком шаге остановилась разработка, и двигает задачу дальше без ручного выбора следующего действия.
TDD и гейты
Фреймворк не просто просит модель «написать фичу», а буквально ведёт её по циклу ATDD и вложенным TDD-шагам. Для бэкенда это начинается с красного приёмочного теста, затем Claude спускается ниже — к use case и адаптерам, после чего поэтапно «зеленит» каждый уровень. Логика та же и для остальных частей продукта: сначала фиксируется проверяемое поведение, потом пишется код, а не наоборот.
Так автор пытается привязать работу модели к архитектуре, а не к случайной удаче. интервью и формализация требований по истории генерация тест-плана и кейсов до старта реализации red-green-refactor цикл для use case, адаптеров и приёмочных тестов quality gates с проверкой строгости тестов, архитектуры и покрытия * коммит после шага и обязательная пауза на ревью человеком > «На голых промптах далеко не уедешь». Поверх TDD автор добавил ещё и страховочные quality gates.
На красном шаге модель отдельно проверяет, насколько тесты строги и не ломают тестовую архитектуру; на зелёном — рефакторит код и сверяет покрытие. У каждого гейта есть чек-лист, по которому LLM должна явно пройтись. Отдельный акцент сделан на управлении контекстом: каждый подшаг запускается в отдельном агенте, а **progress.
md** позволяет после каждого коммита сбрасывать контекст и загружать только минимум данных для следующего прохода.
Параллельные окна IDE Практическая сторона у такого подхода не менее важна, чем сама архитектура.
Один запуск /continue может занимать от 5 до 20 минут, а на тяжёлых тестах — до 40 минут или даже часа. Чтобы не ждать один поток, автор советует клонировать демо-репозиторий несколько раз или использовать worktrees и запускать разные истории параллельно в отдельных IDE. В его собственном процессе одновременно открыто до шести окон, из которых четыре-пять заняты работой агента, а в оставшихся идёт ревью, рефакторинг и техдолг.
Для нестандартных случаев рядом с основным потоком живут дополнительные команды. Для входа автор выложил две репы: demo Kanban на Java + React и пустой каркас фреймворка. /task нужен для багфиксов, инфраструктуры и длинных задач, которые не укладываются в историю с полным TDD-ритуалом.
/prompt-update — для доработки самого фреймворка, если модель снова спотыкается о повторяющуюся проблему. При этом автор прямо признаёт ограничения: решение выросло из конкретного веб-стека, заточено под Clean Architecture и ATDD, тратит много токенов и не делает разработку полностью автономной. Если баг не пойман на ревью, он спокойно уедет в прод.
Что это значит
Подход показывает, куда сдвигается зрелая AI-разработка: от одиночных промптов к воспроизводимым пайплайнам, где модель работает внутри процесса, а не вместо него. Главный вывод здесь довольно жёсткий: LLM уже может ускорять продакшн-разработку, но только если её держат в рамках тестов, чек-листов, коротких шагов и постоянного человеческого контроля.