Полгода назад я начал делать сервис для себя, без команды. Код пишут агенты в 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-файлы, починка упавших | Хилер не задаёт вопросов и не ждёт |
Я | Утверждение плана, приёмка, деньги, публикации, стратегия, вкус |
Самое полезное в этой таблице - правая колонка. Роли для агентов работают, когда запреты сформулированы жёстче обязанностей. 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: людям они пригодятся не меньше.
