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

Прямо сейчас в Rox мы способны надёжно управлять 5–7 агентами для кода в параллель — будь то Claude Code, Codex и т. д. — за раз. Наша цель — научиться управлять 100 агентами для кода в параллель каждый к концу 2026 года.

Большинство людей считают, что путь от семи к 100 агентам — это лучшие модели, более быстрый инференс и более умные агенты. Это не так. Вычисления для агентов уже достаточно дёшевы: можно гонять сотни агентов в месяц, и всё это дешевле стоимости одного инженера.

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

Размечаем проблему

Можно представить цикл работы агента как конвейер, и цель — повысить пропускную способность:

Конвейер агента — большинство шагов требуют человека

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

При 100 агентах эта модель ломается напрочь. Ты не можешь ревьюить 100 diff'ов в день. Ты не можешь переключать контекст между 100 потоками работы.

Решение очевидно: убрать человека из шагов, где он не нужен, и сделать оставшиеся шаги быстрее.

Как мы будем это улучшать

Пусть агенты работают усерднее, прежде чем обращаться к тебе

Если ты работал с агентом для кода, ты знаешь это на собственном опыте: агент возвращается с чем-то полусырым, ты тратишь 15 минут, чтобы вникнуть в то, что он сделал, поднимаешь dev-сервер, кликаешь по округе, а потом скармливаешь ему ту же обратную связь, что ты давал дюжине агентов до этого. Большую часть времени, что ты тратишь на ревью, ты не принимаешь решения — ты ловишь проблемы, которые должны были быть пойманы до того, как работа дошла до тебя.

Решение — добавить слои между агентом и тобой. Работа агента должна быть тщательно проверена, прежде чем она вообще будет представлена тебе.

Работа агента проходит через слои ревью, прежде чем дойти до тебя

Состязательные агенты

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

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

Стэк из агентов ревью и автоматического тестирования

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

Та же логика применима к тестированию. Дав агентам доступ к браузеру через инструменты вроде BrowserUse или тестов Maestro, ты позволяешь им проверять собственную работу визуально — отлавливая регрессии UI, проблемы вёрстки и баги взаимодействия, которые невидимы в одном лишь код-ревью.

Долго работающие агенты

Большинство процессов с агентами сегодня одноразовые: ты даёшь задачу, агент работает, он возвращается. Но агенты должны уметь гонять более длинные циклы — пробовать подход, упираться в проблему, корректироваться и итерировать, пока не будут уверены или по-настоящему не застрянут. Ralph-циклы — популярный для этого паттерн: относись к работе агента как к глине на круге, итеративно её обтачивая, а не как к кирпичам, выкладываемым в линию.

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

Сделай ревью работы агентов быстрым

Большинство инструментов для разработчиков сегодня управляются человеком — ты открываешь diff, ты поднимаешь dev-сервер, ты переходишь на нужную страницу. Агенты подключаются к этим инструментам, но черновую работу всё ещё делает человек. Мы хотим сместить парадигму в сторону UI, управляемых агентами, — интерфейсов, которые агенты оркеструют на благо человека, где каждое ревью занимает секунды, а не минуты.

Инвестиции в UI, управляемые агентами

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

В UI, управляемом агентами, агент готовит ревью за тебя. Он пишет сводку того, что изменилось и почему, поднимает preview-окружение, переводит тебя на конкретные страницы или флоу, которые хочет тебе показать, и выносит на поверхность те результаты тестов, что важны. Когда ты открываешь завершённую задачу, ты должен смотреть на подготовленный брифинг, а не на сырой вывод.

Сделай существующие инструменты лучше

Ревью PR, дашборды CI, IDE — всё это построено для мира, где взаимодействия ведёт человек. В мире, где на первом месте агенты, инструменты должны встречать тебя иначе. Агенты должны аннотировать собственные PR, прежде чем ты их откроешь, — так, как ревью Devin заранее добавляет контекст к diff'ам. Результаты CI должны быть сведены и рассортированы агентом, а не представлены сырым логом, который тебе разбирать. Инструменты, которыми мы пользуемся каждый день, проектировались для людей-авторов — адаптировать их под людей-ревьюеров работы агентов — это другая задача дизайна.

Сведение трения к нулю

Каждое взаимодействие между тобой и агентом должно быть максимально лёгким. Ты должен иметь возможность кликнуть «да» или «нет» для простых изменений. Агенты должны готовить вопросы с вариантами ответа — «Я нашёл три подхода к этому, какой ты предпочитаешь?» — чтобы ты выбирал, а не печатал. Когда агенту всё-таки нужна письменная обратная связь, вспомогательные агенты могут заранее заполнить черновик ответа на основе контекста, чтобы ты редактировал, а не писал с нуля. Быстрые действия вроде «создать PR» или «выкатить на staging» тоже должны быть под рукой.

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

Пусть агенты будут более проактивными

События запускают агентов автоматически

Всё вышеперечисленное предполагает, что именно ты решаешь, над чем работают агенты. Но при 100 агентах планирование само по себе становится узким местом. Ты не можешь расписать 100 задач в день — это требует понимания кодовой базы, продуктовых приоритетов и нюансов каждой задачи.

Переиспользуемые рабочие процессы

Строительные блоки для этого уже появляются. Codex skills от OpenAI позволяют упаковывать повторяемые рабочие процессы — процедуры деплоя, шаги миграции, паттерны тестирования — как переиспользуемые бандлы, которые агенты могут сами вызывать, когда ситуация совпадает. Вместо того чтобы писать одни и те же инструкции каждый раз, ты кодируешь их однажды, а агент распознаёт, когда их применить.

Триггеры, управляемые событиями

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

За пределами кода

Даже за пределами кода этот паттерн закрепляется. Circleback слушает твои встречи и не просто делает заметки — он извлекает пункты действий, создаёт тикеты в Linear для запросов на фичи, упомянутых на продуктовых демо, и обновляет твою CRM после звонков с продаж. Встреча заканчивается — а дальнейшая работа уже в движении.

Мы ещё не во всём этом разобрались. Что-то уже работает, что-то в нашем роадмапе, а что-то всё ещё обретает форму. Но рамка пропускной способности даёт нам ясный тест для каждой фичи, которую мы строим: сокращает ли это время, которое человек тратит на одно взаимодействие с агентом?

Если ты гоняешь агентов в масштабе и упираешься в эти стены, мы будем рады сравнить заметки — пиши нам на founders@rox.one