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

Ladygin58 минут назад

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

Уровень сложностиСложныйВремя на прочтение12 минОхват и читатели1.3KИскусственный интеллектКейсПолгода назад я начал делать сервис для себя, без команды. Код пишут агенты в 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 года.

ЧтоСколькоРолевых команд для агентов14 (12 ролей) плюс 3 субагента для тестовАрхитектурных решений (ADR)73Файлов с «граблями» - диагнозами отказов37Тест-кейсов / файлов интеграционных тестов331 / 146Разобранных багов110Недельных отчётов по бизнес-циклу6Коммитов / PR / релизных тегов409 / 70 / 44Коммитов только с документацией, без кода64 из 325Версий моделей за полгода8Медиана от первого коммита в ветке до мержа (61 PR)3,9 часаГлавная строка в таблице - про восемь версий моделей. Модели менялись примерно раз в месяц, и ни одну роль не пришлось переписывать под новую модель. Роли - это обычные 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, с задачами и зависимостями между ними.

РольДелаетНе делаетАналитик неделиМетрики, сверка гипотез, отчёт, бэклогНе решает про деньги и приоритеты, не правит стратегию, не выдумывает числаДежурный по продуСобирает и классифицирует ошибки, предлагает, что чинитьНе чинит, не трогает средуМаркетолог и писательМатериалы для лендинга и посевов, замеры эффектаНе публикуют от моего имениТехлидДекомпозиция, команда, задачи с зависимостями, контрольНе пишет код, не пропускает этапыАрхитекторРешение: API, миграции, сообщения, компонентыНе пишет кодBackend / FrontendРеализация, тесты, отчёт о влиянии на тестыНе сдают работу без этого отчёта; frontend не хардкодит цвета и отступыDevOpsПересборка среды, здоровье сервисовНе трогает код продукта, его зона - compose и конфигиQAСверка с ТЗ и решением, статические проверки, браузер, тесты, тест-кейсыНе чинит баги, не гоняет весь регресс на каждой задачеДокументацияREADME, карта проекта, docsНе пишет кодПланировщик, генератор, хилер тестовПлан сценариев, spec-файлы, починка упавшихХилер не задаёт вопросов и не ждёт networkidleЯУтверждение плана, приёмка, деньги, публикации, стратегия, вкусСамое полезное в этой таблице - правая колонка. Роли для агентов работают, когда запреты сформулированы жёстче обязанностей. 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 проверить ничего не сможет, и весь конвейер сведётся к «код написан».

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

• Карта проекта и ТЗ - до первого коммита.
• Две-три роли файлами-командами и обязательный порядок этапов.
• QA в браузере и интеграционные тесты как условие перехода, отчёт о влиянии на тесты от разработчика.
• ADR и грабли как обязательный выход каждой задачи.
• Недельный цикл с утверждением плана и дежурный по проду.Ни один из шагов не требует конкретной модели или инструмента. Роли у меня переезжали между Claude Code и Codex с минимальными правками, потому что живут в обычных markdown-файлах.

Вывод

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

• Запреты работают лучше обязанностей: «не пиши код», «не чини», «не трогай среду».
• Проверка встроена в конвейер как условие перехода. Разработчик не отдаёт задачу без отчёта о влиянии на тесты, QA не берёт задачу без пересобранной среды.
• Код-ревью встроено в процесс: архитектура и ограничения задаются до кода, поэтому нет петли «написали - получили замечания - исправили».
• Память лежит в файлах: решения, грабли, карта покрытия. Без неё агенты повторяют старые ошибки.Если вы делаете проект с агентами и через пару месяцев в нём начали повторяться старые ошибки - начните с запретов и обязательных этапов, это дешевле всего. Если вы тимлид команды людей и думаете, как встроить агентов, - начните с карты проекта и ADR: людям они пригодятся не меньше.Теги:• claude
• agents
• go
• сезон код будущегоХабы:• Искусственный интеллект