Команда агентов в Claude Code: от задачи до релиза

Полгода назад я начал делать сервис для себя, без команды. Код пишут агенты в Claude Code, я ставлю задачи и принимаю результат. За это время эксперимент превратился в рабочую схему: двенадцать ролей, обязательный порядок этапов, максимальная автономия агентов от постановки задачи до выпуска релиза. Расскажу, кто чем занимается, как задача проходит путь от строки в бэклоге до релиза и с чего начать, если хочется так же у себя.

С чего всё началось

Меня зовут Сергей Ладыгин, я разработчик.

В Claude Code анонсировали функцию Agent Teams. Одна сессия становится лидом команды: раздаёт задачи и собирает результат. Остальные агенты - тиммейты, отдельные сессии Claude Code, у каждого свой контекст. Они берут задачи из общего списка, где у задач есть зависимости, и переписываются друг с другом напрямую.

Функция включается переменной окружения CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.

А ещё у меня была своя боль: ретроспективы в моих командах проходили неоптимально. Я решил попробовать сделать свой сервис и заодно построить схему, при которой агенты смогут работать как целая команда разработчиков. Так в марте 2026 года я начал делать сервис для командных ретроспектив - Scruma, дальше буду называть его просто «проект». Стек обычный: Go, Next.js, PostgreSQL, Docker.

Сначала мы с Claude собрали объёмное ТЗ: как я вижу такой сервис, что он умеет, какие в нём экраны. Потом разбили ТЗ на задачи, и я запускал по одной задаче в одной сессии. На этом этапе мы зафиксировали стек, архитектуру и правила.

Claude выдавал результат так быстро, что я не успевал его проверять и принимать. В итоге я понял, что узкое место в этом процессе - я сам.

Тогда мы подумали, как сделать так, чтобы он сам проверял результат и писал на это тесты. Так появился QA: он проверял задачи в браузере, описывал тест-кейсы и писал по ним тесты. Для тестов у Playwright есть готовые агенты - Playwright Test Agents: планировщик, генератор и хилер. Вместе с QA появился DevOps - вносить изменения в контур и пересобирать его. А ещё качественный локальный контур, на котором можно проверить весь функционал.

Так я выстроил автономный процесс от постановки задачи до работающей реализации.

Результат: во что это выросло

Вот что лежит в репозитории проекта на сентябрь 2026 года.

Главная строка в таблице - про восемь версий моделей. Модели менялись примерно раз в месяц, и ни одну роль не пришлось переписывать под новую модель. Роли - это обычные markdown-файлы, поэтому основные из них я продублировал в форматах для Codex: skills и конфиги агентов, плюс общий AGENTS.md. Процесс держится на файлах в репозитории, а не на конкретной модели.

/weekly - раз в неделю. Запускаю в понедельник. Роль аналитика читает стратегию, бэклог гипотез и прошлый отчёт. Собирает метрики: посещаемость, витрины в базе, ошибки за неделю. Сверяет обещанное неделю назад с фактом и пишет отчёт. Потом показывает мне сводку с предложениями и останавливается: без моего ответа ничего не запускает и ничего не тратит. Я утверждаю, откладываю или вычёркиваю задачи, на это уходит 20–30 минут. Причину отказа аналитик записывает и учитывает в следующих предложениях. После ответа он обновляет бэклог и предлагает запустить исполнителей по утверждённым задачам. Через неделю следующий /weekly проверит, дала ли задача обещанный эффект.

/implement - на каждую задачу. Запускается на утверждённую продуктовую задачу. Сессия начинается в роли техлида: он разбивает задачу на подзадачи и ведёт её по ролям - архитектор, backend и frontend, DevOps, QA, документация. В конце техлид коммитит, дальше PR и CI. Мне остаётся принять результат и выпустить релиз. Подробно этот путь разобран ниже.

Это и есть две точки, где решаю я: в /weekly утверждаю план, после /implement принимаю результат. Всё между ними делают роли.

