Паралелізм: коли більше виконавців допомагає, а коли заважає

Коли робіт накопичилося багато, спокуса проста: роздати її кільком виконавцям і чекати на швидший результат. Але п’ять активних агентів не означають п’ятикратної швидкості. Якщо вони залежать один від одного, змінюють спільні файли або чекають на одну чергу перевірки, додаткові виконавці можуть лише перенести очікування та помилки в інтеграцію.

Навчальний результат. Після цієї глави читач відрізняє перекриття робіт від фактичного паралельного виконання; визначає незалежні частини й критичний шлях; помічає спільні ресурси та межі їхньої ізоляції; рахує умовну економію часу разом із накладними витратами; перевіряє результат на об’єднаній ревізії та вимірює час до прийнятого результату, а не кількість одночасно запущених виконавців.

Передумови. Глава спирається на графи залежностей із глави 20, делегування з глав 38–40 і командні межі з глави 41. Окремі робочі дерева Git розглядаються докладно в главі 47. Вибір моделі належить наступній главі 43, а повну економіку студії розбирає глава 70.

42.1. Робота перекривається чи виконується паралельно?

Послідовне виконання означає, що наступна робота починається після завершення попередньої. Паралелізм (parallelism) означає, що кілька робіт справді виконуються одночасно на окремих доступних обчислювальних потужностях — наприклад, на різних ядрах центрального процесора чи машинах. Різні середовища можуть ізолювати стан, але якщо вони ділять процесор, чергу чи інший вузький ресурс, саме розділення середовищ не створює паралельного обчислення.

Конкурентність (concurrency) означає, що кілька робіт просуваються в той самий проміжок часу, хоча в кожну конкретну мить ресурс може переходити від однієї роботи до іншої. На одному процесорі програма може чергувати кілька задач: вони перекриваються за часом, але не обчислюються одночасно. Людина теж може паралельно «вести» кілька запитів, перемикаючись між ними; саме перемикання не створює додаткового часу для зосередженої роботи.

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

Тому розділяймо три результати:

• Активність: виконавець зайнятий або чекає на відповідь.
• Завершена одиниця роботи: виконавець надав результат, який можна перевірити.
• Прийнятий інтегрований результат: перевірку пройшла спільна ревізія, до якої включено всі потрібні зміни.

Збільшення активності не гарантує збільшення двох останніх результатів.

42.2. Коли задачі справді незалежні?

Назви задач не доводять, що між ними немає залежностей. «Оновити клієнт» і «оновити сервер» звучать як дві роботи, але їх може пов’язувати один формат відповіді. Якщо сервер змінить назву поля, а клієнт не знає про це рішення, обидві гілки можуть завершитися окремо, а продукт — зламатися після об’єднання.

Перед роздачею роботи домовтеся про контракт. У ньому варто зафіксувати:

1. Спільну ціль і критерій завершення. Який спостережуваний результат приймається?
2. Передумови й залежності. Що має бути відомим або завершеним до початку?
3. Межі власності. Які файли, модулі, схеми, сервіси чи дані належать кожному виконавцеві?
4. Форму результату. Наприклад, перелік перевірених знахідок із посиланнями на файл і рядок або зміну з описаним контрактом.
5. Власника інтеграції. Хто звірить результати, розв’яже суперечності й відповідає за спільну перевірку?
6. Спільний стан і дозволені дії. Чи може робота змінити базу даних, чергу, конфігурацію, гілку або реальне середовище?

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

Офіційні матеріали Codex та Claude Code радять роздавати незалежні дослідження, а для одночасного редагування спільного коду враховувати конфлікти й координацію. Це корисне продуктове настановлення, а не обіцянка певного прискорення Codex: субагенти, Claude Code: субагенти.

Повністю розібраний випадок: три пошуки та три реалізації

Команда хоче зрозуміти, чи можна прибрати застарілий статус «чернетка» з каталогу. Спершу можна роздати три обмежені пошуки:

• один виконавець знаходить місця, де статус записується;
• другий — читачів і фонові процеси, які залежать від статусу;
• третій — тести й документацію, що фіксують його поведінку.

Усі працюють лише для читання на одній і тій самій ревізії. Вони повертають шлях до коду, доказ залежності та невизначеність. Оркестратор порівнює знахідки, перевіряє критичні місця й лише потім вирішує, як змінювати код. Пошуки можуть іти паралельно, бо результат одного не є вхідною умовою для іншого. Їх зведення все одно потребує власника.

