Как я строю production-процесс, где AI-агенты делают реальную работу, а качество держится правилами, а не надеждой.
Паттерны вынесены из рабочего пайплайна (frontend / landing production). Сам пайплайн под NDA — здесь архитектура, роли и примеры конфигов без клиентских данных.
Один «умный агент» в длинной сессии деградирует: контекст разбухает, самопроверка слабая, одни и те же ошибки повторяются от задачи к задаче. Дорогая модель в каждом ходе — сжигает бюджет.
┌──────────────────────────────────────────────────────────────┐
│ 1. ROLES Executor (Cursor) ←→ Lead (Claude Code) │
│ вёрстка, сборка ревью, вердикт, │
│ процесс, память │
├──────────────────────────────────────────────────────────────┤
│ 2. ADVISOR Organizer (Sonnet) ── on-demand ──► Advisor │
│ main loop, каждый ход (Opus, read-only) │
├──────────────────────────────────────────────────────────────┤
│ 3. RULES .mdc-правила по ролям + скрипты-гейты │
│ validate → click-test → package │
├──────────────────────────────────────────────────────────────┤
│ 4. MEMORY ошибка → правило; типизированная память │
│ читается перед каждой задачей │
└──────────────────────────────────────────────────────────────┘
| Executor (Cursor) | Lead (Claude Code) |
|---|---|
| вёрстка, сборка, ассеты, упаковка | ревью, вердикт ПРИНЯТО / ПРАВКИ / СТОП |
| прогоняет валидаторы, правит по чеклисту | разбор ошибок, запись уроков |
| читает память перед работой | владеет правилами, скриптами, памятью |
| не трогает конфиги лида | не делает работу исполнителя без запроса |
Каждый инструмент видит только свои инструкции. Исполнитель физически не может «договориться с собой» о приёмке.
Дешёвая модель ведёт работу. Дорогая зовётся точечно, только читает и отвечает коротко.
Когда звать advisor:
- перед любым финальным «принято» — обязательно
- развилка из двух равноправных подходов
- конфликт между правилами, памятью и ТЗ
- формулировка нового урока в память
Ключевой приём: в промпт advisor'у кладутся факты (пути, вывод валидатора, дифф), а не «разберись в репо». Иначе дорогая модель сама сканирует проект и экономия сгорает.
- правила разбиты по ролям (
core,dev,qa,front,cleanliness) и подгружаются по контексту задачи - каждое критичное правило подкреплено скриптом, а не только текстом
- порядок гейтов фиксирован: validate → click-test → package; упаковка без зелёных гейтов невозможна
Принцип, выведенный на практике: repair > retry > gate. Проверка только на финальном гейте превращает каждое нарушение в мёртвую задачу; чинить надо там, где ошибка рождается.
Каждый разбор бага заканчивается одной строкой ошибка → правило. Память типизирована и индексирована, чтобы агент подтягивал только релевантное.
- повторяемые ошибки уходят в правила и скрипты, а не в «в следующий раз внимательнее»
- дорогая модель — только в точках решений
- приёмка независима от исполнителя
- новый человек / агент стартует с накопленным опытом команды, а не с нуля
Claude Code (agents, skills, hooks, MCP) · Cursor (rules .mdc) · Python (валидаторы, click-тесты на Playwright, упаковка) · Asana / Slack через MCP
Автор: Artem Egorov · Frontend (React / Vue / Nuxt) · AI-assisted development