После нескольких итераций я пошёл ещё дальше: теперь /weekly после утверждения плана сам запускает /implement на каждую задачу. Значит, над проектом одновременно работают несколько команд разработки, у каждой своя задача и свой набор ролей. На выходе от каждой команды я получаю по PR.

Для частных случаев есть ещё команды. /bugfix - короткий конвейер для дефекта: техлид, разработчик, DevOps, проверка QA. /triage - дежурный по проду: разбирает ошибки из Sentry и логов и предлагает, что чинить. /marketing - тексты для продвижения и замер их эффекта.

Роли: кто чем занимается

Технически роль - это markdown-файл с промптом в папке .claude/commands. Техлид создаёт команду и запускает остальных как тиммейтов через Agent Teams, с задачами и зависимостями между ними.

Самое полезное в этой таблице - правая колонка. Роли для агентов работают, когда запреты сформулированы жёстче обязанностей. QA, который чинит сам, перестаёт находить: баги исправляются молча и не попадают в реестр.

Но и запрет текстом срабатывает не всегда. В промпте техлида прямо написано: «Ты не должен сам реализовывать задачи и писать код, ты должен декомпозировать задачи для teammates и контролировать их выполнение». В конце марта я дал ему маленькую задачу, и он решил, что быстрее сделает её сам. Сделал - хуже, чем сделал бы фронтендер.

Скелет промпта роли выглядит примерно так (сильно упрощённый):

Ты - QA-инженер проекта <название>.

Задача: $ARGUMENTS

## Контекст (читать первым)
- Решение задачи: docs/decisions/ - что должно получиться
- ТЗ: docs/spec.md - замысел
- Что есть в продукте на самом деле: docs/features.md и код
- Тест-кейсы: testing/test-cases/

## Что делать
1. Сверить изменённые файлы с ТЗ и решением.
2. Статические проверки: go vet, go test, tsc, lint.
3. Браузер: ТОЛЬКО изменённый функционал, скриншоты в testing/screenshots/.
4. Интеграционные тесты затронутых модулей.

## Что запрещено
- Чинить баги самому. Нашёл - опиши в testing/bugs/, один файл на баг.
- Тестировать весь сервис: для этого есть отдельная команда.

## Отчёт
Что прошло, что требует исправления (файл и строка), статистика тест-кейсов.

Реальный файл - 119 строк, но структура та же: контекст, порядок, запреты, формат отчёта. Порядок и запреты - самые важные части.

Путь одной задачи

Техлид декомпозирует. Читает ТЗ, задаёт мне вопросы, разбивает задачу на подзадачи, создаёт команду и список задач с зависимостями blocked_by. Сам не пишет ни строчки.

Архитектор пишет решение. Файл ADR в docs/decisions/: какие эндпоинты, какие миграции, какие сообщения по WebSocket, какие компоненты. Потом рассылает спецификацию backend и frontend. Для тривиальной задачи без новых API архитектора можно пропустить. Backend или frontend можно пропустить, если задача не трогает этот слой. DevOps, QA и документацию - никогда.

Backend и frontend работают параллельно. Каждый в своей зоне файлов. Каждый в конце прикладывает блок «Test impact»: какие тест-планы изменил, какие модули тестов нужно прогнать, какие сценарии под подозрением.

Точка контроля. Без блока Test impact техлид не передаёт задачу дальше, а возвращает разработчику. Это дешёвое правило сэкономило больше всего времени: QA гоняет тесты только по затронутым модулям, а не весь регресс.

DevOps пересобирает среду. docker compose up -d --build, проверка логов и здоровья сервисов, сообщение QA «среда готова».

QA проверяет. Сверяет результат с ТЗ и решением, запускает статические проверки, смотрит в браузере через Playwright MCP только изменённое, гоняет интеграционные тесты затронутых модулей. Если тесты упали из-за изменившегося поведения, субагент-хилер их чинит. Если появился новый функционал, планировщик дописывает план, а генератор пишет новые тесты. В конце QA обновляет тест-кейсы и карту покрытия.

