Команда из 12 ИИ-агентов в Claude Code: схема до релиза

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

1. Один элемент бэклога — один файл: что нужно сделать, зачем и критерии приёмки проверяемыми утверждениями («эндпоинт отвечает 200 на пустой запрос»). Результат: проверка по любой задаче даёт «прошла или не прошла», а не «вроде работает».
2. Опишите роли текстом, по файлу на роль: что делает, чего не делает и какой артефакт передаёт дальше. Результат: у каждого этапа есть вход и выход.
3. Заведите общий файл правил проекта (в Claude Code — в корне репозитория): стек, стиль, запреты, команды сборки и тестов. Результат: агент не переспрашивает про фреймворк и не тянет лишние библиотеки.
4. Задайте жёсткий порядок этапов: задача не попадает в релиз, минуя тесты и ревью. Результат: по истории репозитория видно, кто и на каком этапе прикасался к задаче.
5. Роль «постановщик» переводит задачу в техзадание: список изменений, границы правок, риски. Результат: техзадание читается за минуту и оспаривается до работы, а не после.
6. Роль «архитектор» описывает решение до кода: какие модули затрагиваются, какие интерфейсы меняются, что не трогаем. Результат: план изменений лежит в задаче, и дифф сверяется с ним построчно.
7. «Разработчик» пишет код в отдельной ветке: одна задача — одна ветка. Результат: правки изолированы, откат — одна команда.
8. «Тесты» дописывает и запускает проверки. Результат: в отчёте видно число прошедших тестов до и после правок.
9. «Ревьюер» читает дифф, а не пересказ, и это не тот агент, который писал код. Результат: замечания с привязкой к строкам, а не «выглядит неплохо».
10. «Безопасность» проверяет секреты, зависимости и права доступа: ключи не должны попадать ни в репозиторий, ни в логи прогонов. Результат: отчёт по новым зависимостям и найденным секретам.
11. «Документация» обновляет описание проекта и журнал изменений. Результат: описание релиза собирается по журналу без чтения диффа.
12. «Релиз-менеджер» собирает версию: тег, список изменений, выпуск. Результат: релиз воспроизводится одной командой, а не руками по памяти.
13. За человеком — две точки: постановка задачи и приёмка. Промежуточные этапы агенты проходят сами, но продакшен закрыт без явного «да». Результат: в журнале видно, кто подтвердил релиз.
14. Логируйте каждый прогон и считайте стоимость: расход на задачу, число кругов правок и долю задач, принятых с первого раза. Результат: раз в неделю видно, какой этап буксует.

Стоимость считается по числу прогонов, а не агентов: каждая роль — отдельный запрос к модели. Поэтому логирование не менее важно, чем сами роли: без него не видно, какие этапы съедают бюджет, а какие можно слить в один запрос.