Каждый месяц запускается новый ИИ-агент для кода. агент для кода. агент для кода. Aider. OpenCode. Режим агента в Cursor. Cascade у внешний редактор. облачный агент. Список всё растёт. Каждый обещает быть умнее, быстрее, способнее предыдущего.

Вот в чём дело: агенты уже достаточно хороши. агент для кода умеет отрефакторить модуль. агент для кода умеет написать набор тестов. Aider умеет итерировать над багфиксом. Разница в качестве между топовыми агентами сокращается. Что не становится лучше — так это рабочий процесс вокруг них.

Настоящее узкое место — не качество агентов. Это количество агентов.

Потолок одного агента

Большинство разработчиков используют ИИ-агентов для кода одинаково:

Открыть терминал
Описать задачу
Смотреть, как агент работает
Проверить вывод
Дать обратную связь или смержить
Повторить

Это последовательно. По одной задаче за раз. Агенту может понадобиться 5 минут. Твоё ревью может занять 10. Это одна задача на 15 минут, четыре задачи в час. Для отдельного разработчика это солидный прирост продуктивности.

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

Запускать их по одной — это 50 задач по 15 минут каждая: больше 12 часов. Запустить 5 в параллель — меньше 3 часов. Запустить 10 в параллель — меньше 2 часов. Арифметика проста. Сложная часть — оркестрация.

Почему оркестрация — это сложно

Изоляция

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

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

Агенты падают. Терминалы закрываются. Ноутбуки уходят в сон. Если сессия твоего агента умрёт, ты теряешь контекст и вынужден перезапускаться. Для одного агента это раздражает. Для 10 агентов это неуправляемо.

Ревью

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

Распределение задач

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

Оркестрация против большего числа агентов

ИИ-индустрия кода делает крупную ставку на более качественных агентов. Умнее модели, больше контекстные окна, лучше работа с инструментами. Эти улучшения реальны и ценны.

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

Качество агента и оркестрация решают разные ограничения. Независимые задачи могут выполняться одновременно, а зависимые изменения и итоговое ревью остаются последовательными этапами.

Как выглядит хорошая оркестрация

Автоматическая изоляция

Создание задачи должно автоматически создавать Git worktree и ветку. Никакой ручной настройки, не надо помнить про checkout новой ветки, не надо переживать о конфликтах файлов. Оркестратор делает это прозрачно.

Сохранение сессий

Сессии агентов должны переживать падения, перезапуски приложения и циклы сна ноутбука. Фоновый демон, который владеет сессиями независимо от UI, решает это — тот же паттерн, что tmux использует для мультиплексирования терминалов, применённый к оркестрации агентов.

Агентонезависимость

Поддержка нескольких CLI-агентов позволяет выбирать инструмент под задачу. Оркестратор может запускать агент для кода, агент для кода, Aider или OpenCode и сохранять единый процесс организации сессий.

Единое ревью

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

Интеграция с редактором

У разработчиков сильные предпочтения по редакторам. Оркестратор не должен навязывать выбор редактора. Он должен интегрироваться с тем, чем ты пользуешься — VS Code, Cursor, JetBrains, Xcode, Neovim — и позволять открывать любой worktree в твоём любимом окружении.

Как мы строим это в Rox

Мы построили Rox, потому что сами упёрлись в этот потолок. Мы запускали агент для кода на всё — и для отдельных задач это было прекрасно. Но масштабирование до 5–7 агентов вручную было операционными издержками, отвлекающими от собственно работы.

Архитектура намеренно проста:

Git worktrees для изоляции (никаких контейнеров, никаких VM)
Постоянный демон для управления сессиями (Unix-domain-сокеты, переживает падения)
Любой CLI-агент как полноправный гражданин (нет SDK-интеграций, которые надо поддерживать)
Встроенный просмотрщик diff'ов для быстрого ревью
Интеграция с редактором для глубокого изучения (VS Code, Cursor, JetBrains, Xcode)

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

Эффект сложного процента

Запуск параллельных агентов даёт эффект сложного процента для продуктивности:

Больше задач в работе одновременно — независимые задачи могут выполняться параллельно, но итоговая скорость зависит от ревью и других ограничений
Более быстрая итерация — пока один агент итерирует над обратной связью, другие работают над новыми задачами
Лучший подбор агентов — используй правильного агента под каждую задачу вместо «один размер для всех»
Меньше переключений контекста — задачи доводятся до конца в изоляции, а не прячутся в стэш и возобновляются

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

Это правильный вопрос. И ответ такой: столькими, сколько поддерживает твой оркестратор и позволяет твоя скорость ревью.

Как управлять несколькими агентами в одном проекте