Multi-agent: правила й антикритерії

1. Три Claude не працюють утричі сильніше

Безпечний варіант за замовчуванням ви вже знаєте: один Claude, а паралельність спершу потрібно виправдати завданням. Тепер важливо не просто повторити це правило, а зробити його жорсткішим — прогнати ідею multi-agent через fitness check.

Найнебезпечніша ілюзія тут та сама: «Один Claude допомагає, отже три допоможуть утричі». Іноді так і є — але лише тоді, коли заздалегідь зрозуміло, хто що чіпає, як це перевіряється і де людина натискає стоп. Інакше кожен агент дає не прискорення, а coordination cost.

Нижче не нова теорія, а той самий coordination cost у практичному вигляді.

Тому хороше базове правило звучить дуже прозаїчно:

Чим більше агентів ви запускаєте, тим жорсткішими мають бути ownership, verification і human checkpoints.

Якщо завдання — виправити одну друкарську помилку в тексті кнопки, multi-agent не прискорює роботу. Він просто перетворює трисекундну правку на маленький корпоративний процес. Гарно? Можливо. Корисно — як мікросервіс для калькулятора чайових.

2. Пʼять запитань, які ставлять до запуску

Це все ще те саме перше інженерне запитання — чи потрібна паралельність взагалі, — лише у жорсткішій формі. Тепер нас цікавить не просто «чи можна розділити роботу», а чи витримає ця ідея ownership, verification і human bandwidth.

Ось проста схема, яку зручно тримати в голові перед стартом.

flowchart TD
    A[Є завдання] --> B{Є незалежні потоки роботи?}
    B -- ні --> C[Один Claude / plan mode]
    B -- так --> D{Можна розділити ownership?}
    D -- ні --> C
    D -- так --> E{Є зрозуміла окрема перевірка результату?}
    E -- ні --> F[Спершу додати safety net]
    E -- так --> G{Є ресурс на проміжні human decisions?}
    G -- ні --> C
    G -- так --> H[Multi-agent виправданий]

Тепер розкладемо це трохи спокійніше.

Зверніть увагу на четверте питання — воно про safety net. Не потрібні ані складний CI, ані повна система quality gates; достатньо мінімуму: зрозуміти, що результат однієї ролі не зламав результат іншої. Без нього multi-agent — як бригада ремонтників без рулетки: шуму багато, а результат потім переміряють вручну.

Пʼяте запитання новачки особливо люблять забувати. Ідеально розділена робота марна, якщо вам ніколи прочитати проміжні результати й вчасно сказати: «Стоп, спершу заморожуємо API-контракт». Multi-agent без human bandwidth — відкладена плутанина.

3. Коли паралельність чесно окупається

Якщо fitness check пройдено, зазвичай одразу видно і причину: робота реально бʼється на незалежні шматки, а не просто красиво перейменована в кілька ролей.

Гарний приклад із нашого Commerce OS — умовний issue COM-512, доопрацювання потоку замовлень. API-контракт зафіксований, backend і frontend розведені по каталогах, тести живуть окремо. Паралеляться три потоки: серверний код, інтерфейс, тестове покриття. Це незалежні workstreams, а не три красиві назви для одного завдання.

# Fitness check — COM-512

Independent workstreams? так
Ownership separable? так
Safety net available? так
Shared state low? так
Висновок: multi-agent is justified

