Эта заметка является пересказом статьи моих бывших коллег в DoorDash.Подробный пересказ статьи «Delegating Engineering Work To Cloud‑Based Agents»

https://careersatdoordash.com/blog/delegating‑engineering‑work‑to‑cloud‑based‑agents/

DoorDash построили внутреннюю платформу для облачных AI‑агентов под названием Flux. Масштаб уже впечатляющий: за один месяц 2026 года через неё прогнали 130 000 инженерных задач, включая свыше 25 000 автоматических код‑ревью в неделю и более 10 000 запусков playbook'ов из более чем 300 уникальных сценариев — всё это работает без участия человека, параллельно и круглосуточно.

Почему ушли от локальных агентов на ноутбуках

Команда описывает три конкретных ограничения агентных воркфлоу, запущенных прямо на машинах инженеров:

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

• Безопасность. Локальная среда обычно даёт агенту широкий доступ к чувствительным данным — SSH‑ключам, VPN‑сессиям, авторизованным инструментам. Давать автономному агенту такой же уровень доступа — избыточный риск с большим потенциальным радиусом поражения.

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

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

Почему строили своё, а не взяли готовое решение

Готовые облачные coding‑агенты удобны, но заставляют выбирать: либо отправлять чувствительный код и контекст выполнения третьей стороне, либо открывать внешней системе путь обратно во внутреннюю инфраструктуру. Для DoorDash сложность была не в том, чтобы заставить агента писать код — это, как отмечают авторы, уже более‑менее решённая задача. Сложность в том, чтобы дать агенту правильную среду, инструменты, права доступа, интеграции и ограничения.

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

Четыре платформенных примитива Flux

1. Sandboxes (песочницы). Вместо локальной среды агент выполняет работу в изолированных облачных песочницах на базе Firecracker microVM — с аппаратной изоляцией. Каждая песочница разворачивается с нужными репозиториями, инструментами разработки, секретами и зависимостями. SLO на полное развёртывание окружения (от старта microVM до готовых репозиториев, собранных тулов и настроенного агентского харнесса) — менее 5 секунд на 95-м перцентиле.

2. MCP‑шлюз (Agent Gateway). Собственный шлюз на основе Model Context Protocol даёт агентам доступ к внутренним системам — CI, observability, трекерам задач, инструментам деплоя, поиску по коду, документации. Каждый playbook явно декларирует, какие инструменты ему нужны, и получает только эти права — не больше. Все действия логируются, что даёт полный аудиторский след.

3. Playbooks (сценарии). Playbook — переиспользуемая единица агентной работы, по аналогии с Docker‑контейнером, только для навыков и задач. Описывается одним YAML‑файлом: задача, входные данные, контекст, навыки, инструменты, права доступа, критерии проверки, ожидаемый результат и границы безопасности. Playbook может комбинировать агентные шаги (гибкость и суждение) с детерминированными шагами (предсказуемость, дешевизна, простая проверка) — команды могут постепенно переносить логику между ними без переделки всего воркфлоу.

4. Invocation surfaces (точки запуска). Один и тот же playbook можно запускать из Slack (для совместного делегирования), GitHub (для автоматизации PR и CI), по cron‑расписанию (для регулярного обслуживания) или из CLI/скилла (для прямого контроля разработчиком). Это, по словам авторов, ключевой фактор, который сделал Flux легко внедряемым — командам не нужно каждый раз переизобретать способ запуска.

Извлечённые уроки

• Начинать узко, чтобы заслужить доверие. DoorDash не пытались автоматизировать весь цикл разработки сразу, а начали с автоматического код‑ревью — частая, измеримая и легко оцениваемая задача. Это дало продакшн‑воркфлоу, на котором можно было настроить качество, задержки и стоимость, прежде чем расширяться на CI‑триаж, on‑call задачи и разработку по тикетам.

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

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

Что дальше

Авторы обещают следующие посты — глубже про сами примитивы, про developer experience при создании новых воркфлоу, и про приложения поверх Flux, включая внутреннего Slack‑агента Flux Responder.