За 3,5 месяца работы с собственным ИИ-фреймворком техлид Саша Раковский накопил 4 000 коммитов, написал 1 500 тестов — около 350 из них end-to-end — и вырастил кодовую базу до 25 000 строк продакшн-кода: примерно поровну Java-бэкенд и TypeScript/TSX-фронтенд. Столько же строк занимает тест-код. Фреймворк разрабатывался для нужд команды, которая обслуживает расчётный центр банка, где ежедневно проходят миллионы платежей, а цена ошибки измеряется сотнями миллионов рублей.
Появление фреймворка — следствие практического разочарования в «голых промптах». По наблюдению Раковского, без системного управления контекстом и без автотестов ИИ-разработка быстро превращается в неуправляемый процесс. Из открытых TDD-ориентированных инструментов он упоминает только Superpowers, однако считает его слишком легковесным: тот плохо встраивается в ATDD и структурированные процессы. Собственное решение выросло органически из командных практик, которые автор называет «книжным подходом» — с отсылкой к работам Тома Хомбергса «Get Your Hands Dirty on Clean Architecture» и Алистера Кокберна «Hexagonal Architecture Explained».
Архитектурно фреймворк делит работу на пользовательские истории — минимально зависимые друг от друга фичи. Каждая история проходит два этапа: спецификацию (интервью, описание, макеты, проектирование API, генерация тест-кейсов) и реализацию. Реализация идёт строго в TDD-стиле: сначала красный приёмочный e2e-тест, затем красный и зелёный usecase-тест, потом аналогичные мини-циклы для каждого адаптера — контроллера и прочих, — и наконец приёмочный тест зеленеет. После каждого шага фреймворк делает коммит и уходит на паузу, ожидая ревью от человека.
Центральный скилл /continue сам определяет следующий шаг, опираясь на progress.md каждой истории.
Центральный скилл /continue читает текущее состояние проекта через файл stories.md и progress.md каждой истории, сам определяет, на каком шаге остановилась работа, и продолжает с нужного места. Это снимает необходимость вручную отслеживать контекст между сессиями. Для исправления типовых ошибок LLM предусмотрены quality gates: на красном шаге — ревью строгости тестов и тестовой архитектуры плюс рефакторинг, на зелёном — рефакторинг и проверка покрытия. По каждому пункту обязательного чеклиста модель должна явно отчитаться о наличии или отсутствии нарушения.
Фреймворк опубликован с демо-примером: Kanban-доска с тремя историями — создание, перемещение и редактирование/удаление задачи. На примере видно, как /continue ведёт себя на разных стадиях готовности истории: от нулевой спецификации до частично реализованного фронтенда. Раковский честно обозначает ограничение: инструмент создавался под серверные приложения, и для мобильной, десктопной или embedded-разработки потребуется адаптация через скилл /prompt-update. Автономная ИИ-разработка, по его оценке, остаётся фантастикой — человеческое ревью после каждого шага он считает обязательным условием приемлемого качества.