Документация. README, карта проекта, статусы API.

Техлид собирает результат и коммитит. Дальше PR, CI (vet, тесты, типы, линтер, пробная сборка образов), тег, релиз.

Через неделю. Дежурный смотрит прод, аналитик сверяет гипотезу с фактом.

Всё это записано в промпте техлида - команде /implement. Скелет выглядит так (сильно упрощённый):

Ты - техлид проекта <название>.
Ты не должен сам реализовывать задачи и писать код, ты должен
декомпозировать задачи для teammates и контролировать их выполнение.

Задача: $ARGUMENTS

## Инструкции
1. Декомпозируй задачу на подзадачи с зависимостями.
2. Создай agent team и task list с зависимостями (blocked_by).
3. Спавни teammates с учётом зависимостей.

## КРИТИЧЕСКИ ВАЖНО: обязательный пайплайн
НИКОГДА не пропускай этапы пайплайна... (целиком - ниже)

## Роли teammates
- architect: ADR в docs/decisions/ - API, миграции, WebSocket,
  компоненты. Рассылает спецификацию backend и frontend.
- backend: ждёт спецификацию. Миграции, handlers, services, тесты,
  блок Test impact.
- frontend: ждёт спецификацию. Компоненты по дизайн-системе, без
  хардкод-цветов, блок Test impact.
- devops: ждёт backend и frontend. docker compose up -d --build,
  логи, здоровье сервисов, сообщение QA «среда готова».
- qa: ждёт devops. Проверка по ТЗ, браузер только по изменённому,
  тесты затронутых модулей, хилер и генератор тестов.
- docs: README, CLAUDE.md, docs/, статусы API.

## Точка контроля перед QA
Без блока Test impact от разработчика задачу в QA не передавай -
верни разработчику.

## В конце
Собери результат, сделай итоговый коммит, останови тиммейтов.

Реальный файл - 100 строк. Главное в нём - блок про обязательный пайплайн: три этапа нельзя пропустить никогда - DevOps, QA и документацию. Блок написан капсом, привожу его дословно, перенёс только строки:

НИКОГДА не пропускай этапы пайплайна. Даже если задача затрагивает
только frontend или только backend — полный цикл обязателен:

**Разработка → DevOps (пересборка) → QA (браузерное тестирование) → Docs**

- DevOps ВСЕГДА запускается после завершения разработки (backend и/или
  frontend) — без пересборки QA не может тестировать в браузере
- QA ВСЕГДА делает браузерное тестирование через Playwright MCP — это
  не опционально
- Docs ВСЕГДА проверяет и актуализирует документацию

Капс появился после ошибки. В марте техлид после реализации забыл передать задачу DevOps. QA открыл браузер, увидел старую версию и вернул задачу со словами «ничего не сделано». Я провёл с техлидом one-to-one, и он сам поправил свой промпт.

Код-ревью: встроено в процесс

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

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

Контроль - до кода. Архитектор определяет интерфейсы и контракты до того, как остальные начнут работу. В промпте каждой роли записаны запреты. У фронтенда, например, так: «Никаких хардкод-цветов, отступов, радиусов, теней, размеров шрифтов. Любой HEX/rgba в коде компонента = ошибка». На обычном ревью это замечание пришлось бы писать снова и снова.

Проверка - автоматически. Часть правил охраняют тесты: нарушил - сборка красная. CI на PR гоняет go vet, тесты, проверку типов, линтер и пробную сборку образов. QA сверяет результат с ТЗ и решением, а не спорит о стиле.

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

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

Слой знаний: что лежит рядом с кодом

