Stripe Minions: más de 1.300 pull requests a la semana
Los agentes de programación Stripe Minions ya producen más de 1.300 pull requests integrados por semana, dijo Stripe en una publicación de ingeniería del 19 de febrero de 2026, frente a 1.000 antes. Un humano revisa cada cambio, pero ninguno contiene código escrito por humanos. Para los equipos de ingeniería, el caso muestra a agentes sin supervisión que asumen el flujo constante de pequeñas actualizaciones y correcciones, mientras los ingenieros conservan la última palabra en cada integración.
Por qué Stripe quería agentes que trabajen sin que un humano los vigile
El problema de Stripe era la escala en una base de código donde los errores son costosos. El código en el que trabajan sus agentes respalda más de 1 billón de dólares en volumen anual de pagos y funciona con dependencias de instituciones financieras, marcos regulatorios y obligaciones de cumplimiento, informa InfoQ.
Los ingenieros de Stripe ya tenían herramientas interactivas como Cursor y Claude Code, pero funcionan como acompañante, con un ingeniero atento a cada paso. Stripe quería otro tipo de herramienta: una que reciba una sola instrucción y devuelva un pull request terminado sin que nadie supervise la ejecución.
Qué construyó Stripe: los agentes Minions
Los Minions son los agentes de programación sin supervisión que Stripe desarrolló internamente. A fines de 2024, Stripe hizo un fork del agente de programación goose de Block y lo personalizó para su propia infraestructura de LLM, y luego centró el desarrollo en las necesidades de las ejecuciones sin supervisión.
«El aspecto más singular de los minions es la ausencia de un humano que supervise». — Stripe, sobre sus agentes de programación Minions
Una tarea puede empezar en un hilo de Slack, un reporte de error o una solicitud de función. El minion escribe el código, las pruebas y la documentación, y la ejecución termina con un pull request que un ingeniero revisa antes de integrarlo.
Cómo funcionan los Minions en el día a día
Cada minion corre en un devbox, el mismo entorno de desarrollo en la nube que usan los ingenieros de Stripe: una instancia de AWS EC2 con el código fuente de Stripe. Stripe mantiene un grupo de devboxes precalentados para que uno nuevo esté listo en 10 segundos, con los repositorios clonados y las cachés construidas. Como cada devbox está aislado, un error se queda dentro de una sola caja, así que el agente puede correr con todos los permisos y omitir los avisos de confirmación.
El trabajo sigue un blueprint, un flujo definido en código. Algunos pasos son ciclos del agente con margen para decidir, como «Implementar la tarea» o «Corregir fallas de CI». Otros son código fijo que nunca llama a un modelo, como «Ejecutar los linters configurados» o «Subir los cambios». Stripe dice que fijar en código los pasos predecibles ahorra tokens y costos de CI a escala y deja al agente menos margen de error.
Para aprender la base de código, los minions leen archivos de reglas limitados a carpetas y patrones de archivos específicos, en el mismo formato que usa Cursor, de modo que humanos y agentes comparten un solo conjunto de guías. Los cambios generados pasan luego por pipelines de CI/CD, pruebas automáticas y análisis estático antes de la revisión humana.
Qué muestran los resultados de Stripe Minions
El resultado medido es el volumen. En una publicación del 19 de febrero de 2026, Alistair Gray, de Stripe, escribió que más de 1.300 pull requests de Stripe integrados cada semana son producidos por completo por minions, frente a 1.000 en la primera parte de la serie. Un humano revisa cada uno y ninguno contiene código escrito por humanos.
El gerente de ingeniería Cameron Bernhardt escribió que los agentes producen cada vez más cambios de principio a fin. Los ingenieros de Stripe dicen que los minions rinden mejor en tareas bien definidas, como cambios de configuración, actualizaciones de dependencias y refactorizaciones menores. Stripe no ha publicado cifras de tiempo ahorrado, esfuerzo de revisión ni tasas de defectos.
Qué cambian los agentes de programación autónomos para los equipos de ingeniería
Para una empresa, la tarea que asumen los minions es el flujo constante de cambios pequeños y bien definidos que se acumulan en una base de código grande: actualizaciones, ajustes y limpiezas en los que nadie quiere gastar una tarde. Pasar ese trabajo a los agentes libera a los ingenieros para el diseño y la revisión, y mantiene a una persona responsable de cada integración.
El caso de Stripe también muestra adónde va la inversión. El modelo es solo una parte. Las mejoras vienen de infraestructura construida antes para humanos: entornos de desarrollo rápidos y aislados, buenas pruebas y archivos de reglas compartidos. Los equipos de Stripe también han creado sus propios blueprints para migraciones de toda la base de código que un simple cambio de código con script no podía manejar.
Preguntas y respuestas
¿Cuántos pull requests producen los Minions de Stripe?
Más de 1.300 pull requests integrados por semana son producidos por completo por minions, frente a 1.000 antes, según el blog de ingeniería de Stripe.
¿Revisan los humanos el código generado por IA de Stripe?
Sí. Un ingeniero humano revisa cada pull request de un minion antes de integrarlo, aunque el código en sí no tenga líneas escritas por humanos.
¿En qué tareas son mejores los agentes de programación de Stripe?
En tareas bien definidas, como cambios de configuración, actualizaciones de dependencias y refactorizaciones menores, dicen los ingenieros de Stripe.
La visión de MOZGII
Cómo lo construiríamos
El caso de Stripe muestra que un agente de programación sin supervisión es sobre todo un proyecto de infraestructura. El modelo escribe el código, pero la máquina de desarrollo aislada, el conjunto de pruebas y los archivos de reglas compartidos deciden si ese código es seguro de integrar. Una empresa sin esas piezas obtendría más pull requests y más riesgo al mismo tiempo.
Si construyéramos esto, empezaríamos eligiendo una tarea acotada y aburrida, como actualizar dependencias, y escribiendo cómo se ve un cambio correcto. Cada ejecución del agente ocurriría en un entorno desechable, sin acceso a producción ni a credenciales personales. Los pasos fijos, como el lint y la subida de cambios, serían código común, y el modelo se ocuparía solo de las partes que requieren criterio. Cada pull request indicaría el nombre del ingeniero que lo revisó.
Se rompería en la revisión. Cuando los agentes producen cientos de cambios por semana, los revisores empiezan a leer por encima, y un cambio pequeño y equivocado en código de pagos puede pasar porque se parece al anterior. Los archivos de reglas también se desactualizan a medida que cambia la base de código. La métrica que vigilaríamos es la proporción de pull requests de agentes que luego se revierten o se corrigen, comparada con la de los humanos.
Después construiríamos una cola de revisión que ordene los cambios de agentes por riesgo, para que las ediciones pequeñas de configuración tengan una verificación rápida y los cambios cerca del movimiento de dinero tengan un segundo revisor.
Fuentes
De dónde salen los datos de esta nota.