Рівні паралельності до agent team

1. Один Claude часто кращий за маленьку «AI-команду»

Коли люди вперше доходять до теми multi-agent, їх майже завжди тягне переускладнити навіть просту задачу. Це абсолютно нормальна стадія. Приблизно як у новачка в спортзалі: техніку не поставив, а рукавички, пояс, браслет, розумний годинник і загадковий аксесуар дуже серйозних людей уже подумки обрав. Спочатку «красиво», потім — «правильно».

Після всієї карти skills, subagents, MCP і hooks це особливо небезпечно: інструменти вже під рукою, і рука сама тягнеться зібрати AI-оркестр там, де вистачило б одного виконавця. Тому змістіть запитання: не «що увімкнути», а «коли це виправдано».

За замовчуванням достатньо однієї основної сесії Claude. Усе інше потрібно виправдати задачею.

Це не нудне правило, а корисний фільтр. Один Claude уже читає код, працює в plan mode, вносить зміни, запускає перевірки, показує diff. Задача невелика, послідовна, в одному місці проєкту — subagent, окрема сесія або worktree її не пришвидшать, а лише додадуть рухомих частин.

Щоб не вирішувати «на емоціях», корисно проганяти задачу через ознаки:

Ось тут і зʼявляється перше доросле інженерне рішення: parallelism — це не «фіча», а design decision. Його ухвалюють до старту роботи, а не «по ходу, бо стало цікаво».

Для Commerce OS це виглядає дуже життєво. Issue рівня «виправити підпис у повідомленні про помилку в кошику» — а ви запускаєте planner, reviewer і background agent. Усе одно що викликати будівельну бригаду, щоб підправити криво повішену картину: картина, звісно, вразиться, але навряд чи оцінить.

2. Меню рівнів: від сесії до agent team

Щоб не плутатися, корисно сприймати варіанти не як хаос можливостей, а як обмежене меню: ви обираєте не «що модніше», а «що дешевше за координацією і достатньо для задачі». І речей тут дві: рівень координації та режими, які змінюють спосіб дослідження, ізоляції або виконання.

agent team

plan mode

worktree

Тобто 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 як на суму кількох компонентів.

Ось чому формула курсу звучить так:

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 і повертає стиснений висновок.

Давайте порівняємо це в короткій таблиці:

plan mode

subagent

Ось невеликий приклад для 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 — не одне й те саме:

worktree

Тому корисно памʼятати просту формулу:

Якщо паралельність стосується міркувань — може вистачити окремої сесії.
Якщо паралельність стосується 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[Видно відповідальність]
    B --> D[Видно час виконання]
    B --> E[Видно рішення, що очікують]
    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 розробці. Не запустити пʼять агентів — легко. Не запустити їх, коли дуже хочеться, і при цьому бути правим — ось це вже професіоналізм.