# Por qué Stripe dejó atrás localhost al escalar su flota de agentes, y lo que aprendí probándolo toda una noche > Author: Tony Lee > Published: 2026-03-03 > URL: https://tonylee.im/es/blog/why-stripe-abandoned-localhost-for-agent-fleet/ > Reading time: 6 minutes > Language: es > Tags: ai, ai-agent, devops, infrastructure, stripe, developer-productivity ## Description Tras un hackathon de 12 horas construyendo un producto solo con agentes, entendí de primera mano por qué Stripe Minions y Ramp Inspect apostaron por entornos de ejecución aislados en la nube. ## Content Anoche me impuse una regla para el hackathon: dejar el entorno configurado a las ocho de la tarde y no volver a tocar el teclado hasta las ocho de la mañana. Doce horas en las que la responsabilidad de construir el producto recaería íntegramente en los agentes. Durante ese tiempo comprendí en carne propia por qué Stripe, al presentar su [plataforma Minions](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents), y Ramp, al compartir su experiencia construyendo [Inspect, su propio agente en segundo plano](https://builders.ramp.com/post/why-we-built-our-background-agent), llegaron a la misma conclusión: localhost se ha quedado obsoleto para este tipo de trabajo. ## Lanzar varios agentes en paralelo sobre un mismo equipo acaba en caos Cuando varios agentes conviven en la misma máquina, el estado se vuelve impredecible. Los secretos colisionan, los puertos se pisan entre sí, y en cuanto el equipo entra en modo suspensión, un bucle de doce horas entero se pierde para siempre. Cuando Stripe y Ramp hicieron públicas sus arquitecturas de agentes, ambas compartían un elemento central: cada agente opera en su propia máquina virtual y contenedor de desarrollo independientes. Los Minions de Stripe se ejecutan en lo que llaman "devboxes": entornos aislados que utilizan el mismo tipo de máquina que los ingenieros humanos, pero completamente desconectados de los recursos de producción y de internet. Se arrancan en menos de diez segundos y permiten ejecutar tareas en paralelo sin la sobrecarga de los git worktrees. El Inspect de Ramp está construido sobre Modal Sandbox. Cada sesión dispone de su propio entorno completo, incluyendo Postgres, Redis, Temporal y RabbitMQ. No hay ningún tipo de contención entre sesiones, y el arranque es casi instantáneo gracias a los snapshots del sistema de ficheros. Un agente de codificación interactivo necesita tu máquina y tu atención. Un agente en segundo plano no necesita ninguna de las dos. Durante el hackathon lo comprobé directamente: una sola suspensión del equipo paró todo el bucle. En una VM en la nube, ese problema simplemente no existe. ## Si encolas las tareas de forma secuencial, solo obtienes funcionalidades triviales Este fue el golpe más duro de la noche. Con ejecución secuencial, los agentes producen CRUD sin complicaciones. El problema aparece en cuanto existen dependencias entre módulos: el agente que llegaba más tarde sobreescribía o rompía lo que el anterior había construido. Una y otra vez. Aquí es donde conviene distinguir entre flota de agentes y enjambre de agentes. **Una flota de agentes** sirve para aplicar un mismo cambio a múltiples repositorios de forma simultánea. Así consigue Stripe fusionar más de mil pull requests a la semana: empujando la misma migración o corrección de linting a cientos de servicios de una sola vez. **Un enjambre de agentes** asigna partes distintas del problema a agentes diferentes para que converjan en un único resultado. Frontend, backend y tests en manos de agentes independientes que luego se integran mediante pull requests. Sin ejecución paralela seguida de integración por pull requests, construir un producto complejo es inviable. En la práctica, la diferencia en calidad entre el enfoque paralelo con revisión de merges y el secuencial fue evidente desde el primer momento. ## Los límites de peticiones y la coordinación entre agentes son un problema de infraestructura, no de prompts A lo largo de doce horas es imposible no toparse con los límites de peticiones de la API. Además, necesitaba que los agentes revisaran los commits de otros agentes y resolvieran automáticamente las ambigüedades de la especificación. Hay una frase que lo resume perfectamente: "escribir 'no borres ficheros' en el prompt del sistema es un ruego, no un control". Exactamente así. Stripe resolvió este problema en la capa de ejecución. Los Minions tienen bloqueado por diseño el acceso a los recursos de producción y a internet, lo que permite ejecutarlos de forma segura sin necesidad de comprobaciones de permisos en tiempo de ejecución. Más de 400 herramientas MCP están alojadas en un servidor interno llamado "Toolshed", y cada agente tiene acceso únicamente al conjunto de herramientas que le corresponde. Ramp diseñó su sistema para que todos los pull requests se creen obligatoriamente a través de una cuenta de usuario real mediante GitHub OAuth, no a través de un ID de aplicación. De este modo, el código no puede llegar a producción sin pasar por una revisión humana, como garantía estructural. Sin bloqueo de permisos en la capa de ejecución, sin registros de auditoría y sin un radio de impacto acotado para los fallos, ningún equipo de seguridad va a aprobar el uso de agentes autónomos. ## Un desarrollador más rápido no implica una organización más rápida Existe lo que podríamos llamar una "cima falsa": introduces agentes de codificación, los pull requests se multiplican, pero el cycle time no se mueve. Las revisiones se acumulan, la integración continua se rompe y los conflictos de merge se apilan. En el hackathon también lo viví: los agentes generaban código rápidamente. El cuello de botella no estaba ahí, sino en integrar y validar todo lo que producían. Stripe ataca este cuello de botella con automatización. Minions utiliza una orquestación híbrida que intercala bucles de agentes con operaciones de código deterministas. Garantiza que el linting, los tests y las operaciones de git siempre se completan, sin sacrificar la capacidad creativa del agente. Los tests de integración continua tienen un límite máximo de dos intentos para evitar bucles infinitos. Ramp mide el éxito por el número de pull requests fusionados. Más del 50 % de los PRs generados por Inspect llegan a fusionarse, y más del 80 % del propio Inspect fue escrito por Inspect. Para que la velocidad organizacional acompañe a la individual, los agentes en segundo plano deben encargarse de la revisión de PRs, del análisis de fallos en CI y de la resolución de conflictos de merge antes que las personas. El cambio esencial es pasar de estar "en el bucle" operando directamente, a estar "sobre el bucle" revisando únicamente los resultados. ## La ventaja competitiva no está en la velocidad de generación, sino en la arquitectura de integración Hacer que los agentes generen código rápido es un problema ya resuelto. Stripe fusiona más de mil PRs a la semana; en Ramp, los agentes son responsables de más de la mitad del total. El verdadero diferenciador es diseñar el sistema que permite integrar de forma segura todo lo que producen esos agentes: entornos de ejecución aislados, arquitectura paralela con integración por pull requests, gobernanza a nivel de infraestructura y automatización de la validación. Sin estas cuatro piezas en su lugar, los agentes no son más que un juguete veloz. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/es/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.