Несколько coding-агентов на одном репозитории: как не сломать код

Один агент пишет фичу, второй параллельно чинит баги, третий переписывает тесты — всё в одном репозитории и почти одновременно. Сценарий перестал быть экзотикой: у Anthropic есть Claude Code с поддержкой параллельных сессий и субагентов, у OpenAI — облачный Codex, который берёт задачу и открывает pull request сам, у Cursor и Windsurf — фоновые агенты. Проблема в том, что git и файловая система не знали, что над ними теперь работает не человек, а несколько автономных процессов, каждый из которых уверен, что редактирует файл в одиночку.

Что вообще значит «несколько агентов над одним репозиторием»

Под этим понимают три разных сценария, и путать их дорого.

• Параллельные независимые задачи. Каждому агенту дают отдельную задачу и отдельную ветку. Они почти не пересекаются по файлам, конфликт возникает только при слиянии.
• Оркестрация субагентов. Один главный агент раздаёт подзадачи вспомогательным (это и называют мультиагентной схемой). Так устроены субагенты¹ в Claude Code: планировщик делит работу, исполнители возвращают результат.
• Соревновательный запуск. Одну и ту же задачу отдают нескольким агентам или моделям, а потом выбирают лучший результат. Дорого по токенам, но иногда оправдано на сложных багах.

Технически ни один из трёх не безопасен «из коробки»: два процесса, редактирующие один рабочий каталог, перезаписывают правки друг друга, ломают индекс git и оставляют репозиторий в состоянии, из которого сложно откатиться.

Главная защита — git worktree, а не общий каталог

Самый надёжный приём — не пускать агентов в один и тот же рабочий каталог. Git worktree² позволяет из одного репозитория развернуть несколько независимых рабочих директорий, каждая на своей ветке. Агент А работает в каталоге ../feature-auth, агент Б — в ../fix-tests, и файлы физически не пересекаются.

git worktree add ../feature-auth feature-auth
git worktree add ../fix-tests fix-tests
git worktree list

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

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

Чем инструменты отличаются между собой

Подходы к параллельной работе у популярных инструментов разные: от локальных worktree до полностью облачных песочниц. Ниже — сравнение по состоянию на начало 2025 года; проверяйте актуальные возможности в документации, они обновляются часто.

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

Как организовать процесс, чтобы не разгребать конфликты

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

1. Разбейте задачу на непересекающиеся части. Идеально, если два агента не трогают одни и те же файлы. Пересечение по одному файлу почти гарантирует конфликт слияния.
2. Дайте каждому агенту свою ветку и свой worktree. Никакого общего рабочего каталога.
3. Запретите агентам мержить в main самостоятельно. Финальное слияние — через pull request и ревью, человеком или отдельным проверяющим прогоном.
4. Держите тесты и линтер в CI. Прогон на каждом PR ловит то, что агент сломал в чужой зоне.
5. Фиксируйте контекст в файле-инструкции. Общие правила проекта (стиль, запреты, архитектура) в одном месте, чтобы агенты не расходились в трактовках.

Отдельная боль — токены и деньги. Соревновательный запуск трёх агентов на одну задачу утраивает расход. Оркестрация субагентов тоже стоит дороже одиночного прогона, потому что планировщик и исполнители тратят контекст на переписку между собой. Прежде чем масштабировать, посчитайте, окупается ли параллелизм на вашей задаче.

Кому это пригодится и кому нет

Пригодится:

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

Не пригодится или навредит:

• Маленьким проектам, где два агента неизбежно топчутся в одних файлах — накладные расходы на изоляцию больше выигрыша.
• Задачам с сильной связностью кода, где изменение в одном месте тянет за собой правки по всему проекту: разделить на независимые части не выйдет.
• Командам без ревью и без CI — параллельные агенты в таком окружении просто быстрее приводят main в нерабочее состояние.

¹ Субагент — вспомогательный агент, которому главный агент делегирует подзадачу; он выполняет её в своём контексте и возвращает результат оркестратору.

² Git worktree — механизм git, позволяющий из одного репозитория держать несколько независимых рабочих каталогов, каждый на своей ветке.