Stripe Minions: agentes geram mais de 1.300 PRs por semana
Os agentes de código Stripe Minions já geram mais de 1.300 pull requests integrados por semana, disse a Stripe em um post de engenharia de 19 de fevereiro de 2026, contra 1.000 antes. Cada mudança é revisada por uma pessoa, mas não contém nenhum código escrito por humanos. Para times de engenharia, o caso mostra agentes sem supervisão assumindo o fluxo constante de pequenas atualizações e correções, enquanto os engenheiros mantêm a palavra final em cada merge.
Por que a Stripe queria agentes que trabalham sem ninguém olhando
O problema da Stripe era a escala em uma base de código onde os erros custam caro. O código em que seus agentes trabalham sustenta mais de 1 trilhão de dólares em volume anual de pagamentos e roda sobre dependências com instituições financeiras, marcos regulatórios e obrigações de conformidade, informa o InfoQ.
Ferramentas interativas como Cursor e Claude Code já estavam à disposição dos engenheiros da Stripe, mas funcionam como companhia, com um engenheiro acompanhando cada passo. A Stripe queria outro tipo de ferramenta: uma que recebe uma única instrução e devolve um pull request pronto, sem ninguém supervisionando a execução.
O que a Stripe construiu: os agentes Minions
Os Minions são os agentes de código sem supervisão criados na própria Stripe. No fim de 2024, a Stripe fez um fork do agente de código goose, da Block, e o adaptou à sua infraestrutura de LLMs, concentrando depois o desenvolvimento nas necessidades de execuções sem supervisão.
"O aspecto mais singular dos minions é a ausência de um humano supervisor." — Stripe, sobre seus agentes de código Minions
Uma tarefa pode começar em uma conversa do Slack, em um relato de bug ou em um pedido de funcionalidade. O minion escreve o código, os testes e a documentação, e a execução termina com um pull request que um engenheiro revisa antes de ele ser integrado.
Como os Minions funcionam no dia a dia
Cada minion roda em um devbox, o mesmo ambiente de desenvolvimento na nuvem que os engenheiros da Stripe usam: uma instância AWS EC2 com o código-fonte da Stripe. A Stripe mantém um conjunto de devboxes já aquecidos para que um novo fique pronto em 10 segundos, com repositórios clonados e caches montados. Como cada devbox é isolado, um erro fica dentro de uma caixa, e o agente pode rodar com todas as permissões e pular as confirmações.
O trabalho segue um blueprint, um fluxo definido em código. Alguns passos são ciclos do agente com liberdade para decidir, como "Implementar a tarefa" ou "Corrigir falhas de CI". Outros são código fixo que nunca chama um modelo, como "Rodar os linters configurados" ou "Enviar as mudanças". A Stripe diz que fixar em código os passos previsíveis economiza tokens e custos de CI em escala e dá ao agente menos espaço para errar.
Para aprender a base de código, os minions leem arquivos de regras restritos a pastas e padrões de arquivo específicos, no mesmo formato que o Cursor usa, para que humanos e agentes compartilhem um único conjunto de orientações. As mudanças geradas passam então por pipelines de CI/CD, testes automatizados e análise estática antes da revisão humana.
O que mostram os resultados dos Stripe Minions
O resultado medido é o volume. Em um post de 19 de fevereiro de 2026, Alistair Gray, da Stripe, escreveu que mais de 1.300 pull requests da Stripe integrados por semana são produzidos inteiramente pelos minions, contra 1.000 na primeira parte da série. Todos são revisados por uma pessoa, e nenhum contém código escrito por humanos.
O gerente de engenharia Cameron Bernhardt escreveu que os agentes produzem cada vez mais mudanças de ponta a ponta. Engenheiros da Stripe dizem que os minions vão melhor em tarefas bem definidas, como mudanças de configuração, atualizações de dependências e pequenas refatorações. A Stripe não publicou números de tempo economizado, esforço de revisão ou taxa de defeitos.
O que os agentes de código autônomos mudam para times de engenharia
Para uma empresa, a tarefa que os minions assumem é o fluxo constante de mudanças pequenas e bem definidas que se acumulam em uma base de código grande: atualizações, configurações e limpezas em que ninguém quer gastar uma tarde. Passar esse trabalho para agentes libera os engenheiros para projeto e revisão, mantendo uma pessoa responsável por cada merge.
O caso da Stripe também mostra para onde vai o investimento. O modelo é só uma parte. Os ganhos vêm da infraestrutura montada antes para humanos: ambientes de desenvolvimento rápidos e isolados, bons testes e arquivos de regras compartilhados. Times da Stripe também criaram seus próprios blueprints para migrações em toda a base de código que uma simples alteração de código por script não resolveria.
Perguntas e respostas
Quantos pull requests os Minions da Stripe produzem?
Mais de 1.300 pull requests integrados por semana são produzidos inteiramente pelos minions, contra 1.000 antes, segundo o blog de engenharia da Stripe.
Humanos revisam o código gerado por IA da Stripe?
Sim. Todo pull request de minion é revisado por um engenheiro antes de ser integrado, embora o código em si não tenha nenhuma linha escrita por humanos.
Em que tarefas os agentes de código da Stripe são melhores?
Em tarefas bem definidas, como mudanças de configuração, atualizações de dependências e pequenas refatorações, dizem engenheiros da Stripe.
A visão da MOZGII
Como nós construiríamos
O caso da Stripe mostra que um agente de código sem supervisão é, sobretudo, um projeto de infraestrutura. O modelo escreve o código, mas a máquina de desenvolvimento isolada, a suíte de testes e os arquivos de regras compartilhados decidem se esse código é seguro para integrar. Uma empresa sem essas peças teria mais pull requests e mais risco ao mesmo tempo.
Se fôssemos construir isso, começaríamos escolhendo uma tarefa estreita e chata, como atualização de dependências, e escrevendo o que é uma mudança correta. Cada execução do agente aconteceria em um ambiente descartável, sem acesso à produção nem a credenciais pessoais. Os passos fixos, como lint e envio, seriam código comum, e o modelo cuidaria só das partes que pedem julgamento. Todo pull request nomearia o engenheiro que o revisou.
O plano quebraria na revisão. Quando os agentes produzem centenas de mudanças por semana, os revisores passam a ler por cima, e uma pequena mudança errada em código de pagamentos pode passar por parecer com a anterior. Os arquivos de regras também ficam velhos conforme a base de código muda. A métrica que acompanharíamos é a parcela de pull requests de agentes revertidos ou corrigidos depois, em comparação com os de humanos.
Depois, montaríamos uma fila de revisão que ordena as mudanças dos agentes por risco, de modo que pequenas edições de configuração tenham uma checagem rápida e mudanças perto da movimentação de dinheiro tenham um segundo revisor.
Fontes
De onde vêm os fatos desta matéria.