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

Зачем параллельные агенты?

Один агент для кода обрабатывает одну задачу за раз. Ты даёшь промпт, он работает, ты ревьюишь, ты итерируешь. В лучшем случае ты выполняешь одну единицу работы агента за цикл.

Но в большинстве кодовых баз в любой момент есть десятки задач, которые можно распараллелить:

Написание тестов для модуля A не конфликтует с рефакторингом модуля B
Обновление документации API не конфликтует с починкой запроса к базе данных
Добавление валидации ввода не конфликтует с миграцией формата конфига

Эти задачи независимы. Они могут — и должны — выполняться одновременно. Узкое место — не агент и не модель. Это человек, который оркеструет по одной задаче за раз.

Проблема изоляции

Запуск двух агентов в одной директории сразу же создаёт проблемы:

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

Решение: по одному worktree на агента

Git worktrees решают это на уровне файловой системы:

У каждого worktree есть:

Своя копия рабочей директории
Своя ветка
Своя область индекса (git index)

Они делят хранилище объектов git, поэтому создание worktree занимает секунды и стоит минимума места на диске.

Паттерны оркестрации

Паттерн 1. Worktrees вручную

Самый простой подход — создавать worktrees самому и запускать агентов вручную:

Это работает для 2–3 агентов, но разваливается при масштабировании. Ты управляешь worktrees, ветками и терминалами вручную.

Паттерн 2. Скриптовая оркестрация

Shell-скрипт, который автоматизирует создание worktree и запуск агента:

Лучше, но всё ещё нет единого обзора всех задач, нет сохранения сессий и нет рабочего процесса ревью diff'ов.

Паттерн 3. Выделенный оркестратор

Инструменты вроде Rox занимаются оркестрацией от начала до конца:

Создание задачи — опиши задачу, выбери агента
Автоматическая изоляция — worktree и ветка создаются автоматически
Управление сессиями — постоянный демон держит сессии живыми при падениях
Ревью diff'ов — встроенный просмотрщик diff'ов для ревью вывода агента
Интеграция с редактором — открыть любой worktree в VS Code, Cursor, JetBrains или Xcode

Именно этот подход масштабируется до 5–10+ одновременных агентов без операционных издержек.

Подбор правильного агента под задачу

У разных агентов разные сильные стороны. Параллельный рабочий процесс позволяет подбирать агентов под задачи:

Claude Code

Сложные рефакторы по нескольким файлам
Архитектурные изменения (новые паттерны, реструктуризация модулей)
Отладка тонких проблем, требующих глубокого понимания кодовой базы
Задачи, требующие интеграции инструментов через MCP

Codex CLI

Чётко очерченные, ясно определённые задачи
Режим Full Auto для автономного выполнения
Задачи, где хорошо себя показывают модели OpenAI (o3, o4-mini)
Чувствительные к стоимости задачи на более дешёвых моделях

OpenCode

Задачи, где важна гибкость в выборе модели (75+ провайдеров)
Оптимизация стоимости между разными провайдерами
Команды, запускающие локальные модели через Ollama
Задачи, выигрывающие от интеграции с LSP

Aider

Итеративные задачи в стиле парного программирования
Небольшие точечные изменения с плотной обратной связью
Задачи, требующие частого обмена туда-обратно

Ключевая идея: тебе не нужно выбирать одного агента на всё. Запусти Claude Code на сложном рефакторе и Codex на генерации тестов одновременно.

Узкое место ревью

Параллельные агенты создают новую проблему: пропускную способность ревью. Если ты запускаешь 10 агентов и каждый выдаёт diff за 15 минут, у тебя 10 diff'ов на ревью в час.

Стратегии быстрого ревью

Расставляй приоритеты по риску: добавление теста низкорисковое и ревьюится быстро. Миграция базы данных высокорисковая и требует тщательного ревью. Сортируй diff'ы по влиянию.

Ревьюй diff'ы, а не файлы: не перечитывай весь файл. Сосредоточься на том, что изменилось. Если diff ограничен тем, что ты просил, и тесты проходят, быстрого ревью обычно достаточно.

Дай агентам проверять собственную работу: перед ревью проверь, прогонял ли агент тесты. Если тесты проходят и diff чистый, твоё ревью — это проверка на здравомыслие, а не аудит с нуля.

Используй структурированные описания задач: «Добавь валидацию ввода на форму регистрации: email должен быть валидным, пароль — от 8 символов, показывать ошибки прямо в форме» даёт пригодный для ревью diff. «Улучши форму регистрации» даёт что-то непредсказуемое.

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

Управление ресурсами

CPU и память

Каждый агент потребляет локальные ресурсы на:

Сам процесс агента (терминал, файловый ввод-вывод)
Языковые серверы (TypeScript, Go, Python), если агент их использует
Процессы сборки, если агент запускает сборки
Наборы тестов, если агент запускает тесты

На современном ноутбуке 5–7 одновременных агентов работают комфортно. Сверх этого, возможно, стоит разносить запуски агентов по времени или ограничивать число одновременных сборок.

Лимиты запросов к API

Каждый агент делает запросы к API своего провайдера модели. Запуск 10 инстансов Claude Code упирается в лимиты Anthropic быстрее, чем один. Следи за заголовками лимитов своего провайдера и притормаживай при необходимости.

Место на диске

Каждый worktree — это полная выгрузка твоей рабочей директории. Для репозитория в 1 ГБ 10 worktrees займут ~10 ГБ. Хранилище объектов git общее, поэтому история не дублируется. Своевременно подчищай завершённые worktrees.

Частые ошибки

Слишком много агентов разом

Начни с 2–3, пока не освоишься с рабочим процессом ревью. Масштабирование до 10 раньше, чем ты сможешь ревьюить на скорости, создаёт затор, который тормозит всё.

Расплывчатые описания задач

«Почини баги» даст непредсказуемые результаты. «Почини разыменование null в UserService.getProfile, когда user.avatar равен null — добавь проверку на null и возвращай URL дефолтного аватара» даёт агенту ровно то, что ему нужно.

Игнорирование конфликтов веток

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

Не запускать тесты

Если агент не прогоняет тесты, ты ревьюишь вслепую. Либо включи в промпт «прогони тесты и почини любые падения», либо убедись, что тесты проходят, прежде чем ревьюить diff.

С чего начать

Выбери оркестратор — Rox берёт на себя worktrees, сессии и ревью
Выбери своих агентов — начни с Claude Code или Codex, расширишь позже
Начни с 2–3 задач — распараллеливаемых, непересекающихся
Ревьюй быстро — сосредоточься на diff'ах, а не на чтении файлов целиком
Масштабируй постепенно — добавляй агентов по мере роста скорости ревью

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

Полное руководство по запуску ИИ-агентов для кода в параллель