Stripe Minions: 1 300 PR в неделю без единой строчки кода
Stripe мержит более 1 300 пулл-реквестов в неделю без единой строки человеческого кода. Разбираем, как устроены агенты Minions: devbox-ы, блюпринты, MCP-инструменты и жёсткие ограничения.
1 300 PR каждую неделю, и ни одной строки от человека
В феврале 2026 года инженерный блог Stripe опубликовал серию из двух постов про внутреннюю систему Minions. Каждую неделю компания мержит более 1 300 пулл-реквестов, в которых нет ни одной строки, написанной человеком. Миграции кода, патчи безопасности, обновления зависимостей — всё делают автономные ИИ-агенты.
Кодовая база Stripe при этом не самая дружелюбная для LLM: сотни миллионов строк на Ruby с типизацией Sorbet. Редкий стек, на котором модели почти не обучались. А через платёжную систему проходит больше триллиона долларов в год, так что цена ошибки высока.
Главное, что показывает эта история: успех определяет зрелость инфраструктуры, а не выбор модели.
Что такое Minions и чем они отличаются от Cursor
Cursor, Claude Code, GitHub Copilot работают рядом с разработчиком. Программист смотрит на экран, корректирует курс, подтверждает действия. Это attended-агенты.
Minions работают иначе. Это unattended-агенты: инженер пишет задачу в Slack, уходит за кофе, а когда возвращается, готовый PR уже прошёл тесты и ждёт ревью. Человек не участвует до этапа проверки.
Инженеры Stripe пользуются и тем, и другим. Cursor и Claude Code берут для задач, где нужен контекст и понимание бизнес-логики. Minions — для рутины: миграций, обновления зависимостей, патчей безопасности, рефакторинга.
Технически Minions построены на форке goose от Block, одного из первых open-source кодинг-агентов. Stripe взял его в конце 2024 года и переделал под автономную работу без участия человека.
Devbox: облачные машины, которые стартуют за 10 секунд
Автономному агенту нужны три свойства от среды: изоляция (ошибки не затрагивают прод), параллельность (несколько агентов работают одновременно) и предсказуемость (каждый агент стартует с чистого состояния).
У Stripe всё это уже было задолго до появления LLM. Их «devbox-ы» — инстансы AWS EC2 с полной кодовой базой, инструментами и сервисами. Stripe заранее разворачивает пул таких машин: клонирует репозитории, прогревает кеши Bazel, запускает фоновые процессы. Новый devbox готов к работе за 10 секунд.
Инженеры и раньше использовали по отдельному devbox на каждую задачу. Один разработчик мог держать полдюжины одновременно. Агенты просто встроились в тот же паттерн.
Devbox-ы работают в QA-окружении, изолированном от продакшена. Агенты получают полные права без подтверждений, потому что радиус поражения ограничен одной одноразовой машиной. Пользовательских данных и доступа к боевым сервисам там нет.
Блюпринты: гибрид workflow и агента
Есть два стандартных подхода к оркестрации LLM-систем. Workflow — фиксированный граф шагов, где всё предопределено. Агент — цикл, где модель сама решает, что делать дальше. Workflow предсказуем, но негибок. Агент гибкий, но ненадёжный.
Stripe выбрал третий путь и назвал его «блюпринтами». Это последовательность узлов, где одни выполняют детерминированный код, а другие запускают агентный цикл.
На практике это выглядит так:
- «Реализуй задачу» — полноценный агентный цикл с инструментами и свободой действий
- «Запусти линтеры» — жёстко прописанный шаг, без участия LLM
- «Запуши ветку» — тоже захардкожен, следует шаблону PR компании
- «Исправь ошибки CI» — снова агентный цикл
Такое разделение экономит токены и снижает количество ошибок. При сотнях запусков в день каждый детерминированный узел убирает одну точку отказа. Эффект накапливается.
Отдельные команды внутри Stripe создают собственные блюпринты под специфические задачи, например, для сложных миграций, которые не получается решить обычным кодмодом.
Контекст: 500 MCP-инструментов через Toolshed
В кодовой базе из сотен миллионов строк агент легко потеряется. Если загрузить все правила глобально, контекстное окно забьётся ещё до начала работы.
Stripe решает это двумя способами. Для статического контекста — файлы правил, привязанные к конкретным директориям и паттернам файлов. Агент перемещается по файловой системе и подхватывает только то, что относится к текущей папке. Stripe использует формат Cursor и синхронизирует его с Claude Code, чтобы все три инструмента (Minions, Cursor, Claude Code) читали одни и те же правила.
Для динамического контекста — централизованный MCP-сервер Toolshed. Через него агенты получают доступ к внутренней документации, деталям тикетов, статусам билдов и результатам поиска по коду. На момент публикации Toolshed содержал почти 500 MCP-инструментов.
Stripe при этом подчёркивает: больше инструментов не значит лучше. Minions по умолчанию получают небольшой набор, а инженеры могут добавлять тематические группы под конкретные задачи.
Если вы следите за развитием MCP в индустрии, подход Stripe — один из крупнейших примеров применения этого протокола в продакшене.
Обратная связь: два цикла CI, и стоп
У Stripe больше трёх миллионов тестов. Прогонять их все локально нереально, а бесконечные итерации через CI — пустая трата токенов и вычислений.
Система обратной связи работает в три слоя:
- Локальный линтинг запускается при каждом push и занимает менее 5 секунд. Фоновый демон заранее вычисляет, какие правила применимы, и кеширует результаты
- CI выборочно запускает тесты. Автофиксы для известных паттернов ошибок применяются автоматически
- Если после автофикса ошибки остались, агент получает ещё один шанс исправить и запушить
После второго push всё заканчивается. Максимум два цикла CI. Если код не проходит, ветка возвращается инженеру.
Ограничение осознанное. LLM показывают убывающую отдачу при повторных попытках решить ту же проблему. Каждый дополнительный раунд стоит токенов и вычислений, а результат улучшается всё меньше.
Даже частично корректный PR экономит время. Доработать его за 20 минут — всё равно быстрее, чем писать с нуля несколько часов.
Какие задачи Minions решают, а какие нет
Minions справляются с задачами, которые хорошо определены, повторяемы и проверяемы автотестами:
- Миграции кода — перевод со старых API на новые
- Обновление зависимостей — bump версий, адаптация к breaking changes
- Патчи безопасности — применение фиксов по известным уязвимостям
- Рефакторинг — переименование, перемещение модулей
- Мелкие баг-фиксы, которые копятся в on-call очереди за ночь
Чего Minions не делают: не проектируют архитектуру, не принимают продуктовых решений, не пишут код с глубокой бизнес-логикой. И не берутся за задачи без автотестов.
Типичный сценарий: инженер на дежурстве получает пять мелких багов за ночь. Вместо последовательной работы он отправляет пять сообщений в Slack с описанием фиксов. За время кофе-брейка пять агентов параллельно поднимают devbox-ы, пишут код, прогоняют тесты и готовят PR. Инженер возвращается, одобряет три, даёт фидбек на один, отклоняет последний. Пять задач за время, которое обычно уходит на две.
Практические выводы
Stripe не раскрывает, какую именно LLM используют Minions. Архитектура сознательно абстрагирована от конкретной модели: модель можно заменить, а инфраструктура остаётся.
Пять вещей, которые стоит забрать из этого опыта:
- Начинайте с инфраструктуры, а не с модели. Окружения разработчика, тестовая инфраструктура, пайплайны обратной связи — если они хороши, агенты получат выгоду. Если нет, никакая модель не поможет
- Разделяйте детерминированное и агентное. Линтинг, push, создание PR — не задачи для LLM. Захардкодьте то, что можно захардкодить
- Ставьте жёсткие ограничения. Два цикла CI — одно из ключевых решений Stripe
- Начинайте с рутины. Миграции, обновления зависимостей, патчи — лучшие первые кандидаты для автономных агентов
- Ревью никуда не уходит. Роль инженера смещается от написания кода к проверке, но сама проверка становится важнее
Если у вас уже есть рабочая CI/CD-инфраструктура, изолированные окружения и достаточно рутинных задач, вы ближе к собственным «миньонам», чем кажется.