Тепер припустімо, що три виконавці паралельно реалізують видалення статусу. Один змінює модель даних, другий — інтерфейс, третій — імпортер, і кожен сам виводить новий формат. Це вже три реалізації спільної поведінки, а не три незалежні частини. Погоджений контракт і неперетинні межі можуть відкрити паралельну роботу; без них найімовірніше доведеться зводити несумісні припущення. Якщо межі не піддаються поділу, один виконавець реалізує цілісну зміну, а другий незалежно перевіряє поведінку.

42.3. Fan-out, fan-in і критичний шлях

Fan-out (роздавання) — це поділ роботи між виконавцями після визначення меж. Fan-in (зведення) — повернення результатів до власника інтеграції для порівняння, об’єднання та перевірки. У главі 40 розглянуто ці кроки як частину оркестрації; тут важливо порахувати, яка частина часу може зникнути після роздавання, а яка залишиться в спільній черзі.

Граф залежностей показує, що має завершитися перед початком іншої роботи. Критичний шлях — найтриваліший ланцюг залежних робіт, який визначає найраніший можливий час завершення всього результату. Роботи поза цим ланцюгом можуть утворити паралельні гілки, але їхнє приєднання до спільного результату все одно потребує інтеграції.

Розгляньмо умовну зміну імпорту товарів. Спершу команда 20 хвилин узгоджує й застосовує оновлення схеми даних. Після цього одну незалежну частину можна виконувати 35 хвилин, а іншу — 30 хвилин. Завершення потребує 25 хвилин спільної інтеграції, перевірки й людського огляду.

Етап	Якщо працювати послідовно	Якщо незалежні частини виконуються паралельно
Оновлення схеми, яке розблоковує обидві частини	20 хвилин	20 хвилин
Зміна відображення імпортованого запису	35 хвилин	35 хвилин одночасно з наступним рядком
Адаптер імпорту за вже погодженим контрактом	30 хвилин	30 хвилин одночасно з попереднім рядком
Спільна інтеграція, перевірка й огляд	25 хвилин	25 хвилин після готовності обох частин
Узгодження меж, зведення гілок і додатковий час у черзі перевірки	0 хвилин у базовій оцінці	10 хвилин, умовне припущення
Загальний час до прийнятого результату	110 хвилин	90 хвилин

У цьому прикладі ідеальний час без додаткових накладних витрат дорівнює 20 + max(35, 30) + 25 = 80 хвилин. Із прийнятим припущенням про 10 хвилин узгодження та зведення виходить 90 хвилин. Це на 20 хвилин, або приблизно на 18,2%, менше за послідовну оцінку 110 хвилин.

Ці цифри — навчальна модель, а не результат вимірювання чи прогноз для реальної команди. Вона припускає, що дві зміни справді незалежні, можуть початися після оновлення схеми, мають достатньо ресурсів і не збільшують час інтеграції. За цими умовами паралельна робота потребує приблизно 120 людино-хвилин: 20 + 35 + 30 + 25 + 10. Послідовна базова оцінка становить 110 людино-хвилин. Отже, календарний час у моделі зменшується, а сумарні зусилля збільшуються.

Якщо після зведення з’явиться ще 25 хвилин несумісної поведінки, підсумок сягне 115 хвилин. Паралельний план тоді програє послідовному. У міру того як спільна частина й накладні витрати зростають, перевага коротшої паралельної гілки зникає.

42.4. Паралельна робота не ізолює спільний стан

Дві окремі розмови чи середовища не обов’язково означають дві окремі копії кожного ресурсу. Планувальник має перевірити, що саме спільне:

• файл, схема даних, тип, параметр конфігурації або згенерований файл;
• база даних, тестові записи, порт чи тимчасовий каталог;
• мережеве обмеження, черга збірки або ліміт викликів інструмента;
• гілка, об’єкт Git, обліковий запис або секрет;
• людина, якій треба передати незавершений результат для рецензії.

Робоче дерево (worktree) Git — окрема робоча копія для перевірки іншої гілки. Воно зменшує ризик, що кілька виконавців випадково перезапишуть файли одне одного, але дерева все одно належать одному репозиторію та спільно використовують об’єкти й більшість посилань на гілки. Робочі дерева не розділяють зовнішню базу даних, мережеву чергу чи доступ до облікового запису. Деталі й команда роботи з ними розглядаються в главі 47 Git: git-worktree.

