AI software factory: las 5 etapas de Stripe, Spotify y Shopify

Qué es una AI software factory y por qué cambia las reglas del juego

Una AI software factory no es un agente más inteligente: es la infraestructura alrededor del agente. El trabajo entra por una cola, los agentes corren en entornos aislados, la verificación ocurre antes de que un humano vea el diff y una persona decide en un gate explícito de merge. Sin la cola, sin los entornos desechables y sin la verificación automática, no hay fábrica: hay una máquina que genera más PRs de los que tu equipo puede absorber.

El 6 de enero de 2026, Stephen Toub abrió nueve pull requests desde su teléfono a 35.000 pies de altura. Siete se fusionaron. Toub trabaja en dotnet/runtime y su conclusión es la que define toda esta categoría: "la IA cambia la economía de producir código; una persona con buen criterio y un teléfono puede generar PRs más rápido de lo que un equipo las puede revisar".

Cuando un solo ingeniero satura la capacidad de review desde un asiento de avión, el problema deja de ser cómo hacer que los agentes escriban código y pasa a ser cómo absorber la salida.

Las cinco etapas que comparten todas las fábricas publicadas

Al leer las arquitecturas publicadas —las llamadas Minions de Stripe, Honk de Spotify, River de Shopify, Inspect de Ramp y Goose de Block— aparece el mismo esqueleto, aunque cada empresa lo bautice distinto:

• Intake: qué trabajo vale la pena empezar. Sentry puntúa cada error entrante con Seer antes de investigarlo.
• Isolation: dónde corre el agente sin colisionar. Stripe levanta devboxes pre-calentados en alrededor de 10 segundos.
• Tools: qué puede tocar el agente. Stripe expone cerca de 500 herramientas internas vía MCP desde Toolshed.
• Verification: si el cambio es correcto. Spotify veta con un juez LLM cerca del 25% de las sesiones de agente.
• Merge gate: quién responde. Faire exige dos revisiones humanas en PRs escritos por agentes.

La regla de oro que repiten todas las empresas que lo hicieron funcionar: construir las puertas antes que la flota. Spotify envió Fleetshift en 2023, dos años antes de tener un agente que poner dentro.

Stage 1: cómo llega el trabajo al agente (Intake)

Asignar un agente a cada issue abierto es la versión naive. Las versiones publicadas filtran primero. La regla de Shopify con River es directa: el agente no responde a mensajes directos, sugiere crear un canal público. Tobi Lütke lo explicó como una decisión organizacional, no técnica: una sesión privada enseña a una persona y muere con la ventana.

Microsoft publicó los números que justifican filtrar por tamaño: en dotnet/runtime, los PRs de agentes entre 1 y 50 líneas modificadas tuvieron una tasa de éxito del 76 al 80%, mientras que el trabajo de performance aterrizó en 54,5%. El propio resumen es elocuente: el coding agent de Copilot es "excelente implementando cambios bien especificados, muy bueno investigando issues y relativamente pobre arquitecturando soluciones".

El gate que casi nadie construye: ¿alguien ya resolvió esto upstream? En el flujo de Stripe —1.300 PRs de agentes fusionados por semana— lanzar agentes sobre problemas ya resueltos es exactamente el desperdicio que la fábrica existe para eliminar.

Stage 2: el modelo de aislamiento

Dos agentes editando el mismo directorio es la forma más rápida de perder un día. Hay tres modelos, en orden creciente de costo y capacidad:

• Git worktrees: aíslan archivos y rama, pero no puertos, bases de datos ni dependencias. Sirven para una máquina con 2 a 5 agentes. Claude Code los crea con --worktree.
• Containers: aíslan archivos, dependencias, red y procesos. Útiles cuando hay versiones conflictivas o cambios no confiables. Ejemplos: container-use, Sculptor.
• Sandboxes en la nube: aíslan todo y suman concurrencia ilimitada. Aquí están Stripe devboxes, Ramp sobre Modal y Spotify sobre Kubernetes.

El detalle que todos los tutoriales se saltan: un worktree es un checkout fresco, así que tu .env no está ahí, ni node_modules, ni un puerto libre. Ese es el verdadero punto de quiebre cuando llegas al cuarto agente. Claude Code resuelve la mitad de archivos ignorados con un .worktreeinclude en la raíz. Puertos y bases de datos los resuelves tú: asígnalos desde el nombre del worktree, no hardcodeados.

El modo de falla que nadie planifica: las sesiones interactivas preguntan al salir, pero las ejecuciones no interactivas con -p no limpian nada y cada una sostiene un lock hasta que un barrido lo libere. Si estás orquestando una flota, limpia explícitamente.

Stage 3: darle manos al agente, no solo cerebro

