Habr AI→ оригинал

На Habr описали ИИ-фреймворк для Claude с Clean Architecture и TDD-циклом

На Habr вышел разбор AI-фреймворка, который заставляет Claude писать код через истории, progress-файлы и TDD-циклы. Автор говорит, что за 3,5 месяца прогнал чер

На Habr описали ИИ-фреймворк для Claude с Clean Architecture и TDD-циклом
Источник: Habr AI. Коллаж: Hamidun News.
◐ Слушать статью

На 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 уже может ускорять продакшн-разработку, но только если её держат в рамках тестов, чек-листов, коротких шагов и постоянного человеческого контроля.

ЖХ
Hamidun News
AI‑новости без шума. Ежедневный редакторский отбор из 400+ источников. Продукт Жемала Хамидуна, Head of AI в Alpina Digital.
Загружаем комментарии…