Por que a Stripe abandonou o localhost ao rodar centenas de agentes — e depois de testar a noite toda, eu entendi o motivo

Ontem à noite, o hackathon tinha uma regra simples: às 20h eu configurava a especificação e o harness, e às 8h da manhã tirava as mãos do teclado. Doze horas de experimento — produto construído exclusivamente por agentes.

Foi nessas 12 horas que entendi, na prática, por que a Stripe declarou “o localhost acabou” ao lançar a plataforma Minions, e por que a Ramp chegou à mesma conclusão ao descrever a construção do Inspect, seu próprio agente em background.

Rodar agentes em paralelo no notebook vira briga

Quando vários agentes rodam na mesma máquina, o estado começa a colidir. Segredos se sobrepõem, portas conflitam, e se a máquina entrar em modo de suspensão, o loop de 12 horas vai inteiro para o lixo.

Quando a Stripe e a Ramp publicaram suas arquiteturas de agentes, havia um ponto em comum: ambas adotaram a estratégia de dar a cada agente uma VM isolada e um container de desenvolvimento próprio.

Os Minions da Stripe rodam num ambiente isolado chamado “devbox” — mesmo tipo de máquina que os engenheiros usam, mas completamente isolado dos recursos de produção e da internet. O spin-up leva 10 segundos e suporta execução paralela de tarefas sem o overhead de git worktrees.

O Inspect da Ramp foi construído sobre o Modal Sandbox. Cada sessão tem seu próprio stack completo — Postgres, Redis, Temporal, RabbitMQ — sem nenhuma disputa entre sessões. E graças aos snapshots do sistema de arquivos, a inicialização é quase instantânea.

Agentes de codificação interativos precisam da sua atenção. Agentes em background não precisam de nenhuma das duas coisas. Durante a madrugada, vi com os próprios olhos o loop inteiro parar por causa de uma única suspensão da máquina. Em uma VM na nuvem, isso simplesmente não acontece.

Executar tarefas em sequência gera só features simples

Esse foi o ponto mais doloroso do hackathon. Rodando agentes de forma sequencial, o CRUD básico sai. O problema começa quando surgem dependências. O que um módulo entregou na frente era constantemente sobrescrito ou quebrado pelo agente que rodava depois.

Aqui é onde vale separar dois conceitos: agent fleet e agent swarm.

Agent fleet é o padrão usado para aplicar uma mesma mudança em vários repositórios ao mesmo tempo. É por isso que a Stripe consegue mergear mais de 1.000 PRs por semana: a mesma migração, a mesma correção de lint, empurrada para centenas de serviços de uma vez.

Agent swarm é o padrão onde agentes diferentes cuidam de partes distintas e convergem para um único resultado — frontend, backend e testes em agentes separados, integrados via PRs.

Sem execução paralela seguida de merge por PR, produtos complexos simplesmente não saem. Testei os dois na prática e a diferença de qualidade entre paralelo com revisão de merge e sequencial foi gritante.

Rate limit e comunicação entre agentes são problemas de infraestrutura, não de prompt

Nas 12 horas de loop, evitar rate limit era impossível. Além disso, o fluxo precisava que um agente revisasse commits feitos por outro e reinterpretasse automaticamente partes ambíguas da especificação.

Existe uma frase que resume bem: “escrever ‘não delete arquivos’ no system prompt é um pedido, não um controle.” É exatamente isso.

A Stripe resolveu isso na camada de execução. Os Minions têm acesso a recursos de produção e à internet bloqueados na origem — o que permite execução segura sem precisar checar permissões a cada passo. Mais de 400 ferramentas MCP são hospedadas num servidor interno chamado “Toolshed”, com conjuntos curados de ferramentas acessíveis por cada agente.

A Ramp exige que os PRs sejam criados via GitHub OAuth, vinculados a contas reais de usuário — não a IDs de app. Isso garante estruturalmente que nenhum código seja mergeado sem revisão.

Travar o escopo de permissões na camada de execução, manter logs de auditoria e limitar o raio de falha: sem isso, nenhum time de segurança vai aprovar agentes autônomos em produção.

O indivíduo pode acelerar sem que a organização acelere junto

Existe um fenômeno que dá para chamar de “falso cume”: você adota agentes de codificação, os PRs explodem, mas o cycle time continua igual. As revisões acumulam, o CI quebra, os conflitos de merge se empilham.

No hackathon também foi assim — os agentes geravam código rápido. O gargalo era juntar e validar tudo isso.

A Stripe resolve esse gargalo com automação. Os Minions usam uma orquestração híbrida que intercala loops de agente com operações de código determinísticas. Lint, testes e operações git sempre terminam, mas sem sufocar a criatividade do agente. Os testes de CI têm limite de duas tentativas, para evitar loops infinitos.

A Ramp usa número de PRs mergeados como métrica central de sucesso. Mais de 50% dos PRs criados pelo Inspect são efetivamente mergeados, e mais de 80% do próprio Inspect foi escrito pelo Inspect.

Para a velocidade organizacional acompanhar, agentes em background precisam tratar revisão de PR, análise de falhas de CI e resolução de conflitos de merge antes que um humano precise intervir. A mudança essencial é sair do “in the loop” (controle direto) para o “on the loop” (revisão de resultado).

A batalha não é sobre velocidade de geração, mas sobre estrutura de integração

Gerar código rápido com agentes já é um problema resolvido. A Stripe tem mais de 1.000 PRs por semana criados por agentes; a Ramp tem mais da metade de todos os seus PRs gerados assim.

A verdadeira disputa é projetar o sistema que integra com segurança o que esses agentes produzem: ambiente de execução isolado, estrutura de paralelo com merge, governança no nível de infraestrutura e validação automatizada. Sem esses quatro pilares, o agente é só um brinquedo rápido.