Un modelo con un repositorio es un autocompletar. Un modelo con tu test runner, tu telemetría, tus feature flags y tu deploy es un colega. La diferencia entre las dos cosas es la capa de herramientas, y es la menos glamorosa y más decisiva de la fábrica.

Las cifras publicadas muestran cuánto se la toman en serio los líderes: Stripe aloja cerca de 500 herramientas internas detrás de un servidor MCP; Cloudflare generó AGENTS.md en más de 3.900 repositorios; Ramp conecta tests, telemetría, feature flags y verificación visual en cada sandbox.

El apalancamiento está en que esto es configuración para toda la flota, no setup por agente. Un bloque MCP alcanza a cada agente.

Sobre los archivos de instrucciones, resistí la tentación de escribir un manual. El equipo de Codex en OpenAI corre un repositorio de cerca de un millón de líneas con un AGENTS.md de unas 100 líneas que funciona como mapa. Los datos de Microsoft validan el principio desde el otro lado: agregar .github/copilot-instructions.md y configuración de firewall movió el éxito del agente en dotnet/runtime de 41,7% a un sostenido 71%. La preparación valió más que cualquier upgrade de modelo en el mismo período.

Stage 4: verificación, donde realmente difieren las fábricas

Cada software factory genera código. Lo que las separa es lo que pasa entre la generación y los ojos de un humano, y este es el escenario con los resultados más contraintuitivos publicados.

El post de loops de feedback de Spotify describe la estructura más clara: loops anidados, del más barato al más caro. Loop interno con verificadores determinísticos —formato, compilación, tests, sin modelo de por medio. Un juez LLM que evalúa si el diff se mantuvo en scope y veta cerca del 25% de las sesiones; cerca de la mitad de esos vetos son recuperables reencauzando al agente. Loop externo con CI y PR checks.

Spotify también rankea sus modos de falla, y el ranking es lo útil. Un PR que falla CI es una carga para un ingeniero. Un PR que pasa CI y está funcionalmente mal erosiona la confianza en todo el sistema. Diseña hacia el primer fallo y aléjate del tercero.

La trampa del confidence score

El resultado negativo más valioso publicado en este espacio te va a ahorrar un trimestre. Faire construyó un revisor interno y probó primero la palanca obvia: filtrar comentarios por el propio confidence score del modelo. No funcionó. En el gate más estricto, tiró el 65% de los comentarios y la tasa de aceptación se movió 3%. Su writeup muestra un comentario con score 0,93 que fue descartado junto a uno con score 0,35 que fue aceptado y arreglado. Lo que subió la aceptación a 73% fue mejor contexto sobre el cambio, mejor targeting de dónde vale la pena comentar y gates calificados por modelo en lugar de un umbral determinístico. La confianza autoreportada no es señal de calidad; un segundo modelo preguntando "¿vale la pena gastar tiempo humano en este comentario?" sí lo es.

El verificador determinístico responde si el código compila y los tests pasan. Ninguna de las dos preguntas cubre si la página sigue viéndose bien. Un cambio de CSS puede pasar todos los checks y romper silenciosamente la vista móvil, porque casi nadie escribe tests que asserten que un layout es razonable. Dale al agente un browser y pinea la rutina como archivo de skill para que cada agente de la flota la corra igual.

GitHub cerró ese último paso el 1 de septiembre de 2026 con un flag repetible --attach en gh v2.99.0. Texto después de # se vuelve alt text; imágenes hasta 10MB; video hasta 10MB en planes free y 100MB en planes pagos. GitHub Enterprise Server no está soportado en este release.

Ordená tus checks por costo. Stripe capa los agentes en un máximo de dos corridas de CI antes de pasar a un humano. Con más de 3 millones de tests, una corrida de CI es el recurso caro. Lint y tests vuelven en menos de cinco segundos localmente; una consulta acotada al índice de developers cuesta 2 créditos por 10 resultados a septiembre de 2026; una corrida de CI sobre esa suite cuesta vastamente más. Cuando un agente escribe contra una API que recuerda a medias, verificar esa llamada contra issues reales, PRs y migration guides antes de pushear es prácticamente gratis.

Stage 5: el merge gate

Una política de merge de agentes es el escenario menos escrito y el que determina si la fábrica es un activo o un pasivo. La pregunta no es si un agente puede abrir un PR, sino qué tiene que ser cierto antes de que uno aterrice.

Las políticas publicadas se agrupan en tiers por blast radius:

• Cambios mecánicos reversibles: bump de dependencia, fix de lint, migración de tests. Checks automatizados, auto-merge.
• Feature o fix acotado: bug fix bajo 50 líneas, cobertura nueva. Una revisión humana.
• PRs de agente no triviales: cualquier cosa que toque comportamiento de producto. Dos revisiones, según la regla de Faire.
• Sensible por dominio: auth, pagos, criptografía, borrado de datos. Dueño de dominio nombrado, sin importar el autor.

