Por qué Stripe abandonó localhost al escalar su flota de agentes, y lo que aprendí corriendo lo mismo toda la noche

Anoche el hackathon tenía una sola regla: a las 8 PM preparaba las especificaciones y el harness, y a las 8 AM me alejaba del teclado. Doce horas en las que solo los agentes podían escribir código.

En ese tiempo entendí, de primera mano, por qué Stripe al presentar su plataforma Minions y Ramp al compartir el proceso detrás de Inspect, su agente en background, llegaron a la misma conclusión: localhost ya no alcanza.

Correr agentes en paralelo en una sola máquina es una receta para el caos

Cuando varios agentes comparten la misma máquina, el estado se empieza a mezclar. Los secretos chocan, los puertos se pisan, y en el momento en que la máquina entra en modo suspensión, el loop de 12 horas se va a la basura.

Cuando Stripe y Ramp publicaron sus arquitecturas, había algo en común: los dos asignan una VM independiente y un contenedor de desarrollo a cada agente.

Los Minions de Stripe corren en lo que llaman un “devbox”, un entorno aislado que usa el mismo tipo de máquina que los ingenieros, pero completamente separado de los recursos de producción y del acceso a internet. Levanta en 10 segundos y soporta ejecución de tareas en paralelo sin el overhead de los git worktrees.

Inspect de Ramp está construido sobre Modal Sandbox. Cada sesión tiene su propio stack completo: Postgres, Redis, Temporal y RabbitMQ. No hay contención entre sesiones, y gracias a los snapshots del sistema de archivos el arranque es casi instantáneo.

Un agente de coding necesita mi laptop y mi atención. Un agente en background no necesita ninguna de las dos. Lo comprobé en carne propia: una sola vez que la máquina entró en suspensión, el loop entero se detuvo. En una VM en la nube eso no pasa.

Ejecutar tareas en secuencia solo produce features sencillas

Este fue el golpe más duro del hackathon. Con ejecución secuencial, los agentes producen CRUD sin problemas. El problema aparece en cuanto hay dependencias. Perdí la cuenta de cuántas veces un agente que arrancó después sobrescribió o rompió algo que otro ya había terminado.

Aquí es donde vale la pena distinguir entre una flota de agentes y un enjambre de agentes.

Una flota de agentes sirve para aplicar el mismo cambio a múltiples repositorios al mismo tiempo. Por eso Stripe puede mergear más de 1,000 PRs a la semana: la misma migración, la misma corrección de linting, empujada a cientos de servicios de golpe.

Un enjambre de agentes es cuando cada uno se encarga de una parte distinta y convergen en un solo resultado. Frontend, backend y tests en agentes separados, que luego se integran PR por PR.

Sin ejecución paralela seguida de un proceso de merge claro, no se puede construir un producto complejo. Lo viví: la diferencia en calidad entre la combinación paralelo + revisión de merge y la ejecución secuencial fue enorme.

El rate limit y la comunicación entre agentes son problemas de infraestructura, no de prompts

En 12 horas, toparse con el rate limit era inevitable. Además necesitaba que un agente revisara los commits de otro y que las partes ambiguas de las especificaciones se reevaluaran automáticamente.

Hay una frase que lo resume bien: “escribir ‘no borres archivos’ en el system prompt es un ruego, no un control”. Exactamente.

Stripe resuelve esto en la capa de ejecución. Los Minions tienen bloqueado el acceso a recursos de producción y a internet desde el inicio, así que pueden correr de forma segura sin necesidad de verificar permisos en cada paso. Más de 400 herramientas MCP están alojadas en un servidor interno llamado “Toolshed”, y el conjunto de herramientas al que tiene acceso cada agente está curado.

Ramp usa OAuth de GitHub para que todos los PRs queden asociados a una cuenta de usuario real, no a un ID de aplicación. Eso hace que estructuralmente sea imposible que el código se mergee sin revisión.

Acotar los permisos en la capa de ejecución, mantener logs de auditoría y limitar el radio de impacto de un fallo: sin eso, el equipo de seguridad nunca va a aprobar agentes autónomos.

Una persona puede volverse más rápida sin que la organización lo sea

Hay un fenómeno que podría llamarse “cima falsa”: cuando se adoptan agentes de coding, los PRs se multiplican pero el cycle time no mejora. Se acumulan los code reviews pendientes, el CI se rompe y los conflictos de merge se apilan.

En el hackathon el problema no era que los agentes tardaran en escribir código. El tiempo se perdía en el cuello de botella de integrar y validar todo lo que producían.

Stripe resuelve ese cuello de botella con automatización. Minions usa una orquestación híbrida que intercala el loop del agente con operaciones de código deterministas. Garantiza que linting, tests y operaciones de git siempre terminen, pero preserva la capacidad creativa del agente. Incluso limita los reintentos en los tests del CI a un máximo de dos para evitar loops infinitos.

Ramp usa la cantidad de PRs mergeados como métrica principal de éxito. Más del 50% de los PRs que crea Inspect terminan siendo mergeados, e Inspect mismo fue escrito en más del 80% con Inspect.

Para que la velocidad organizacional acompañe a la individual, los agentes en background tienen que procesar las revisiones de PR, analizar fallas del CI y resolver conflictos de merge antes que las personas. El cambio de fondo es pasar de “in the loop” —controlando cada paso— a “on the loop” —revisando solo los resultados.

La ventaja real no está en producir más rápido, sino en saber integrar bien

Producir código rápido ya es un problema resuelto. Stripe tiene agentes generando más de 1,000 PRs por semana; en Ramp, más de la mitad de todos los PRs los crean agentes.

El verdadero diferenciador es diseñar el sistema que integra de forma segura todo lo que esos agentes producen: entornos de ejecución aislados, arquitectura de paralelo más merge, gobernanza a nivel de infraestructura y automatización de la validación. Sin esos cuatro pilares, los agentes son solo juguetes rápidos.