Параллельные AI-агенты: красиво в демо, неудобно в работе
Демо выглядело убедительно. На экране — Kanban-доска, восемь карточек, каждая закрывается своим AI-агентом. Через 20 минут все тикеты зелёные. Зрители аплодируют.
В феврале я попробовал что-то похожее в своей практике. Три параллельных Claude Code сессии на трёх ветках одного проекта. Через три часа я сидел с девятью конфликтами слияния и двумя местами, где агенты приняли несовместимые архитектурные решения, не зная друг о друге.
Почему параллельность кажется очевидным шагом
Логика на поверхности простая: разработчик нанимает трёх джунов — производительность растёт. Почему с агентами иначе?
Проблема в том, что джуны общаются. Они используют общий Slack, стоят у одного whiteboard, видят чужой код на ревью. У параллельных AI-агентов общего контекста нет. Каждый работает в своём окне, со своим системным промптом, с историей разговора, которая начинается с нуля.
В моём эксперименте я распределил три задачи: первый агент переписывал API-обёртку для Bitrix REST, второй добавлял кеширование в слой данных, третий чистил типы в TypeScript. Задачи казались независимыми. На бумаге.
На практике все три касались одного модуля. Первый агент изменил сигнатуру функции fetchProduct(). Второй выстроил кеш вокруг старой сигнатуры. Третий выровнял типы по старой версии тоже, потому что не знал, что первый её меняет. К концу третьего часа у меня было три ветки, каждая из которых считала себя правой.
Цена review-overhead
Когда один разработчик сдаёт один PR, ревью занимает определённое время. Три PR от трёх агентов — не втрое больше. Намного больше.
Дело не только в объёме. Дело в том, что я должен удержать в голове три локальных истории принятия решений. Каждый агент видел задачу по-своему, каждый оставил свои trace в коде. Чтобы принять финальное решение о merge, мне пришлось восстановить, кто что думал — и почему три агента пришли к разным решениям.
В итоге: три часа работы агентов, четыре часа моего ревью. Один агент с той же задачей, последовательно, занял бы суммарно около трёх часов. Итого я потерял четыре часа на «ускорение».
Архитектурные конфликты без арбитра
Есть класс решений, где нет объективно правильного ответа: выбор структуры кеш-ключа, форма error response, место, где живёт бизнес-логика. Когда работает один агент, он принимает эти решения последовательно и остаётся в контексте.
Параллельные агенты принимают эти решения независимо. У них нет «главного», нет shared design doc, нет общей памяти об уже принятых решениях. В моём случае агент с кешированием выбрал структуру ключа product:{id}:v1, а агент с API-обёрткой внутри той же функции сгенерировал bp:product-{id}. Оба решения рабочие. Оба несовместимые между собой.
Арбитром стал я. Это и есть моя работа — но я не планировал тратить её на склейку артефактов трёх независимых сессий.
Когда параллельность реально работает
Я не говорю, что параллельные агенты никогда не нужны. Они работают при одном условии: задачи действительно изолированы.
Под изоляцией я понимаю не «разные файлы», а разные домены без общих зависимостей. Например:
Первое — разные микросервисы с отдельными репозиториями и независимыми API. Один агент пишет логику нотификаций, второй делает экспорт в Excel. Они физически не могут затронуть один и тот же код.
Второе — задачи на разных стадиях пайплайна, где выход одного не является входом другого. Один агент генерирует тесты для уже готового модуля, второй в это время документирует другой готовый модуль.
Третье — по-настоящему контентные задачи без архитектурного измерения: перевод UI-строк, seed-данные для разных таблиц, changelog entries по готовым коммитам.
В моём случае задачи казались независимыми, но делили один модуль. Это была ошибка декомпозиции, а не проблема с инструментом.
Что не работает точно
Параллельные агенты ломаются в предсказуемых местах:
Общая кодовая база с пересекающимися файлами. Даже если задачи разные, агенты могут изменить один и тот же файл несовместимым образом.
Задачи, где есть «архитектурный выбор». Выбор структуры данных, форма публичного API, способ обработки ошибок — всё это требует единого решения. Параллельные агенты примут разные решения независимо.
Любая задача, где нужна история предыдущих решений в этой же сессии. Агент не знает, что второй агент уже решил переименовать переменную или изменил контракт функции.
Мой рабочий режим в 2026
После этого эксперимента я вернулся к одному агенту с длинным явным контекстом. Для сложного рефакторинга — CLAUDE.md с описанием текущего состояния и принятыми решениями. Для последовательных задач — один разговор, где агент помнит всё, что было раньше.
Производительность по цифрам: 65% кода в моих проектах за последние полгода написан с AI-помощью. Но ни одна из 13 автоматизаций в моей системе не использует параллельных агентов. Там, где нужна скорость, я разбиваю задачу на последовательные шаги, а не на параллельные ветки.
Параллельность впечатляет в демо. В демо нет merge-конфликтов, нет архитектурных решений, и не нужно объяснять одному агенту, что сделал другой. В реальном проекте всё это есть. И платить за это приходится мне, не агентам.
Один агент, хорошо сформулированная задача, явный контекст — дешевле восьми агентов с туманными инструкциями. Я проверил.
Связанные статьи: