Как масштабировать AI кодирующих агентов на команду разработчиков

Один разработчик с кодирующим агентом: это история о продуктивности. Ее легко рассказать, она хорошо демонстрируется и действительно правдива.

Пять разработчиков с двадцатью агентами: это совсем другое дело. Это проблема координации, и проблемы координации не решаются инструментом, который их создал. Об этом никто не пишет, потому что это проявляется только после фазы энтузиазма: индивидуальные достижения реальны, они приходят сразу, а затем где-то на третьем или четвертом разработчике команда начинает тратить свою новую скорость на уборку за собой.

Далее следует порядок сбоев. Это не список лучших практик в абстрактном виде, а последовательность, в которой вещи действительно ломаются, потому что исправление их в неправильном порядке тратит четверть времени впустую.

Что ломается первым: общий контекст

Каждый разработчик, использующий агента, тихо обучает его своей версии кодовой базы.

Один человек говорит своему агенту, что проект использует серверные действия и никогда не использует API-маршруты. Другой никогда не упоминает об этом, поэтому его агент пишет API-маршруты. Третий упоминает об этом один раз, в сессии, которая закончилась три дня назад. Никто не ошибается, никто не лжет, и теперь в репозитории содержатся три интерпретации одного и того же соглашения. Вы заметите это в очереди на проверку, что является неправильным местом для этого: к тому времени код уже существует.

Исправление скучно, но это самое эффективное действие на этой странице. Запишите соглашения в файл, зафиксируйте файл.

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

Что должно в нем быть:

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

Что не должно в нем быть, и это то, где команды обжигаются: что-либо специфичное для одной машины. Абсолютные пути, личные API-токены, локальные порты, предпочитаемый редактор кого-то. В момент, когда специфичное для машины значение попадает в зафиксированный файл контекста, каждый другой разработчик наследует настройку, которая для него неверна, и агенты чрезвычайно хорошо следуют инструкциям, которые больше не применимы.

Полезный тест перед добавлением строки: если коллега извлечет это, поможет ли это ему или сломает его?

Что ломается вторым: два агента, один файл

Агенты не ведут переговоры. Они не проверяют, не редактирует ли кто-то другой в данный момент. Два агента, направленные на один и тот же модуль, будут перезаписывать друг друга, и ни один из них не упомянет об этом, потому что с точки зрения каждого работа была успешно завершена.

В одиночку это невидимо. Вы запускаете одного агента за раз, или вы запускаете несколько, и они случайно касаются разных вещей. В команде это становится структурной проблемой и производит худший класс ошибок: работа, которая тихо исчезает между двумя успешными тестовыми запусками.

Два механизма исправляют это, и вам нужны оба.

Изоляция. Git worktrees дают каждой задаче свою собственную копию репозитория, так что параллельные агенты физически не могут столкнуться. Это дешевая половина решения, и нет причин не делать этого.

Владение. Изоляция предотвращает перезапись, но не предотвращает решение одной и той же проблемы дважды, в двух ветках, двумя несовместимыми способами. Это решается на этапе назначения, путем ограничения каждой задачи набором файлов и указания этого в самой задаче. Не "улучшить процесс оформления заказа", а "изменить шаг оплаты, в этих трех файлах, не трогать корзину".

Вторая половина: это то, что команды пропускают, и именно она определяет, будет ли слияние формальностью или займет весь день.

Что ломается третьим: проверка

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

Один разработчик, читающий каждую строку, работает нормально. Пять разработчиков, каждый из которых запускает четырех агентов, генерируют больше диффов в день, чем команда может прочитать, и честный результат: это не тщательная проверка, а театральное одобрение. Человек, бегло просматривающий девятисотстрочный дифф в 6 вечера, ставит подпись, не получая знаний, что хуже, чем отсутствие проверки, потому что это создает уверенность там, где ее нет.

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

Это заслуживает отдельного разговора, и мы написали об этом отдельно: следует ли вам все еще проверять код вашего AI-агента рассматривает десять объективных признаков того, что изменение прошло неправильно, и таблицу радиуса взрыва, которую команды могут принять как есть.

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

Что ломается четвертым: стоимость и разговор о стоимости

