Открываем исходный код DevBox — нашей автономной инженерной среды

DevBox — это инженерная среда с открытым исходным кодом, которой можно поручить задачу так же, как и коллеге по команде. Она определяет, какие репозитории нужно изменить, вносит изменения, тестирует их, проверяет собственный дифф и открывает черновик пулл-реквеста. Проект распространяется под лицензией MIT, работает на вашей собственной инфраструктуре и обращается к вашей конечной точке модели. Код доступен по адресу github.com/rudderlabs/devbox.

Мы используем DevBox в нашей собственной инженерной организации с апреля. И с тех пор:

• 1500+ пулл-реквестов
• 80% успешных слияний
• Задействовано 66 репозиториев

Бэклог, который никогда не сдвигается с места

В каждой инженерной команде есть задачи, которые определенно стоит сделать, но на которые никогда не хватает времени в приоритетах. Клиент API, в который нужно добавить еще одно поле. Тест с тайм-аутом, слишком коротким для CI. Зависимость, зафиксированная на три минорные версии назад. Документация, которая разошлась с кодом шесть недель назад.

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

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

Мы создали DevBox именно для таких задач и выпускаем его под лицензией MIT.

Что DevBox делает с этим

DevBox работает на базе Linear. Назначьте ему задачу или упомяните его в ней. В ответ вы получите черновик пулл-реквеста, который DevBox уже самостоятельно протестировал и проверил. Вы проверяете этот пулл-реквест на GitHub и оставляете свои комментарии там или отвечаете прямо в сессии Linear. В любом случае система отправляет новые коммиты в ту же ветку.

Рисунок 1. Вы передаете тикет и получаете в ответ черновик пулл-реквеста. Всё, что происходит между этими этапами, выполняется автоматически, а ваши комментарии запускают новый раунд в той же ветке.

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

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

Рисунок 2. Записи агента в процессе работы. Это иллюстративные примеры, а не данные реального запуска.

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

Когда DevBox учится чему-то не тому, вы видите это в диффе и исправляете точно так же, как исправили бы вводящий в заблуждение комментарий или устаревший файл README.

Рисунок 3. Знания, приобретаемые DevBox, поступают в виде диффа. Обобщенные заметки попадают в файлы знаний репозитория в том же пулл-реквесте, что и код, а ваши комментарии к ревью питают следующую задачу.

Он следует вашим соглашениям

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

DevBox считывает свои инструкции из репозиториев, с которыми работает. Сборочные команды, команды тестирования, правила именования, желаемые и запрещенные паттерны хранятся в таких файлах, как AGENTS.md в корне репозитория, рядом с кодом, и проходят ревью наравне со всем остальным. DevBox может следовать только тем соглашениям, которые вы зафиксировали в письменном виде.

Большинство таких соглашений оформлено в виде навыков (skills) — самодостаточных пакетов инструкций и ожидаемых рабочих процессов, которые находятся в репозитории рядом с кодом. Навык описывает, как здесь выполняется определенный тип работы, например, как пишется миграция или какие проверки должны пройти до того, как изменения будут считаться завершенными.

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

Рисунок 4. Каждый агент получает соглашения и навыки того репозитория, с которым он работает. Имена репозиториев приведены в качестве примеров.

Как это работает

Назначение задачи Linear для DevBox вызывает вебхук на его плоскости управления (control plane). Плоскость управления запрашивает у OpenSandbox изолированную среду для этой конкретной задачи, запускает ее и следит за ней.

С этого момента DevBox действует самостоятельно. Среда (harness) запускается внутри песочницы, выполняет задачу и сообщает о прогрессе плоскости управления, которая публикует его в тикете Linear по мере продвижения. В конце система открывает пулл-реквест. До этого момента никому не нужно вмешиваться, и на практике это происходит крайне редко.

Оставлять DevBox без присмотра имеет смысл только потому, что песочница изолирована. Всё, что она отправляет наружу, проходит через iron-proxy, который добавляет реальные учетные данные (которых у песочницы никогда нет) и отклоняет любой хост, не входящий в список разрешенных.

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

Рисунок 5. Одна песочница на задачу и один маршрут наружу. Каждый исходящий вызов проходит через прокси, поэтому доступные агенту хосты задаются в конфигурации.

Плоскость управления представляет собой сервис на Bun с Postgres, песочницы предоставляются OpenSandbox (контейнеры на ноутбуке, поды в кластере), агенты построены на базе DeepAgents, а за исходящий трафик отвечает iron-proxy. Всё это устанавливается с помощью чарта Helm.

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

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

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

Почему безопасно подключать систему к вашим приватным репозиториям

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

