Как координировать несколько ИИ-агентов в разработке без постоянных конфликтов слияния

Один разработчик, который запускает одного ИИ-агента поверх файла backlog.md в своём репозитории, получает рабочую схему. Агент читает файл, берёт задачу, делает работу, обновляет файл. Здесь ничего не ломается, пока не появляется второй агент или второй человек.

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

Что происходит, когда это реально запускают в масштабе

Это не теория. Anthropic провели именно такой эксперимент: 16 параллельных агентов Claude писали компилятор C на Rust с нуля, координируясь через общий Git-репозиторий, за около 2000 сессий Claude Code и 20000 долларов затрат на API.

Их способ координации был почти точно паттерном backlog.md: каждый агент забирал задачу, записывая lock-файл, работал над ней, потом мерджил изменения обратно. Это работало, пока команда не наткнулась на общую проблему, к которой сошлись сразу все агенты. Как описывает это сама Anthropic, когда всем агентам нужно было добиться компиляции ядра Linux: «каждый агент натыкался на один и тот же баг, чинил его, а затем затирал изменения друг друга. То, что запущено 16 агентов, не помогало, потому что все были заняты решением одной и той же задачи».

Их решение было не «файл побольше» и не «промпт поумнее». Это была отдельная инфраструктура: они построили «заведомо рабочий компилятор-оракул» на основе GCC, чтобы большинство файлов проверялись против надёжного эталона, а собственному компилятору доставалась только меняющаяся часть. Так одна общая проблема превратилась в много независимых, параллельных.

Это не разовый случай. Недавнее академическое исследование пул-реквестов от ИИ-агентов на GitHub, датасет AgenticFlict, показало, что среди 142652 PR, сгенерированных ИИ, из 59412 репозиториев конфликты слияния встречались в 27,67% случаев, с разбросом от 15,24% до 31,85% в зависимости от инструмента. Проблема координации между ИИ-агентами это измеренный, частый результат, а не редкий случай.

Почему это бьёт по организациям иначе, чем по соло-разработчикам

Соло-разработчик, наткнувшись на конфликт lock-файла, просто разрешает его и идёт дальше. Это стоит ему пары минут. Для команды или агентства, которое ведёт агентов сразу по нескольким клиентским проектам, тот же файловый паттерн ломается способами, которые не имеют отношения к самому конфликту:

• Никто вне репозитория этого не видит. Продакт-менеджер, клиент или QA-инженер никак не может проверить статус задачи, которая живёт в markdown-файле на чьей-то фича-ветке. Доска, в которую реально смотрит стейкхолдер, и файл, который реально читает агент, это два разных источника правды.
• Нет границы доступа. Общий файл задач даёт любому агенту, который может читать репозиторий, тот же уровень доступа, что и всем остальным агентам. Нельзя сказать «этот агент может трогать проект А, но не проект Б», не построив эту логику самостоятельно.
• При передаче теряется всё, чего нет в файле. Когда новый сотрудник или подрядчик подхватывает работу, он получает только то, что записано, а не логику решения или состояние параллельной работы, которую уже сделал другой агент.

Этот разрыв в доступе тоже не гипотетический. Institute for Business Value от IBM обнаружил, что 82% организаций находили хотя бы одного ИИ-агента или воркфлоу, о котором служба безопасности заранее не знала, и только 13% считают, что их governance реально адекватен. Файл в репозитории, который любой локально запущенный агент может читать и писать, это ровно та неконтролируемая поверхность, о которой говорит эта статистика.

Есть и вторая цена, которая проявляется медленнее: то, что O'Reilly называет "comprehension debt", растущим разрывом между тем, сколько кода существует в системе, и тем, сколько из него реально понимает хоть один человек. Несколько агентов, параллельно пишущих код поверх общего файла, разгоняют этот разрыв быстрее, чем когда-либо смог бы один агент, потому что ни один человек и ни один агент не держит в голове всю картину целиком.

Что реально делают команды, у которых это работает

Инженер Эдди Османи, разбирая, что отличает рабочие мультиагентные схемы от тех, что разваливаются, описывает паттерн, который держится: разбивать работу на тестируемые задачи с явными границами, изолировать каждого агента в собственном Git worktree, разделять роли на координатора, специалиста и верификатора, и требовать автоматических quality gates перед любым мерджем.

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

Большинство организаций такую инфраструктуру ещё не построили. Исследование McKinsey показало, что только 23% организаций реально масштабируют agentic AI-систему хотя бы в одной бизнес-функции, 39% всё ещё экспериментируют, и ни в одной отдельной функции доля реального масштабного использования не превышает 10%. Прогноз Gartner на этот счёт жёстче: они ожидают, что более 40% agentic AI-проектов будут закрыты к концу 2027 года, в основном потому, что операционный и governance-слой не поспевает за скоростью, с которой улучшаются сами агенты.

Как это выглядит с настоящим графом задач вместо файла

TAM заменяет схему «lock-файл и надежда» теми же примитивами, которые описывает Османи, только встроенными в платформу, а не собранными вручную под каждый проект. Задачи живут в настоящем графе с зависимостями, а не в плоском markdown-списке, поэтому два агента не могут случайно забрать одну и ту же работу. Каждый подключённый агент получает свой отдельный MCP-токен со скоупом вместо доступа ко всему репозиторию, проверяемым на стороне сервера, поэтому «этот агент может трогать проект А, но не проект Б» не зависит от того, решит ли агент это соблюдать. Активность по PR привязывается к тикету автоматически уже сегодня, тот же контекст, который у Anthropic пришлось вручную обеспечивать GCC-оракулом, а переход задачи в Done устроен так, чтобы опираться на то же доказательство, с полным принудительным контролем, который выходит поверх него, той же ролью, которую вручную играл оракул Anthropic, только она работает по умолчанию, а не как то, что команде приходится строить с нуля.

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