Добирайте контроль до ресурсу:

• Для коду визначте власників файлів і розділіть реалізацію за межами, які можна перевірити.
• Для схеми чи публічного контракту призначте одного власника рішення або спершу погодьте спільну версію. Для міграцій бази даних визначте порядок і версію схеми, потрібну залежним змінам. Якщо міграція змінює спільний стан чи не сумісна з обома версіями, виконуйте її по черзі й запускайте залежну роботу після погодженого етапу.
• Для тестової бази ізолюйте записи за простором імен, окремими базами чи транзакціями, якщо система це дозволяє. Якщо операція змінює єдиний спільний стан, виконуйте її по черзі.
• Для конфігурації, згенерованих файлів і спільних гілок домовтеся, хто їх змінює. Саме розділення потоків не встановлює такого правила.
• Для доступів виділяйте лише потрібні межі й середовища. Не потрібно блокувати всі паралельні роботи, якщо достатньо відокремити конкретний конфліктний ресурс.

Ці книги описують людей і команди, тому не вимірюють пропускну здатність агентів. Їхні ідеї тут задають запитання для процесу: Brooks спонукає врахувати координацію й передавання роботи в повній оцінці; Peopleware — захистити час людського рецензента від потоку дрібних переривань, зібравши докази до огляду; Team Topologies — зафіксувати власника контракту й організувати співпрацю навколо точок, де межі перетинаються. Це евристики дизайну, а не кількісні закони для штучного інтелекту; їхній ефект потрібно виміряти в конкретному процесі. Повніше людський контекст розібрано в [главі 41](41-human-teams-expertise-and-specialist-agents.md).

42.5. Інтеграція перевіряє спільний результат

Інтеграційна перевірка відповідає на запитання, чи працюють зміни разом. Автоматичне об’єднання гілок не означає, що Git зрозумів призначення коду: він може без конфлікту поєднати правки в різних рядках, хоча нова поведінка несумісна. Текстовий конфлікт повідомляє про частину правок, яку Git не зміг узгодити автоматично; відсутність конфлікту нічого не доводить про сумісність контракту чи правильність роботи програми Git: git-merge, GitHub: конфлікти злиття.

Повністю розібраний випадок: дві зелені гілки ламають клієнт

Це навчальний приклад. У сервісі профілів сервер раніше повертав поле «items». Власник контракту вирішив перейти на «results».

1. У гілці сервера розробник змінює відповідь на «results» і перевіряє сервер локально.
2. В іншій гілці розробник додає новий список профілів у клієнті. Тест клієнта використовує зафіксовану відповідь зі старим полем «items».
3. Кожна гілка окремо проходить свої перевірки. Файли змінені в різних місцях, тому Git може об’єднати гілки без конфлікту.
4. Після злиття сервер віддає «results», клієнт шукає «items» і показує порожній список. Комбінацію поведінок окремо не перевіряли.

Щоб виправити процес, власник контракту спершу фіксує форму відповіді. Якщо треба зберегти сумісність, сервер тимчасово повертає обидва поля або вводить версію відповіді й задає порядок переходу клієнта. Потім спільна перевірка запускає сервер і клієнт разом проти тієї самої схеми на об’єднаній ревізії. Перевірка має підтвердити спостережуваний результат — клієнт показує надіслані записи — а не лише успіх окремої збірки.

Якщо інтерфейс неможливо змінити поступово, зміни зводять у координованому порядку й залишають випуск заблокованим, доки спільний контракт не перевірено. Такий процес не вимагає, щоб усі команди завжди працювали послідовно. Він додає одну явну точку перевірки саме там, де гілки зустрічаються.

Реальний, але обмежений випадок: два субагенти виконали один виклик

У липні 2026 року користувач відкрив у GitHub проєкті oh-my-openagent issue про те, що один виклик завдання іноді породжував дві сесії субагентів із тим самим запитом у тій самій робочій копії. У звіті наведено журнали запуску й три випадки накладання; в одному з них дві сесії 15 хвилин 51 секунду змінювали ті самі шість файлів і майже одночасно виконували git add та git commit. Це конкретне повідомлення користувача про одну систему, а не вимір частоти такої помилки чи середньої продуктивності агентів issue #6487.