Агент не помнит прошлых задач, поэтому память команды лежит в файлах. Я держусь подхода GitOps: всё, что можно описать кодом, описано кодом и лежит в git. Кроме приложения, это инфраструктура, мониторинг, алерты и дашборды. С агентами это даёт кратное усиление. Агенту видна вся система, от кода до алертов. Любую настройку он меняет тем же путём, что и код: правка в ветке, PR, CI, релиз по тегу. Всё, что изменилось, остаётся в истории git, и следующий агент может это прочитать.

Вот что есть в репозитории кроме кода приложения.

• ТЗ - замысел. Читают техлид и архитектор. Источником фактов о продукте не является.

• ADR - память решений: что решили, какие варианты отвергли и почему. Пишет архитектор, любой агент читает перед правкой, я читаю перед мержем.

• Карта граблей - папка с диагнозами отказов, дословно: как выглядит отказ, чем отличается от похожего, почему нельзя «упростить обратно». В корневом файле проекта - таблица «фича, файл, главное, что ломается».

• Карта фич и покрытия - таблица: экран, функционал, каким тестом закрыт, какое решение. У каждой строки написано, какая роль её обновляет.

• Тест-кейсы и тест-планы - один файл на кейс, сквозная нумерация. Планы по модулям - вход для генератора тестов.

• Стратегия, бэклог гипотез, недельные отчёты - основа недельного цикла. В стратегии прямо написано: «Стратегия живёт в файлах, а не в памяти агентов: решения, не записанные сюда или в backlog.md, для следующего цикла не существуют».

• Настройка инфраструктуры - compose-файлы для локального стека и прода, конфиги шлюза и прокси. При релизе по тегу CI копирует их на сервер вместе с новой версией кода.

• Настройка мониторинга - конфиги сборщика телеметрии, логов, трейсов и правила алертов. Алерт - это файл в репозитории, а не галочка в интерфейсе.

• Отчёты в Grafana - дашборды описаны в JSON: техническое состояние сервисов и бизнес-метрики. По бизнес-витринам аналитик собирает недельный отчёт.

С чего начать у себя

Самый частый вопрос после моих постов про агентов - «с чего начать». Отвечу структурой репозитория, потому что процесс живёт в ней, а не в головах и не в промптах.

Всё лежит в одном репозитории. Агент видит только то, что лежит рядом с кодом. Вики, таск-трекер, дашборд в браузере, схема в Miro - для него этого не существует. Поэтому в репозитории у меня лежит всё: код, тесты, документация, задачи и гипотезы, схема базы в виде миграций, конфиги деплоя и сервисов, дашборды и правила алертов как файлы, подключения MCP к браузеру, трекеру ошибок и метрикам, и всё, что нужно, чтобы поднять проект локально одной командой. Секретов в репозитории нет: примеры переменных лежат в .env.example, реальные значения подставляются в CI/CD.

Как это разложено. Упрощённо, без деталей:

CLAUDE.md / AGENTS.md    карта проекта: стек, структура, конвенции, карта граблей
.claude/commands/        роли как slash-команды, по файлу на роль
.claude/agents/          субагенты тестов: планировщик, генератор, хилер
.mcp.json                подключения агентов: браузер, ошибки, метрики (токены из env)
backend/                 сервис, миграции = схема базы, unit-тесты
frontend/                приложение
configs/                 шлюз, почтовые шаблоны, Grafana (дашборды, алерты), телеметрия
docs/spec.md             ТЗ - замысел
docs/decisions/          ADR, по файлу на решение
docs/dev/                грабли, по файлу на фичу
docs/features.md         карта фич и покрытия тестами
docs/api/                контракты эндпоинтов и их статусы
docs/runbook/            как поднять сервер, восстановить бэкап, настроить почту
docs/business/           стратегия, бэклог гипотез, недельные отчёты
specs/                   тест-планы по модулям, вход для генератора тестов
testing/                 интеграционные тесты по модулям, test-cases/, bugs/, screenshots/
.github/workflows/       CI на PR, релиз по тегу, деплой лендинга
docker-compose*.yml      локальный стек, прод, корпоративная редакция
Taskfile.yml             task up / build / test-integration-<module> / check
.env.example             все переменные с комментариями, без значений