Расход токенов перестает быть личной деталью в тот момент, когда он появляется в командном счете.

Ловушка в том, что счет ежемесячный и совокупный, поэтому разговор, который он вызывает, также ежемесячный и совокупный, что означает, что он производит политику вместо исправления. Кто-то предлагает более дешевую модель для всех. Кто-то другой предлагает ограничить сессии. Оба: догадки.

Фактическое распределение почти никогда не является равномерным. Это небольшое количество длительных сессий, на одном или двух проектах, с контекстом, который рос весь день и никогда не сбрасывался. Это исправляемое поведение, и вы можете исправить его только в том случае, если сможете увидеть расходы по сессии и по проекту, а не по месяцу. Мы рассмотрели механику этого в как проверить использование токенов и как сократить его без замедления.

Сделайте число видимым для людей, которые его генерируют, прежде чем оно станет темой для обсуждения на уровне управления. Разработчик, который видит, что одна сессия стоила больше, чем весь его предыдущий день, меняет свои привычки самостоятельно, и это ничего не стоит команде в политическом плане.

Что действительно меняется в ритуалах команды

Три вещи, по нашему опыту и по отчетам команд.

Стендап смещается от статуса к разблокировке. То, что каждый человек сделал вчера, в значительной степени видно в ветках. Что стоит пяти минут: это какие агенты застряли и на чем.

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

Специализация перемещается от людей к ролям. Как только агенты берут на себя написание, интересный вопрос: кто что проверяет, и команды естественным образом склоняются к назначению ролей агентам так же, как они назначают их людям: один на реализацию, один на проверку, один на тесты. Это идея Команд агентов, где задача передается от роли разработчика к роли QA с диффом, рисками и подсказками для тестов, и контроль качества определяется вашим набором тестов, а не собственным мнением агента о своей работе.

Настройка, которая держится

Сжато, в порядке, который имеет значение:

Первые четыре не стоят ничего, кроме согласия. Последние два: это причина, по которой команда в конечном итоге хочет что-то выше терминала: не потому, что терминалы плохи, а потому, что терминал показывает одного агента за раз и не дает вам возможности ответить на вопрос "кто что запускает, на каком проекте, прямо сейчас".

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

Начните с файла контекста. Это бесплатно, занимает один день, и устраняет больше трений, чем любой инструмент, который вы можете установить в этом квартале.

Часто задаваемые вопросы

Как использовать кодирующих агентов на всю инженерную команду?

Начните с контекста, а не с инструментов. Зафиксируйте общий файл инструкций (CLAUDE.md или AGENTS.md) в репозитории, чтобы каждый агент на каждой машине читал одни и те же соглашения. Затем определите, какие файлы принадлежат каждой задаче, чтобы два агента никогда не редактировали один и тот же модуль одновременно. Выбор инструментов имеет гораздо меньшее значение, чем эти два решения.

Следует ли фиксировать CLAUDE.md или AGENTS.md в репозитории?

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

Как предотвратить редактирование одних и тех же файлов двумя агентами?

Дайте каждой задаче свое рабочее дерево с помощью git worktrees и ограничьте каждую задачу набором файлов во время назначения. Агенты не ведут переговоры друг с другом, поэтому, если два из них могут добраться до одного и того же модуля, они в конечном итоге перезапишут работу друг друга таким образом, что ни один из них не сообщит.

Меняется ли код-ревью, когда команда использует кодирующих агентов?

Объем меняется, поэтому политика должна измениться. Чтение каждой строки не выдерживает контакта с пятью агентами, работающими параллельно. Команды, которые сохраняют контроль, проверяют план до начала работы, а затем проверяют diff в зависимости от того, что может сломать изменение, уделяя внимание аутентификации, платежам, разрешениям, личным данным и миграциям.

Как отслеживать, сколько стоят ai кодирующие агенты на одного разработчика?

По сеансу и по проекту, а не по месяцу. Ежемесячный счет-фактура сообщает вам общую сумму и ничего полезного. Вам нужно знать, какой проект и какой тип задачи сжигает токены, потому что ответ обычно заключается в небольшом количестве длительных сеансов с раздутым контекстом, а не в команде в целом.

Что ломается в первую очередь, когда команда масштабирует кодирующих агентов?

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