Пов’язаний pull request пропонував під час повтору спершу завершити попередню сесію, а потім створювати заміну. У відкритій версії пропозиції рецензент окремо звернув увагу, що якщо скасування помиляється або спливає тайм-аут, код усе одно може перейти до створення нової сесії. На дату перевірки пропозиція залишалася відкритою pull request #7223. Отже, команда має перевіряти сам перехід стану: повторний виклик не повинен залишати старого виконавця активним поруч із новим. Підтвердження відправленої команди скасування саме по собі не доводить, що спільні дії припинилися.

42.6. Вузьким місцем може бути не генерація

Паралельний план обмежений найдефіцитнішим потрібним ресурсом. Це може бути не модель:

• ліміт запитів моделі чи інструмента;
• очікування відповіді мережі або зовнішнього сервісу;
• процесор (CPU — central processing unit, центральний процесор) чи оперативна пам’ять (RAM — random-access memory), яких не вистачає для одночасних локальних збірок;
• черга безперервної інтеграції (CI — Continuous Integration, автоматичні збірки й перевірки змін);
• тестове середовище, яке може безпечно використовувати лише один процес;
• людське рев’ю, якому треба прочитати, порівняти й прийняти всі результати.

Не прирівнюйте кількість дозволених потоків агентів до пропускної здатності сервісу. Наприклад, поточна документація Codex описує налаштування максимальної кількості паралельно відкритих потоків субагентів, але залишає вибір значення за замовчуванням самому Codex. Документація Claude Code вказує стандартний ліміт у 20 одночасно активних субагентів, запущених вбудованим інструментом делегування Agent, у версіях від 2.1.217. Інші механізми, зокрема forks і команди агентів, мають окремі правила. Ці ліміти залежать від продукту та версії, не є взаємозамінними й не описують тарифні обмеження моделі або швидкість людської перевірки Codex: налаштування субагентів, Claude Code: паралельна робота агентів.

У Claude Code винятки важливі навіть усередині одного продукту: вбудований /subtask створює окремий fork поточної сесії й займає слот, але не блокується лімітом паралельних викликів інструмента Agent. Відновлення завершеного субагента також може зайняти новий слот без перевірки цього ліміту, тоді як групи агентів і workflow-сеанси мають власні обмеження. Тому числове значення треба читати разом з описом конкретного механізму й версії, а не переносити на всі види паралельної роботи Claude Code: паралельна робота агентів.

Якщо команда встигає створити десять змін за годину, але перевіряє лише дві, черга просто зростає. Неперевірена гілка ще не є завершеною роботою. Так само більше одночасних локальних збірок може подовжити кожну з них, якщо процесор або пам’ять уже зайняті.

42.7. Затримка, зміна контракту й повторна спроба

План має працювати й тоді, коли один виконавець запізнюється, передумови змінюються або частина задачі виявляється дубльованою.

• Затримка. Перевірте, чи може незалежна завершена частина перейти до інтеграції. Якщо без затриманої частини результат непридатний, не називайте його готовим лише через активність інших гілок.
• Зміна контракту. Зупиніть залежні частини, опублікуйте нову версію контракту й позначте, які результати треба переглянути. Не інтегруйте зміни, побудовані на застарілому припущенні.
• Дублювання. Перед повтором з’ясуйте, чи попередній виконавець завершився і чи його записи або зовнішні дії вже відбулися. Спочатку зупиніть або ізолюйте старий процес, потім створюйте заміну.
• Частковий успіх. Збережіть перевірені результати з ревізією або іншим точним посиланням на джерело. Відкиньте лише застарілу чи неперевірену частину, а потім скоригуйте залежності.
• Спільна операція. Якщо її не можна безпечно повторити або розділити, виконуйте її серіалізовано: наступний крок починається лише після підтвердження попереднього.

Після переривання або скасування звіряйте фактичний стан файлів, бази й черги. Повідомлення «скасовано» може з’явитися раніше, ніж зупиниться зовнішня побічна дія. Це особливо важливо, якщо дві сесії користуються спільною робочою копією чи тестовими даними.

42.8. Як обрати корисний ступінь паралелізму