Тут важливі не самі слова, а зміст. Backend owner сидить лише в src/api/orders/*, UI owner — лише в клієнтській частині замовлень, тестова роль чіпає окремі tests і не лізе в production-код. Ви не просите трьох «допомогти з фічею» — ви даєте кожному свій шмат території.

Друга чесна ситуація для multi-agent — паралельна перевірка конкурувальних гіпотез. Наприклад, у Commerce OS повільно відкривається екран метрик. Одна гіпотеза: річ у SQL-запиті. Друга: у повторних викликах зовнішнього клієнта. Два read-only investigation-потоки збирають evidence, кожен за своєю гіпотезою, а людина вирішує, чия переконливіша.

Третя зрозуміла зона — незалежні read-only review-ракурси. Якщо у вас уже готовий diff, іноді виправдано паралельно попросити одного reviewer-а подивитися на performance-ризик, а іншого — на test gaps. Ключове слово знову read-only: щойно обидва почали «трохи підправляти», це вже не review, а гонка за ownership.

Формула: multi-agent виправданий там, де окремо відповідаєш на три запитання — хто робить, що здає на виході, як це перевіряється окремо від усього іншого.

4. Один Claude — зріле рішення, а не слабкість

Правильний verdict часто звучить нудно: один Claude, один plan mode, одна акуратна серія змін — спосіб не платити coordination cost там, де паралельність декоративна. В інженерії нудне рішення дуже часто і є професійним.

Найочевидніший приклад — маленьке завдання. COM-518, правка тексту кнопки — verdict очевидний: single-agent.

Але малий розмір — не єдиний критерій. Завдання на 200–300 рядків теж погано паралелиться, якщо воно строго послідовне. Один PaymentService: спершу відтворити баг, потім знайти root cause, потім вибрати одну зміну в одному місці, потім перевірити побічний ефект. Потік роботи один. Multi-agent створить два конкурувальні diff’и в одному service-класі.

Ще один стоп-сигнал — нечіткий scope. Якщо ви самі поки не можете сформулювати, де проходить межа завдання, запускати ролі зарано. Часту помилку новачків: незрозумілий issue намагаються розбити об стіну з агентів. Не розумієте bug — почніть з reproduction, plan mode, пакета доказів і одного investigator-а. Інакше отримаєте кілька впевнених, але суперечливих пояснень однієї проблеми.

Особливо небезпечно запускати multi-agent як спосіб «колективно подумати» замість нормального task spec. Це схоже на ситуацію, коли людина не знає, куди їхати, і тому відкриває одразу три навігатори. Голосів більше — маршрут зрозумілішим не стане.

5. Shared state і порожній safety net душать паралельність

Красиві схеми найчастіше ламають дві речі: спільний змінюваний контекст і відсутність виразної перевірки. Shared state і відсутність tests — не нюанси, а повноцінні антикритерії.

Shared state — це ситуація, де ролі хоч і названі по-різному, але реально сидять на одній змінюваній поверхні. Найчастіший варіант — один файл або модуль. Трохи менш очевидний — спільний контракт: два агенти правлять різні частини проєкту, але обидві залежать від одного ще не зафіксованого API. На папері ownership розділений, а гіпотеза однієї ролі миттєво змінює вхідні дані для іншої.

Уявіть, що ви хочете винести OrderRefundService з великого OrderService, але characterization tests ще немає і незрозуміло, які методи — публічний контракт. Формально: «Один рефакторить, другий пише тести». На практиці другий пише тести на поверхню, яку перший просто зараз змінює. Не незалежні потоки, а двоє людей на одній драбині.

Без safety net проблема посилюється вдвічі: два результати вже не порівняти. Обидва переконливі, обидва зі зведеннями, але який зламав поведінку — немає за що зачепитися, окрім відчуття. Multi-agent лише підвищує швидкість виробництва впевнено оформлених помилок.

У реальній роботі корисно памʼятати дуже жорстке правило: shared state високий, перевірка слабка — спершу не агенти, а ізоляція або сильніший verification.

6. Fitness check як короткий артефакт

Щоб не ухвалювати такі рішення на емоціях, корисно перетворити їх на короткий інженерний артефакт — не новий документ поруч із Parallelism Decision, а його коротку форму для Workflow Kit.

Зручно тримати маленький шаблон, наприклад workflow-kit/snippets/multi-agent-decision-template.md:

task: COM-512
size: large
workstreams_independent: yes      # backend, UI і tests розведені
ownership_split_by: modules
tests_available: unit
shared_state_risk: low
verdict: multi-agent

Цей шаблон хороший тим, що змушує вас сформулювати рішення коротко й по суті.

Для завдання, де multi-agent не виправданий, заповнення буде ще коротшим, і це нормально:

task: COM-518
size: small
workstreams_independent: no
ownership_split_by: none
tests_available: n/a
shared_state_risk: low
verdict: single-agent

Цей запис не конкурує з Parallelism Decision: потрібен повний reasoning — залишайте record, verdict очевидний — вистачить shorthand.

На практиці такий шаблон можна зберігати не лише окремим файлом: для маленьких завдань вставляйте рядки в PLAN.md, у нотатку до issue або в опис PR. Сенс не в бюрократії — рішення стає явним, і менше спокуси через годину сказати: «Давайте докинемо ще одного агента, раз уже почали».

І ще один корисний ефект: якщо фіксувати такі рішення регулярно, почнете бачити повторювані патерни. Наприклад, усі завдання з shared_state_risk: high стабільно йшли краще в single-agent. Уже не інтуїція, а інженерна практика.

7. Ціна координації, яку новачки не бачать

Новачки помічають лише витрату токенів — найочевидніший лічильник. Але coordination cost ширший: multi-agent просить не тільки обчислень, а й уваги. Не готові до цього — автоматизація не рятує, а швидше виробляє хаос.

Особливо підступна ціна перемикання уваги. Один Claude у main session тримає один ланцюжок думки. Три агенти дають три ланцюжки, між ними треба постійно стрибати. Через якийсь час ловиш себе на тому, що вже не памʼятаєш, який output фінальний, який чернетка і хто працював на старій версії assumptions. Це не проблема продукту, а природна ціна паралелізму.

Є ще ефект хибного консенсусу. Якщо дати всім ролям слабкий task spec, два агенти незалежно повторять одну хибну ідею. Ззовні це виглядає переконливо: «Дивись, обидва дійшли одного висновку» — але обидва читали один поганий input: не підтверджують один одного, а однаково помилилися.

Невелика памʼятка тут корисніша за будь-яку мотиваційну промову:

Є дуже чесне правило, яке одразу ставить усе на місце: якщо у вас немає часу прочитати три проміжні звіти, у вас немає часу на multi-agent. Красивою назвою ролі цю вартість не скасувати.

8. Як записати професійний verdict

Корисно вміти писати короткий verdict без почуття провини. Не «ми не подужали multi-agent», а «multi-agent тут не потрібен». Це все той самий перший артефакт — у PLAN.md, issue note або PR description.

Для single-agent рішення вистачить буквально кількох рядків:

## Рішення щодо паралелізму
Завдання: COM-518
Висновок: single-agent
Причина: невелика послідовна зміна в одному файлі
Відхилено: subagent, worktree, multi-agent

Для завдання, де multi-agent справді виправданий, запис може бути ненабагато довшим:

## Рішення щодо паралелізму
Завдання: COM-512
Висновок: multi-agent
Поділ: backend/orders, frontend/orders, tests/orders
Людська контрольна точка: before merge

Зверніть увагу, що в обох версіях є пояснення, а в другій — обовʼязковий human checkpoint: multi-agent не знімає з людини фінальне рішення, лише змінює форму його підготовки.

Але тут зʼявляється наступна розвилка. Verdict multi-agent ще не означає цілу team-схему. Іноді вистачає одного investigator-а або reviewer-а. А іноді завдання вже потребує lead, handoff і спільного task list.

Навчіться писати такий verdict за тридцять секунд — і multi-agent перестане бути феєрверком. Він стане звичайним робочим інструментом, який вмикають лише тоді, коли він окупається. Один Claude, fitness check, короткий запис рішення — ось база, на якій паралельність із красивої ілюзії стає інженерним вибором.