Як масштабувати AI-кодувальні агенти в команді розробників

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

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

Що далі - це порядок відмов. Не список найкращих практик в абстрактному вигляді, а послідовність, в якій речі насправді ламаються, тому що виправлення їх у неправильному порядку витрачає чверть.

Що ламається першим: спільний контекст

Кожен розробник, який запускає агента, тихо навчає його своїй версії кодової бази.

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

Виправлення нудне, але це найефективніша річ на цій сторінці. Помістіть конвенції у файл, закомітьте файл.

CLAUDE.md для Claude Code, AGENTS.md для Codex і більшості інших CLI агентів, і на практиці багато команд зберігають один переносний файл контексту замість підтримки двох, які розходяться. Механізм важливіший за ім'я файлу: інструкції живуть у репозиторії, тому вони прибувають з git pull, а не через того, хто випадково був у кімнаті.

Що повинно бути в ньому:

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

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

Корисний тест перед додаванням рядка: якщо колега витягне це, чи допоможе це йому, чи зламає його?

Що ламається другим: два агенти, один файл

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

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

Два механізми виправляють це, і вам потрібні обидва.

Ізоляція. Git worktrees дають кожному завданню власну копію репозиторію, тому паралельні агенти фізично не можуть зіткнутися. Це дешева половина рішення, і немає причин не робити цього.

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

Друга половина - це те, що команди пропускають, і це те, що визначає, чи є злиття формальністю чи післяобіднім заняттям.

Що ламається третім: перегляд

Все, що стосується перегляду на командному рівні, випливає з одного числа: скільки дифів прибуває на годину.

Один розробник, який читає кожен рядок, працює нормально. П'ять розробників, які запускають чотири агенти кожен, генерують більше дифів на день, ніж команда може прочитати, і чесний результат - це не ретельний перегляд, це театральне схвалення. Людина, яка швидко переглядає дев'ятисотрядковий диф о 18:00, ставить підпис, не отримуючи знань, що гірше, ніж не переглядати, тому що це створює впевненість там, де її немає.

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

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

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

Що ламається четвертим: вартість і розмова про вартість

Витрати на токени перестають бути особистою деталлю в момент, коли вони з'являються у командному рахунку.

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

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

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

Що насправді змінюється в ритуалах команди

Три речі, за нашим досвідом і за тим, що повідомляють команди.

Статус на стендапі змінюється на розблокування. Те, що кожна людина робила вчора, в основному видно в гілках. Що варте п'яти хвилин - це які агенти застрягли і на чому.

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

Спеціалізація переходить від людей до ролей. Коли агенти займаються написанням, цікавим питанням стає, хто переглядає що, і команди природно дрейфують до призначення ролей агентам так само, як вони призначають їх людям: один на реалізацію, один на перегляд, один на тести. Це ідея Agent Teams, де завдання передається від ролі розробника до ролі QA з дифом, ризиками і підказками тестів, і якісні ворота визначаються вашим тестовим набором, а не власною думкою агента про свою роботу.

Налаштування, яке тримається

Сконденсовано, в порядку, який має значення:

Перші чотири не коштують нічого, крім згоди. Останні два - це причина, чому команда в кінцевому підсумку хоче щось вище терміналу: не тому, що термінали погані, а тому, що термінал показує одного агента за раз і не дає вам можливості відповісти на питання "хто що запускає, на якому проекті, прямо зараз".

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

Але почніть з файлу контексту. Це безкоштовно, це займає один день, і це знімає більше тертя, ніж будь-який інструмент, який ви можете встановити цього кварталу.