1. Один Claude часто лучше маленькой «AI-команды»
Когда люди впервые доходят до темы multi-agent, их почти всегда тянет переусложнить даже простую задачу. Это абсолютно нормальная стадия. Примерно как у новичка в спортзале: технику не поставил, а перчатки, пояс, браслет, умные часы и загадочный аксессуар очень серьёзных людей уже мысленно выбрал. Сначала «красиво», после — «правильно».
После всей карты skills, subagents, MCP и hooks это особенно опасно: инструменты уже под рукой, и рука сама тянется собрать AI-оркестр там, где хватило бы одного исполнителя. Поэтому сместите вопрос: не «что включить», а «когда это оправдано».
По умолчанию достаточно одной основной сессии Claude. Всё остальное нужно оправдать задачей.
Это не скучное правило, а полезный фильтр. Один Claude уже читает код, работает в plan mode, вносит изменения, запускает проверки, показывает diff. Задача небольшая, последовательная, в одном месте проекта — subagent, отдельная сессия или worktree её не ускорят, лишь добавят движущихся частей.
Чтобы не решать «на эмоциях», полезно прогонять задачу через признаки:
| Признак задачи | Что спрашиваем |
|---|---|
| Размер | Это небольшое изменение или длинная многошаговая работа? |
| Независимость частей | Можно ли и правда разделить работу на куски, которые не мешают друг другу? |
| Ownership | Можно ли честно сказать, кто отвечает за какие файлы, модули или слои? |
| Риск | Это простой UI-текст или sensitive area вроде payments, auth, migrations? |
| Verification | Есть ли tests, checks и понятный способ доказать, что всё работает? |
| Merge-conflict risk | Не полезут ли разные роли в один и тот же файл? |
| Human attention | Есть ли у вас ресурс проверять промежуточные результаты? |
Вот тут и появляется первое взрослое инженерное решение: parallelism — это не «фича», а design decision. Его принимают до старта работы, а не «по ходу, потому что стало интересно».
Для Commerce OS это выглядит очень жизненно. Issue уровня «исправить подпись в сообщении об ошибке в корзине» — а вы запускаете planner, reviewer и background agent. Всё равно что вызвать строительную бригаду поправить криво висящую картину: картина, конечно, впечатлится, но вряд ли оценит.
2. Меню уровней: от сессии до agent team
Чтобы не путаться, полезно воспринимать варианты не как хаос возможностей, а как ограниченное меню: выбираете не «что моднее», а «что дешевле по координации и достаточно для задачи». И вещей тут две: уровень координации и режимы, которые меняют способ исследования, изоляции или исполнения.
| Уровень координации | Когда подходит | Что даёт |
|---|---|---|
| Одна основная сессия | Небольшая и понятная задача | Минимум координации |
| Отдельная роль: subagent или fresh / separate session | Нужно изолированное investigation или независимый review | Отдельный context window без full team |
|
Есть несколько независимых workstreams и явная точка координации | Координация нескольких ролей |
| Режим / модификатор | Для чего нужен | Что важно не перепутать |
|---|---|---|
|
Нужна разведка без edits | Это ограничение текущей сессии, а не новый worker |
|
Нужны параллельные или рискованные edits | Это file/Git isolation; оно часто идёт вместе с выбранным уровнем координации |
| Background session | Работа действительно независима и её можно вести асинхронно | Это уже advanced operational mode; нужен явный status tracking, а конкретный surface может отличаться по версии |
То есть plan mode и worktree — не ещё два «следующих агента в списке», а модификаторы выбранного уровня. Чтобы это почувствовать, давайте посмотрим на простой decision record — короткий артефакт, который держат в Workflow Kit рядом с AGENT_HANDOFF_CONTRACT.md:
# Решение по параллелизму — COM-482
Задача: вынести refund-валидацию из OrderService в отдельный helper.
Размер: небольшой
Независимые части: нет
Риск: средний, payment-adjacent
Тесты: есть 2 целевых теста
Выбор: одна сессия + plan mode
Отвергнуто:
- subagent: отдельная роль не нужна
- worktree: параллельных edits нет
- agent team: независимых workstreams нет
Обратите внимание: важно не только то, что выбрали, но и то, от чего осознанно отказались. Именно так решение становится проверяемым артефактом, а не «ощущением».
3. Coordination cost важнее количества агентов
Когда говорят «давайте распараллелим», обычно думают только о выигрыше по времени. Но у параллельности есть цена, и не только в токенах. Самое дорогое часто человеческое: внимание, контроль, синхронизация промежуточных решений.
Полезно смотреть на coordination cost как на сумму нескольких компонентов.
| Компонент стоимости | Что это значит на практике |
|---|---|
| Контекст | Задачу нужно объяснить нескольким ролям, а не одной |
| Время на handoff | Каждый результат надо передать дальше и правильно прочитать |
| Git-стоимость | Появляются merge conflicts, отдельные ветки, worktree |
| Review-нагрузка | Проверять нужно уже не один diff, а несколько промежуточных результатов |
| Token-cost | Больше сессий = больше чтений, сводок и перепроверок |
| Cognitive load | Нужно помнить, кто что делает и на каком этапе застрял |
Вот почему формула курса звучит так:
More agents create coordination cost; use them only when parallelism is real and verification is clear.
На человеческом языке это значит: если задача не распадается на куски, вы получаете не «команду», а несколько источников бардака. Представьте, что вы чините баг в Commerce OS: дублируется заказ в pagination на /api/orders. Один Claude в plan mode — одна нить рассуждения. А поднимете исследовательскую сессию, отдельного executor и ещё reviewer — платите за три контекста, три handoff-а и три точки, где теряется исходная гипотеза. Быстрее баг не чинится. Он просто наблюдает за вашим организационным талантом.
4. Decision tree для выбора уровня без гадания
Давайте соберём простой decision tree. Не модель Вселенной, а шпаргалка — её держат в Workflow Kit как внутренний документ.
flowchart TD
A[Есть задача] --> B{Она маленькая и последовательная?}
B -->|Да| C[Одна сессия]
B -->|Нет| D{Сначала нужна разведка без edits?}
D -->|Да| E[Plan mode]
D -->|Нет| F{Нужна отдельная роль для investigation или review?}
F -->|Да| G[Fresh session или subagent]
F -->|Нет| H[Вернуться к одной сессии и уточнить task spec]
C --> I{Есть несколько независимых workstreams?}
E --> I
G --> I
H --> I
I -->|Нет| J[Этого уровня координации достаточно]
I -->|Да| K{Будут параллельные edits?}
K -->|Да| L[Добавить worktree поверх выбранного уровня]
K -->|Нет| M[Можно обойтись без file isolation]
L --> N{Нужна ещё и async execution или team-координация?}
M --> N
N -->|Да| O[Смотреть в сторону background execution или agent team]
N -->|Нет| J
Эта схема важна не потому, что в ней красивые стрелочки. Она важна потому, что учит одному: сначала вопросы о задаче, потом инструмент.
Давайте посмотрим на три коротких примера.
Задача: исправить текст кнопки “Refund accpeted” → “Refund accepted”.
Выбор: одна сессия
Почему: один файл, нулевой риск параллельности, verification очевиден
Задача: понять, где в Commerce OS собирается response для /api/dashboard/metrics.
Выбор: plan mode
Почему: сначала нужно исследование, edits пока не нужны
Задача: после implementation получить свежий взгляд на diff по orders API.
Выбор: основная сессия + fresh reviewer session
Почему: нужен новый контекст без writer bias
Все три примера полезны одним и тем же: они показывают, что рост сложности начинается не с «добавим ещё агентов», а с вопроса «какая у задачи реальная структура?»
5. plan mode против subagent
У многих на этом месте возникает честный вопрос: если plan mode тоже ничего не редактирует и умеет исследовать проект, зачем тогда subagent? Вопрос отличный, и всё дело в границе между режимом работы и отдельной ролью.
plan mode — это всё ещё ваша основная сессия: одна нить разговора с ограничением «сначала исследуем, без edits». Берите его, когда задача одна и отдельный worker не нужен.
Subagent же имеет смысл, когда investigation или review идут в отдельном context window и не засоряют main session: основная держит task spec и implementation context, а subagent собирает evidence по tests или проходит по API map и возвращает сжатый вывод.
Давайте сравним это в короткой таблице:
| Вариант | Что получает main session | Когда брать |
|---|---|---|
|
Полную нить исследования внутри той же сессии | Одна задача, один поток |
|
Короткую summary с findings и evidence | Отдельная investigation/review роль |
| Fresh session | Полностью новый взгляд | Нужна независимая интерпретация |
Вот небольшой пример для Commerce OS:
Задача: понять, почему metrics endpoint иногда медленный.
Если вы просто ещё не исследовали код — достаточно plan mode.
Если основная сессия уже занята implementation другой части и вы не хотите
тащить внутрь длинное исследование SQL и logs — логичен subagent.
Если implementation уже сделан и нужен независимый reviewer — fresh session.
Это различие важно почувствовать: без него subagent быстро превращается в «умный синоним любой разведки» — а это уже лишняя координация.
6. worktree идёт рядом с параллельными edits
Как только речь заходит о параллельных изменениях файлов, разговор сразу упирается в worktree. Не потому, что Git хочет вас воспитывать, а потому что файловая система не любит, когда несколько потоков разом считают себя хозяевами одних файлов.
Если у вас одна сессия, один diff, одна ветка — никакой драмы нет. А захотите два изменяющих потока (один правит backend, второй проверяет альтернативную реализацию) — без worktree вы очень быстро придёте к «а кто это поменял этот файл, и почему у меня теперь всё смешалось?»
Дело в том, что context isolation и file isolation — не одно и то же:
| Изоляция | Что защищает |
|---|---|
| Отдельная сессия | Историю рассуждений и контекст |
| Subagent | Main session от лишнего investigation |
|
Файлы, ветку и Git-состояние |
Поэтому полезно помнить простую формулу:
Если параллельность касается рассуждений — может хватить отдельной сессии.
Если параллельность касается edits — почти всегда нужен worktree.
Небольшой пример decision note:
Задача: сравнить две реализации фильтрации orders.
Вариант A: main session + одна ветка
Проблема: обе реализации будут менять те же файлы
Решение: завести отдельный worktree для альтернативной реализации
Почему: нужен безопасный параллельный diff без смешивания изменений
Да, worktree создаёт лишнюю работу — но это честная цена за изоляцию файлов. Куда хуже сэкономить на нём, а потом играть в Git-археолога.
7. Agent management surface против «зомби-сессий»
Как только у вас появляется больше одного параллельного workstream, проблема становится не технической, а операционной: как помнить, кто ещё жив, кто ждёт решения, кто закончил, а кто тихо ушёл в лес и утащил с собой контекст?
Именно для этого в современных версиях Claude Code появляется agent management surface — claude agents, agent view или похожий экран; имя и интерфейс могут меняться. Есть он у вас — используйте его. Нет — тот же эффект даёт короткий status note в Workflow Kit, issue note или task list. Важен принцип: единый экран статусов — какие сессии активны, сколько работают, кто их owner, где нужны human decisions.
Здесь важно зафиксировать простое правило:
С момента второго параллельного workstream нужен не обязательно отдельный экран, но обязательно явный способ видеть status, owner и pending decisions.
Почему это так жёстко? Потому что без этого появляются классические «зомби-процессы»:
- вы забыли, что где-то ещё живёт background session;
- один subagent завершился, но его findings никто не прочитал;
- одна из сессий уже двадцать минут ждёт решения, а вы успели уйти в другой поток;
- вы больше не помните, кто из параллельных workers работает с какой веткой или каталогом.
Можно нарисовать очень короткую схему:
flowchart LR
A[2+ параллельных workstreams] --> B[Нужен единый экран статусов]
B --> C[Видно ownership]
B --> D[Видно elapsed time]
B --> E[Видны pending decisions]
B --> F[Меньше зомби-сессий]
Поэтому профессиональная привычка выглядит просто: прежде чем запускать второй параллельный поток, договоритесь, где именно вы будете видеть status, owner и pending decisions.
8. Шаблон parallelism decision record
Чтобы всё сегодняшнее не осталось красивой теорией, давайте заземлим это в первый рабочий артефакт всей схемы — запись о том, нужна ли вообще параллельность. Она лежит в Workflow Kit как parallelism-decision.template.md. Шаблон очень короткий — и это хорошо: чем меньше церемонии, тем выше шанс, что его действительно будут применять.
# Решение по параллелизму
## Задача
<id / короткое описание>
## Размер
<small / medium / large>
## Независимые рабочие потоки
<yes / no / partial>
## Распределение ответственности
<files / modules / layers / flows / none>
## Риск
<low / medium / high>
## Доступная проверка
<tests / build / smoke / none>
## Выбранный уровень
<one session / plan mode / subagent / fresh session / worktree / background / agent team>
## Отклонённые варианты
- ...
- ...
## Обоснование
<2–4 строки>
И вот как он может выглядеть для реального issue:
# Решение по параллелизму
## Задача
COM-538 — исправить сортировку refund inbox
## Размер
medium
## Независимые рабочие потоки
no
## Распределение ответственности
none
## Риск
medium
## Доступная проверка
unit tests + smoke
## Выбранный уровень
one session + plan mode
## Отклонённые варианты
- subagent: отдельная роль не нужна
- worktree: нет параллельных edits
- agent team: нет независимых workstreams
## Обоснование
Нужно сначала локализовать причину бага и сделать маленький diff.
Параллельность не даст выигрыша, а только увеличит review cost.
Если verdict говорит «параллельность не нужна» — на этом вопрос закрыт. Если говорит «нужна», следующий вопрос становится жёстче: это отдельный reviewer или investigator либо уже более тяжёлая координация. Сначала вы фиксируете verdict, и только потом обсуждаете роли, pipeline и handoff.
И это, честно говоря, один из самых недооценённых навыков в AI-assisted разработке. Не запустить пять агентов — легко. Не запустить их, когда очень хочется, и при этом быть правым — вот это уже профессионализм.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