Автор CRM на Django собрал из пяти ИИ-ролей пайплайн, который сам ведёт задачу до скриншота

Знакомая картина: запускаешь Claude или Codex, кидаешь промпт, получаешь «готово». Открываешь код, а там те же формы, только переменные переименованы. Автор разбора на Habr пришёл из разработки баз данных и осенью 2025 года взялся за CRM для проката машин и аэроклубов. Он прошёл через это четыре раза подряд и в итоге построил пайплайн, который сам ведёт задачу и приносит доказательства.

Почему одного промпта мало

Он делал общие ресурсы для машин, инструкторов и площадок на Django. Формы похожие, и код хотелось переиспользовать. Codex отчитался, что рефакторинг выполнен, но ревью показало, что почти ничего не изменилось. Ещё три круга в разных чатах дали тот же результат. Главная претензия автора: что именно сделала модель, он понимал только в конце. Знания между чатами приходилось переносить вручную, а сжатие контекста теряло детали.

Ему нужна была система, где заранее видно, как модель поняла задачу, работа разбита на шаги, а каждый шаг проверяет кто-то другой. Проверить всё самому он не мог.

Пять ролей и один файл

Роли выросли из набора консольных врапперов для Codex CLI, Claude Code и GLM. Сначала их было четыре:

• архитектор строит верхнеуровневое решение (GPT-модели в Codex);
• планировщик определяет набор файлов и набрасывает черновик кода;
• кодер пишет изменения;
• ревьюер проверяет результат. Эту роль отдали GLM, в том числе чтобы уложиться в лимиты подписок.

Когда параллельная работа в пяти git worktree съела внимание автора, появился менеджер. Это почти механическая роль, которая передаёт ход. Автор сделал её агентом, а не скриптом, потому что хотел спрашивать «на каком мы статусе». Сейчас ревьюеров два, по зонам ответственности.

Связывает всех координирующий артефакт, то есть план-файл. Его ведёт архитектор, остальные дописывают свои разделы, менеджер только читает и передаёт дальше. В шапке записан статус и то, кто вправе его поставить: Ready for Planner, Ready for Coder, Ready for Review, Done. Это та же идея, что в SDD-фреймворках вроде Spec Kit, OpenSpec, BMAD и Kiro. Задача живёт в файле и переживает сжатие контекста.

Есть и забавная деталь: роли не любили перечитывать план и полагались на «память». Архитектор однажды заявил, что сейчас ход планировщика, хотя тот уже отработал. Лечение простое. Статус выдаёт хелпер, роль его спрашивает и ничего не придумывает.

Как это выглядит на реальной задаче

Задача из CRM для аэроклубов: запись самолёта, инструктора и курсанта по времени. Планировщик заметил, что для поля «Урок из раздела АУЦ» в модели данных нет места, и задал архитектору вопрос с пометкой «блокер». Архитектор указал, куда замапить поля, и кодер начал работу без вопросов.

Ревьюер дважды возвращал форму кодеру. Во второй раз тест даже закрепил ошибку и проходил, поэтому одних зелёных тестов мало. В третий раз ревьюер прогнал проверки (119 и 67 тестов, проверку миграций, doc-lint), снял скриншоты по сценарию из плана и сверил каждый с планом. Архитектор открыл шесть скриншотов и с первого раза задачу не принял: три файла в коммите не входили в объявленный набор. После исправления принял. Человек подаёт задачу на входе и смотрит, сходятся ли план, ревью, тесты и скриншоты.

Пайплайн ещё и улучшает сам себя. После каждого плана роли делают docs closeout: предлагают, что доделать и как улучшить процесс. Предложения копятся в реестрах, триаж решает, что внедрять. Идеи автор берёт и извне. Golden paths, короткие рецепты вида «для типовой формы открой эти 3–5 документов», и doc gardening пришли из статьи OpenAI про harness engineering. Поиск QMD по markdown попробовали и отвергли: хватило полнотекстового поиска на SQLite. От зацикливания страхует лимит: после 12 итераций на одном плане менеджер останавливает работу.

Ограничения и что забрать себе

Это опыт одного человека на одном проекте, без замеров вроде «сэкономил столько-то часов». Формы к единому коду автор так и не свёл, остановившись на «понятном уровне одинаковости». Через пайплайн идут не все правки, а только те, после которых нужен след в репозитории. Проверка другой моделью теперь в основном происходит вне пайплайна. Конкретные модели, которые он называет, не главное: они меняются быстрее, чем процесс.

Что стоит унести в свой проект:

• Требуйте доказательств, а не отчётов: тесты, скриншоты, сверка с планом.
• Заведите единый файл задачи со статусами и правилом, кто какой статус ставит.
• Не поручайте модели считать статус, вынесите это в хелпер.
• Разрешите ролям задавать блокирующие вопросы до написания кода.
• Поставьте лимит итераций, чтобы агенты не буксовали бесконечно.

Главный урок: промпт хорош для разового решения. Как только проект надо развивать и поддерживать, нужен процесс, в котором результат можно проверить глазами.