Las reglas de Faire son el set publicado más concreto. Dos de las tres son sobre secuencia de revisión, no sobre la revisión en sí: requerir dos revisiones en PRs authored por Copilot, no pedir review a code owners hasta que el PR ya tenga una revisión, marcar ready for review solo cuando el agente lo solicite.

Luego está la atribución. La política 2026 del kernel de Linux establece que los agentes IA no deben agregar Signed-off-by: —porque ese trailer es una aserción legal que un modelo no puede hacer— y exige en su lugar un Assisted-by: AGENT_NAME:MODEL_VERSION. GitHub fue por el otro lado con Agent HQ, gestionando la identidad del agente como gestiona la de desarrolladores humanos. Ambos son defendibles. El silencio no lo es: seis meses después nadie puede contestar qué cambios vinieron de dónde.

Qué dicen los números reales (sin maquillar)

Los PRs de agentes se fusionan menos que los humanos. El review de Microsoft de diez meses en dotnet/runtime es el único dataset público con comparación apples-to-apples: PRs de agentes se fusionaron 67,9% contra 87,1% de ingenieros de Microsoft. La división por autonomía es más nítida: PRs con commits humanos 86,2%, completamente autónomos 55,1%. Las tasas de revert se sostuvieron en 0,6% contra 0,8%, así que lo que entra no es notablemente peor.

Pasar tests no es lo mismo que ser mergeable. METR pidió a maintainers de scikit-learn, Sphinx y pytest revisar 296 PRs de IA que ya habían pasado el grader automatizado de SWE-bench. Cerca de la mitad no se habrían mergeado —un gap de cerca de 24 puntos porcentuales contra el grader. El gap no se redujo entre modelos de mediados de 2024 a mediados de 2025.

El volumen tiene un costo de mantenibilidad. El análisis de GitClear sobre 211 millones de líneas cambiadas encontró bloques duplicados que se multiplicaron por ocho en 2024, líneas refactorizadas que cayeron de cerca del 25% de los cambios a menos del 10%, y churn que se duplicó de 3,3% a 7,1%.

Sobre eso, los números de adopción son reales y grandes. Shopify reporta 59.918 sesiones de River y 3.536 PRs coauthored por River mergeados en una ventana de 30 días; Lütke lo puso en proporción: "Cerca de uno de cada ocho pull requests mergeados en nuestro codebase la semana pasada fue authored por River, revisado por nosotros". Ramp llegó a cerca del 30% de PRs mergeados sin mandato alguno. Airbnb migró cerca de 3.500 archivos de test en seis semanas contra un estimado de 1,5 años a mano, con 75% hecho en las primeras cuatro horas. Lo que prueba es migración y mantenimiento mecánico a escala, no greenfield design.

¿Qué significa esto para tu startup?

La fábrica no es para vos si todavía no tenés un agente en uso. Pero si tu equipo ya está saturado de PRs de agentes y el review es el cuello de botella, hay tres decisiones que podés tomar este mes.

• Construí el gate antes que la flota. Un intake filter con label + query (issues marcados agent-eligible y de menos de 50 líneas) es la puerta más barata para evitar que tu CI se queme con trabajo que nunca debió empezar. Spotify mandó Fleetshift en 2023 sin tener aún un agente dentro; ese orden importa.
• Invertí en el contexto, no en el modelo. El salto de 41,7% a 71% de éxito en dotnet/runtime vino de un copilot-instructions.md y configuración de firewall, no de un modelo más grande. Si tu AGENTS.md es un manual de 500 líneas, borrá la mitad: el AGENTS.md de OpenAI corre un millón de líneas con 100 líneas de mapa.
• Frená el "AI slop" antes que se acumule. El equipo de Codex de OpenAI admitía que antes de automatizar el loop se gastaban cada viernes (20% de la semana) limpiando slop. Esa función tiene que vivir en tu pipeline de verificación, no en tu calendario.

Para equipos chicos sin recursos para construir toda la infraestructura propia, según reportó TechCrunch el 18 de agosto de 2026, Warp lanzó Warp Factories, un sistema out-of-the-box que da la arquitectura armada (triage, spec, implementación, review, verificación) y permite elegir modelo y harness. El CEO Zach Lloyd reportó que automatizan cerca del 30 al 35% de sus tareas semanalmente. Si tu cuello de botella es construir la fábrica desde cero, ese puede ser un atajo razonable.

El techo de esta categoría no lo va a definir quién tenga el mejor modelo. Lo va a definir quién construya mejor las puertas.

Fuentes

• How to Build an AI Software Factory: Agents That Open, Review, and Merge PRs (fuente original)
• Warp’s new system is an out-of-the-box software factory for AI development