Починайте з потрібного результату й порівнюйте плани за однаковими умовами. Для декількох репрезентативних змін зафіксуйте початкову ревізію, критерії приймання й межу завершення: результат зараховано лише після спільної перевірки та людського рев’ю. Потім порівняйте послідовний і паралельний варіанти за такими показниками:

• час від початку до прийнятого результату;
• витрачений час людей на постановку, зведення, рев’ю та виправлення;
• кількість повторів і скасованих спроб;
• текстові конфлікти та несумісності поведінки після інтеграції;
• помилки, знайдені під час спільної перевірки;
• час очікування на модель, інструмент, середовище або рецензента;
• витрачені токени за моделями та агентами й фактичну вартість викликів, якщо сервіс надає такі дані.

Не змінюйте одночасно задачу, критерій якості, середовище й склад виконавців, а потім не приписуйте різницю лише паралельності. Маленьке вимірювання — це опис його умов, а не універсальний відсоток для всіх типів робіт.

Коли три незалежні пошуки справді скорочують очікування, поверніть їхні результати одному власникові для зведення. Коли кілька змін залежать від одного нестабільного контракту, спершу стабілізуйте контракт або виконуйте залежну частину по черзі. Якщо спільна перевірка чи людське рев’ю вже повністю завантажені, додаткові виконавці не прискорять прийняття результату: спочатку треба зменшити розмір порцій або усунути чергу.

Короткий підсумок

Паралельна робота допомагає, коли частини незалежні, мають чіткі межі й достатні ресурси, а власник може перевірити їх разом. Вона скорочує лише частину графа, яка справді може перекриватися; послідовні залежності, спільний стан, інтеграція та рев’ю залишаються. Тому вимірюйте час до прийнятого результату та сумарні зусилля, а безпечно спільні операції виконуйте по черзі.

Джерела та подальше читання

• OpenAI, Subagents in ChatGPT and Codex. Актуальна сторінка документації; дата публікації не зазначена. Перевіряє паралельні потоки Codex, рекомендації щодо read-heavy та write-heavy робіт, витрати токенів і налаштування лімітів. URL. Доступ: 2026-09-24.
• Anthropic, Create custom subagents. Актуальна документація Claude Code; дата публікації не зазначена. Підтримує опис незалежного дослідження, послідовного делегування, окремого контексту та версійно-залежного ліміту Agent-tool. URL. Доступ: 2026-09-24.
• Anthropic, Orchestrate teams of Claude Code sessions. Актуальна документація Claude Code; дата публікації не зазначена. Вказує на накладні витрати команд і ризик спільного редагування одного файла. URL. Доступ: 2026-09-24.
• Git, git-worktree. Чинний довідник Git. Пояснює кілька робочих копій і спільні посилання Git між ними. URL. Доступ: 2026-09-24.
• Git, git-merge. Чинний довідник Git. Пояснює автоматичне злиття, текстові конфлікти та ручне узгодження несумісних змін. URL. Доступ: 2026-09-24.
• GitHub Docs, Merge conflicts. Актуальна довідка; пояснює, коли GitHub блокує злиття через конфлікт гілок. URL. Доступ: 2026-09-24.
• niStee, [Bug]: Single task() invocation spawns duplicate parallel subagent sessions in same worktree, issue #6487 у oh-my-openagent. Відкрито 2026-07-30. Первинне, але одиничне свідчення дубльованого запуску й спільного редагування. URL. Перевірено: 2026-09-24.
• AceRothstein71, fix(delegate-task): abort superseded sync session before fallback retry spawn, pull request #7223 у oh-my-openagent. Відкрито 2026-08-24; залишався відкритим на дату перевірки. Описує причину повторного запуску; обговорення містить зауваження щодо тайм-ауту скасування. URL. Перевірено: 2026-09-24.
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, 2nd ed. Офіційні матеріали видавця й зміст; людські аргументи та обмеження обговорюються в главі 41. Не є доказом продуктивності AI-агентів. URL. Доступ: 2026-09-24.
• Tom DeMarco, Timothy Lister, Peopleware: Productive Projects and Teams, 3rd ed. Офіційні матеріали видавця й зміст; людський контекст обговорюється в главі 41. URL. Доступ: 2026-09-24.
• Matthew Skelton, Manuel Pais, Team Topologies: Key Concepts. Матеріал авторів про межі команд і взаємодію; застосовано як дизайн-лінзу, а не кількісний прогноз паралелізму. URL. Доступ: 2026-09-24.