Как агенты Stripe отправляют 1300 PR в неделю без единой строчки человеческого кода
Каждую неделю Stripe мержит более 1300 пулл-реквестов, в которых нет ни одной строчки, написанной человеком. Эти PR создают внутренние ИИ-агенты под названием Minions — они работают полностью автономно, без присмотра инженера.
Инженер отправляет сообщение в Slack, уходит за кофе — и возвращается к готовому пулл-реквесту, который уже прошёл автотесты и ждёт ревью. Пять задач за то время, которое обычно уходит на две. Звучит как фантастика, но за этой продуктивностью стоит не столько модель, сколько инфраструктура, которую Stripe строил годами — задолго до эры LLM.
Разбираемся, как устроена система Minions, какие задачи она решает и чему из опыта Stripe могут научиться другие компании. Статья основана на публичных материалах ByteByteGo и Stripe Engineering Blog.
Ключевые выводы:
— Stripe мержит более 1300 PR в неделю, созданных полностью автономными ИИ-агентами
— Minions — это unattended-агенты: они не требуют наблюдения или пошагового одобрения
— Архитектура построена на «блюпринтах» — гибридах жёсткого пайплайна и агентных циклов
— Главный секрет успеха — не модель, а developer-инфраструктура: изолированные окружения, быстрые тесты и чёткие ограничения
— Если агент не справился за два цикла CI — задача возвращается человеку
Масштаб — цифры и факты
Stripe обрабатывает более триллиона долларов платежей в год. Кодовая база компании — сотни миллионов строк кода, преимущественно на Ruby с типизацией Sorbet. Это относительно редкий стек, с которым LLM практически не сталкивались при обучении.
На этом фоне цифры Minions выглядят особенно впечатляюще:
- 1300+ PR в неделю — полностью автоматические, без единой строки человеческого кода
- Типы задач — миграции кода, обновление зависимостей, исправления безопасности, рефакторинг
- Время запуска агента — менее 10 секунд от запроса до начала работы
- Параллельность — один инженер может запустить 5-6 агентов одновременно
Важно понимать: Stripe не считает каждый PR идеальным. Частично корректный пулл-реквест, который инженер доработает за 20 минут, — это уже серьёзный выигрыш. Система спроектирована с учётом этой реальности.
Архитектура агентов
Изолированные окружения — devbox-ы
Автономному агенту нужны три свойства от рабочей среды: изоляция (ошибки не затрагивают прод), параллельность (несколько агентов работают одновременно) и предсказуемость (каждый агент стартует с чистого состояния).
Stripe уже имел всё это. Их «devbox-ы» — облачные машины, предзагруженные с полной кодовой базой, инструментами и сервисами. Они поднимаются за 10 секунд, потому что Stripe заранее провизионирует и прогревает пул машин — клонирует репозитории, прогревает кеши и запускает фоновые сервисы. Инженеры и раньше использовали по одному devbox-у на задачу, а один инженер мог держать полдюжины одновременно. Агенты просто встроились в этот паттерн.
Поскольку devbox-ы работают в QA-окружении, они уже изолированы от продакшен-данных и реальной пользовательской информации. Агенты получают полные права без подтверждений — радиус поражения любой ошибки ограничен одной одноразовой машиной.
Блюпринты — гибрид workflow и агента
Есть два классических подхода к оркестрации LLM-систем:
- Workflow — фиксированный граф шагов, где каждый шаг делает одну конкретную вещь, а последовательность предопределена
- Agent — цикл, в котором LLM сама решает, что делать дальше, на основе результатов предыдущих действий
Workflow предсказуемы, но негибки. Агенты гибки, но ненадёжны. Stripe построил нечто среднее — «блюпринты» (blueprints).
Блюпринт — это последовательность узлов, в которой одни узлы выполняют детерминированный код, а другие запускают агентный цикл. Представьте структуру, которая чередует жёсткие и креативные шаги:
- Шаг «реализуй фичу» или «исправь ошибки CI» — полный агентный цикл с инструментами и свободой действий
- Шаг «запусти линтеры» — захардкожен, всегда выполняется одинаково
- Шаг «запуши ветку» — захардкожен, строго по шаблону PR компании
Такое разделение экономит токены, снижает количество ошибок и гарантирует, что критические шаги выполняются каждый раз. При сотнях запусков в день каждый детерминированный узел — это одна проблема меньше, и этот эффект накапливается.
Контекст — как не утонуть в сотнях миллионов строк
У LLM ограниченное контекстное окно. Если загрузить все правила и конвенции глобально, контекст заполнится до того, как агент начнёт работать. Stripe использует глобальные правила «очень осторожно» — вместо этого они привязывают правила к конкретным директориям и паттернам файлов. Когда агент перемещается по файловой системе, он автоматически подхватывает только релевантные правила.
Для информации, которая не живёт в файловой системе, Stripe построил централизованный сервер Toolshed. Он хостит почти 500 инструментов через MCP (Model Context Protocol) — открытый стандарт, который даёт агентам единый способ вызывать внешние сервисы. Через MCP агенты получают доступ к внутренней документации, деталям тикетов, статусам билдов, результатам поиска по коду и многому другому.
Но больше инструментов — не значит лучше. Агенты работают лучше с тщательно подобранным подмножеством, релевантным их задаче. Stripe даёт Minions небольшой набор по умолчанию и позволяет инженерам добавлять дополнительные при необходимости.
Модели и обратная связь
Stripe не раскрывает конкретные модели, которые используют Minions, но архитектура сознательно абстрагирована от конкретной LLM. Ключевое значение имеет не модель, а инфраструктура обратной связи:
- Локальный линтинг — запускается при каждом push за менее чем 5 секунд. Фоновый демон заранее вычисляет, какие правила линтинга применимы, и кеширует результаты
- CI — выборочно запускает тесты из батареи в 3+ миллиона тестов. Автофиксы применяются автоматически для известных паттернов ошибок
- Повторная попытка — если после автофикса ошибки остались, агент получает ещё один шанс исправить и запушить
Затем — стоп. Максимум два цикла CI. Если код не проходит после второго push-а, ветка возвращается инженеру. Это ограничение осознанное: LLM показывают убывающую отдачу при повторных попытках решить ту же проблему. Больше раундов — больше токенов и вычислений без пропорционального улучшения.
Какие задачи решают агенты
Minions лучше всего справляются с задачами, которые хорошо определены, повторяемы и поддаются автоматической проверке:
- Миграции кода — перевод со старых API на новые, обновление паттернов использования библиотек
- Обновление зависимостей — bump версий, адаптация кода к breaking changes
- Исправления безопасности — применение патчей по известным уязвимостям
- Рефакторинг — переименование, перемещение модулей, приведение к единому стилю
- Мелкие баг-фиксы — исправления, которые накапливаются в on-call очереди за ночь
Чего Minions не делают:
- Не проектируют новую архитектуру
- Не принимают продуктовых решений
- Не пишут код, требующий глубокого понимания бизнес-логики
- Не работают с задачами, которые нельзя проверить автоматическими тестами
Это ключевое отличие от «attended» инструментов вроде Cursor или Claude Code, которые работают вместе с разработчиком. Инженеры Stripe используют и те, и другие — для разных типов задач.
Результаты и метрики
Stripe не публикует детальные внутренние метрики, но из публичных материалов и выступлений инженеров можно выделить ключевые результаты:
- 1300+ PR в неделю — объём, эквивалентный работе десятков инженеров
- Сдвиг от написания к ревью — инженеры не исчезли, но их роль изменилась: вместо написания кода они проверяют код, созданный агентами
- Частично корректные PR — даже неидеальные результаты экономят время, потому что доработка занимает 20 минут вместо нескольких часов с нуля
- Масштабирование без найма — рутинные задачи снимаются с инженеров, позволяя команде фокусироваться на сложной архитектурной работе
Четыре уровня системы, которые обеспечивают эти результаты:
- Изолированные окружения — безопасные параллельные рабочие пространства
- Гибридная оркестрация — детерминированные гарантии плюс агентная гибкость
- Курированный контекст — правильная информация без перегрузки
- Быстрая обратная связь с жёсткими лимитами на итерации
Чему учит опыт Stripe
Главный инсайт Stripe: инвестиции в продуктивность разработчиков, сделанные за годы до появления LLM, дали неожиданные дивиденды, когда агенты появились в рабочем процессе.
Уроки, которые можно вынести:
- Начинайте не с выбора модели, а с инфраструктуры. Окружения разработчика, тестовая инфраструктура, пайплайны обратной связи — если они хороши, агенты получат от них выгоду. Если нет — никакая модель не спасёт
- Разделяйте детерминированное и агентное. Линтинг, push, создание PR — это не задачи для LLM. Захардкодьте то, что можно захардкодить
- Ставьте жёсткие ограничения. Максимум два цикла CI — один из самых важных дизайн-решений Stripe. Знать, когда остановиться, так же важно, как знать, с чего начать
- Начинайте с рутины. Миграции, обновления зависимостей, патчи безопасности — это идеальные первые кандидаты для автономных агентов
- Человеческое ревью никуда не уходит. Роль инженера смещается от написания кода к проверке кода. Это не замена людей, а усиление команды
Когда стоит задуматься о внедрении подобного подхода? Если у вас уже есть: надёжная CI/CD-инфраструктура, изолированные окружения для разработки и достаточно рутинных задач, которые поддаются автоматизации.
Часто задаваемые вопросы
Какую LLM используют Minions в Stripe?
Stripe не раскрывает конкретную модель. Архитектура Minions сознательно абстрагирована от конкретной LLM — ключевую роль играет инфраструктура (devbox-ы, блюпринты, MCP-инструменты), а не сама модель. Это позволяет менять или обновлять модель без переписывания всей системы.
Могут ли Minions заменить разработчиков?
Нет. Minions решают рутинные, хорошо определённые задачи — миграции, обновления зависимостей, патчи. Архитектурные решения, продуктовое проектирование и задачи с нетривиальной бизнес-логикой по-прежнему требуют человека. Роль инженера смещается от написания к ревью кода.
Можно ли повторить подход Stripe в небольшой компании?
Принципы масштабируемы: изолированные окружения, гибрид детерминированных и агентных шагов, курированный контекст, жёсткие лимиты на итерации. Но для полноценной реализации нужна зрелая CI/CD-инфраструктура и достаточный объём повторяемых задач. Начните с малого — автоматизируйте один тип рутинной задачи и расширяйте по мере роста доверия к системе.
Что такое MCP и зачем он нужен агентам?
Model Context Protocol (MCP) — это открытый стандарт, который даёт ИИ-агентам единообразный способ вызывать внешние сервисы. Stripe использует MCP для подключения почти 500 внутренних инструментов — от поиска по коду до статусов билдов. Благодаря MCP агенты получают доступ к нужной информации через стандартизированный интерфейс.
Выводы
Опыт Stripe показывает: будущее разработки — это не замена инженеров агентами, а построение инфраструктуры, в которой агенты становятся ещё одним типом участников инженерного процесса. 1300 PR в неделю без единой строчки человеческого кода — это результат не прорыва в ИИ, а многолетних инвестиций в developer experience.
Ключевой вопрос не «какую модель выбрать», а «готова ли наша инфраструктура к агентам». Изолированные окружения, быстрые тесты, чёткие ограничения, курированный контекст — всё это можно и нужно строить уже сейчас, вне зависимости от того, когда именно вы запустите первого агента.
Если тема ИИ-агентов в разработке вам интересна, рекомендуем изучить оригинальные статьи в Stripe Engineering Blog.