Как выглядят документы. Форматы простые, и агенты держат их аккуратнее, чем люди.

Карта фич - таблица по экранам:

| Функционал            | Тест                          | Документ              |
|-----------------------|-------------------------------|-----------------------|
| Регистрация по email  | ✅ auth/registration.spec.ts  | ADR про авторизацию   |
| Смена пароля          | ❌                            | ADR про смену пароля  |

ADR - одно решение, один файл, обязательно с отвергнутыми вариантами:

# NNN. Название решения
## Статус: принято / заменено решением NNN
## Контекст: какую проблему решаем, что снято с живой системы
## Решение: что делаем - контракты API, миграции, сообщения
## Альтернативы: что рассматривали и почему отвергли
## Последствия: что меняется, чем проверяется
## Test impact: какие тест-планы и модули затронуты

Задача в бэклоге - гипотеза с ожидаемым эффектом и статусом, который не закрывается на «сделано», пока эффект не сверен с фактом:

| ID    | Гипотеза                 | Ожидаемый эффект     | Уверенность | Статус               |
|-------|--------------------------|----------------------|-------------|----------------------|
| B-001 | Гайд по частому запросу  | +N поисковых входов  | средняя     | сделано, ждёт замера |

Тест-кейс - один файл, сквозная нумерация, статус меняет QA:

# TC-001: Регистрация по email
Модуль: auth · Приоритет: critical · Статус: pass
## Предусловия
## Шаги
## Ожидаемый результат
## Фактический результат

Один репозиторий или несколько. Для проекта моего размера подходит монорепозиторий: бэкенд, фронт, лендинг, конфиги и документы в одном месте, агент видит всё из одного корня. Если проект большой и сервисы живут в своих репозиториях, работает мета-репозиторий: в нём правила, роли, документы и карта, а репозитории сервисов выгружены рядом. Смысл тот же: у агента один корень, из которого видно всё.

Локальный запуск обязателен. task up поднимает весь стек: база, почтовый мок, шлюз, мониторинг. На нём работают QA-роль и интеграционные тесты. Если проект нельзя поднять локально одной командой, роль QA проверить ничего не сможет, и весь конвейер сведётся к «код написан».

В каком порядке заводить. Если начинать с нуля, я бы шёл так:

1. Карта проекта и ТЗ - до первого коммита.

2. Две-три роли файлами-командами и обязательный порядок этапов.

3. QA в браузере и интеграционные тесты как условие перехода, отчёт о влиянии на тесты от разработчика.

4. ADR и грабли как обязательный выход каждой задачи.

5. Недельный цикл с утверждением плана и дежурный по проду.

Ни один из шагов не требует конкретной модели или инструмента. Роли у меня переезжали между Claude Code и Codex с минимальными правками, потому что живут в обычных markdown-файлах.

Вывод

Если выжимать один вывод: процесс для агентов - это роли с запретами, две точки, где решает человек, и память в файлах. Всё остальное - детали.

• Запреты работают лучше обязанностей: «не пиши код», «не чини», «не трогай среду».

• Проверка встроена в конвейер как условие перехода. Разработчик не отдаёт задачу без отчёта о влиянии на тесты, QA не берёт задачу без пересобранной среды.

• Код-ревью встроено в процесс: архитектура и ограничения задаются до кода, поэтому нет петли «написали - получили замечания - исправили».

• Память лежит в файлах: решения, грабли, карта покрытия. Без неё агенты повторяют старые ошибки.

Если вы делаете проект с агентами и через пару месяцев в нём начали повторяться старые ошибки - начните с запретов и обязательных этапов, это дешевле всего. Если вы тимлид команды людей и думаете, как встроить агентов, - начните с карты проекта и ADR: людям они пригодятся не меньше.