• Ваши учетные данные никогда не попадают в песочницу. Она получает фиктивные значения для токена GitHub и ключа модели, а iron-proxy подставляет настоящие при выходе запросов.
• Песочница может обращаться только к разрешенным вами хостам. iron-proxy служит ее единственным маршрутом наружу и единственным резолвером имен, причем все, что не входит в список разрешенных, отклоняется, поэтому ничто внутри песочницы не сможет отправить ваш исходный код на хост, которого нет в списке.
• Запись ограничена только теми репозиториями, которые вы перечислите. Все, что находится за пределами этого списка, отклоняется на уровне прокси, а не просто игнорируется в подсказке (промпте).
• DevBox принимает инструкции только от назначенных вами людей, так как в противном случае любой, кто может оставить комментарий к пулл-реквесту, попытался бы управлять им. Вы указываете доверенные организации и пользователей, и если вы никого не укажете, он вообще не будет читать обсуждения пулл-реквестов.
• Каждая задача получает собственное окружение. Задачи не делят общее рабочее пространство, поэтому одна не сможет испортить ветку или состояние другой.

Рисунок 7. В песочнице нет ничего ценного, что стоило бы красть. Настоящие учетные данные добавляются на прокси-сервере и только для разрешенных вами хостов.

Для продакшена запустите DevBox на Kubernetes, где каждая задача представляет собой отдельный под, а правила исходящего трафика (egress) принудительно задаются сетевой политикой. Вы можете пойти дальше и назначить песочницам класс среды выполнения (runtime class), чтобы каждая из них представляла собой виртуальную машину Kata Containers вместо контейнера, разделяющего ядро хоста. Готовый чарт содержит пример для продакшена, который делает именно это на выделенных узлах. Путь с Docker Compose существует для того, чтобы вы могли опробовать DevBox на ноутбуке во второй половине дня. Он не предназначен для работы всей команды.

Рисунок 8. От ноутбука до ВМ на каждую задачу. В продакшен-примере из чарта песочницы запускаются как ВМ Kata на выделенных узлах.

Чего он добился для нас

Мы используем DevBox во всей нашей инженерной организации. За последние три месяца он объединил (слил) 734 пулл-реквеста в 60 репозиториях, и 80% пулл-реквестов, доведенных им до принятия решения за этот период, были успешно слиты. Остальные были закрыты после того, как человек ознакомился с изменениями и посчитал их нецелесообразными.

Этот показатель рос каждый месяц: 72% в августе, 79% в сентябре, 91% в октябре. Мы считаем, что изменилось две вещи. DevBox стал более функциональным, а мы научились лучше ставить ему задачи.

Рисунок 9. Месячный процент слияний: количество слитых пулл-реквестов, деленное на количество слитых или закрытых за месяц. Данные за октябрь приведены по 26-е число.

Рисунок 10. Пулл-реквесты, открытые DevBox с августа по октябрь 2026 года, по типу изменений.

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

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

Пулл-реквест, перелицензировавший DevBox под лицензию MIT в преддверии этого релиза, был открыт самим DevBox.

Где он работает плохо

DevBox дает сбои предсказуемым образом, и эти сбои делятся на три категории.

• Нечеткие тикеты приводят к нечетким изменениям. Однострочная задача без деталей порождает решение, которое упускает суть. Что действительно работает, так это спецификация. Инженер уточняет требования в описании задачи перед ее делегированием, и это влияет на результат сильнее, чем любая опробованная нами конфигурация.
• Герметичные корпоративные знания для него невидимы. Когда рабочий процесс живет в головах людей, а не в коде, DevBox не может следовать ему и уверенно сделает что-то другое. Запишите это в репозитории или объясните с помощью последующих комментариев к пулл-реквесту, которые этап дистилляции затем запишет для будущих задач.
• Для работы обвязки требуется образ, собранный под ваш стек: набор инструментов, версии и деревья зависимостей, которые долго разрешаются с нуля. Соберите этот образ, прежде чем оценивать результаты.

Это те же проблемы, с которыми сталкивается новый инженер в свою первую неделю, и они реагируют на те же решения.

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

Запустите самостоятельно

DevBox распространяется под лицензией MIT и развертывается на собственных мощностях (self-hosted). Вы используете собственный эндпоинт и ключ модели, поэтому ваш код и промпты отправляются провайдеру, с которым у вас уже налажены отношения. Он работает с эндпоинтами, совместимыми с OpenAI, а также с API Anthropic.

Начало работы требует одного файла конфигурации со списком репозиториев, к которым DevBox может иметь доступ, и эндпоинта вашей модели, а затем одной команды для запуска стека. Первая сборка занимает около десяти минут. Подключите его к Linear и GitHub, делегируйте задачу в Linear и наблюдайте за появлением черновика пулл-реквеста.

Исходный код, руководство по быстрому старту и руководство по Kubernetes находятся по адресу . Выберите один тикет из бэклога, который никогда не сдвигается с места, и передайте его DevBox.