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

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

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

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

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

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

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

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

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

Что должно в него входить:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка, которая работает

Сжато, в порядке важности:

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

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

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