3.025 pull requests en diez meses: un proceso de entrega con IA, desde dentro

Una plataforma para centros de formación empezó en un generador de apps con IA y hoy es un SaaS multiinquilino con app web, apps nativas para iOS y Android, 160 funciones serverless y 1.048 archivos de tests automatizados. En diez meses se fusionaron 3.025 pull requests, la mayoría escritas por agentes de código y cada una revisada, probada y publicada pasando por las mismas siete etapas. Una segunda plataforma, para un negocio de hostelería, llegó a 2.133 en seis meses de la misma forma. Así es ese proceso en el día a día, ahí están las dos puertas duras y esto es lo primero que montaría si empezara de nuevo mañana.

Dominik Heinrich

8 de noviembre de 202611 min de lectura

1. El montaje: un ingeniero principal, varios agentes, un proceso

Fui arquitecto e ingeniero principal de principio a fin. El código lo escribieron en gran parte agentes, Claude Code y Codex, trabajando en tickets en paralelo, cada uno en su propia rama. Eso solo funciona si los agentes no pueden hacer daño por su cuenta, así que el proceso fue antes que la velocidad: React en Vercel, Supabase Postgres con row-level security en cada tabla, edge functions y tareas programadas, apps nativas cuyos design tokens se generan desde el CSS web, y un pipeline de release que trata cada cambio igual, lo escriba quien lo escriba.

3.025 pull requests fusionadas en diez meses son unas 300 al mes. La cifra en sí no es lo importante; lo que importa es que cada una era lo bastante pequeña para revisarla, reversible, y pasó por staging antes de producción. La guía que escribí sobre este proceso describe las siete etapas de forma compacta. Así se viven en la práctica.

2. Barandillas antes del primer prompt

Cada repositorio tiene un archivo de instrucciones breve que los agentes leen al empezar cada sesión: la arquitectura en pocas líneas, las convenciones, cómo ejecutar los tests y una lista de lo que un agente puede y no puede hacer. Las reglas duras son pocas y absolutas. La autenticación, los pagos, el borrado de datos y los secretos siempre necesitan aprobación humana. Los agentes nunca tocan datos de producción ni cuentas reales de clientes; reciben cuentas de prueba en staging y nada más.

El archivo de instrucciones no es documentación por gusto. Es la forma más barata de no cometer dos veces el mismo error. Sin él, cada sesión empieza de cero y un agente repetirá encantado un patrón de migración que rompió staging la semana pasada. Con él, la lección se escribe una vez y cada sesión futura empieza con ella.

markdown

# AGENTS.md (excerpt)
## Never without a human approval
- auth, payments, data deletion, secrets, production config
## Never
- push to main, touch production data or real customer accounts
## Always
- one ticket = one PR; migrations idempotent, dry-run before merge
- run unit tests + type check before asking for review
## Lessons (append, never delete)
- <date>: <what went wrong> -> <the rule that prevents it>

Entrega con IA en siete etapas: barandillas (archivo de instrucciones, reglas duras), pull requests pequeñas (un ticket, una PR), staging (misma compilación que producción), verificación (tests y una prueba de navegador con IA, puerta: tests en verde), revisión de impacto (riesgo y camino de vuelta, puerta: una persona aprueba), publicar y vigilar (smoke tests, monitorización, una incidencia por fallo) y aprender (lecciones de vuelta a los archivos de instrucciones), con un bucle de la última etapa a la primera. — Siete etapas, dos puertas duras. Los agentes escriben el código; las personas aprueban lo que llega a producción; cada lección vuelve a las barandillas.

3. Cambios pequeños y reversibles, primero staging

Un ticket, una pull request, con protección de rama en main para que nadie, persona o agente, haga push directo. Una pull request que cambia mil líneas en diez funcionalidades no se puede revisar bien, por buena que sea la revisora, así que a los agentes se les pide el cambio más pequeño que cierre el ticket. Las migraciones de base de datos son idempotentes y se ejecutan en modo prueba contra la base de datos de destino antes de fusionar nada.

Cada cambio llega a un entorno de staging con la misma compilación y configuración que producción antes de acercarse a los clientes. En el release se despliegan solo las funciones que han cambiado de verdad, así cada release es pequeño y cada marcha atrás es evidente. Es la parte poco vistosa, y de ella sale casi toda la velocidad: si cada paso es pequeño y reversible, nadie tiene miedo de fusionar.

4. Verificar como un usuario, no como un compilador

Tipos en verde y tests unitarios en verde son necesarios, pero no suficientes. La plataforma tiene 1.048 archivos de tests automatizados, y la comprobación de tipos y el linter se miden contra líneas base que solo pueden mejorar, para que los agentes no empeoren nada en silencio. Aquí está la primera puerta dura: no se fusiona nada si los tests no están en verde.

Además, cada flujo se comprueba como lo viviría un usuario. Para eso construí un probador de navegador con IA: describes el flujo en lenguaje normal, por ejemplo 'una formadora crea una sesión, un alumno firma con el código QR, la formadora ve la firma sin recargar', y un agente recorre el flujo en un Chrome real y devuelve un aprobado o suspenso con errores de consola, peticiones fallidas y un prompt de corrección. Montar una prueba así lleva nueve pasos en vez de unos doscientos, y los flujos con varios roles como este son justo donde los tests clásicos se quedan cortos.

5. Revisión de impacto, y luego una persona dice que sí

Antes de que un release vaya a producción, una tabla corta responde a cuatro preguntas: qué cambia, a quién afecta, cuál es el riesgo y cuál es el camino de vuelta. Los agentes la redactan a partir de las pull requests; yo la leo. Esta es la segunda puerta dura: una persona aprueba cada fusión a producción. Lleva minutos, porque los cambios son pequeños y la tabla es corta, y atrapa los casos en que un cambio técnicamente correcto es lo que no toca un viernes por la tarde o en la semana de auditoría de un cliente.

No se trata de desconfiar de los agentes. Se trata de que las decisiones de release necesitan un contexto que no está en el código: un cliente a punto de incorporarse, una cola de soporte, una migración prevista. Ese contexto lo tienen las personas, así que la decisión también.

markdown

## Release <date> — impact check (template, example rows)
| change                         | who is affected        | risk   | way back                 |
|--------------------------------|------------------------|--------|--------------------------|
| attendance flow change         | trainers, learners     | low    | revert PR, redeploy fn   |
| new invoice field              | admins of all tenants  | medium | migration is additive    |
| CRM scoring update             | sales users            | low    | feature flag off         |
Approved by: ____  (no production merge without a name here)

6. Publicar, vigilar y dejar que los fallos abran tickets

Tras cada despliegue, unos smoke tests recorren las rutas vitales del sistema en directo, como el inicio de sesión y el checkout. Si una falla, el despliegue se pone en rojo y el cambio se revierte. La monitorización vigila resultados en lugar de CPU: ¿se registró la asistencia?, ¿salió la factura? Cada fallo abre automáticamente una incidencia, y la incidencia se cierra sola cuando la comprobación se recupera, así el backlog muestra problemas reales y no ruido de alertas.

Debajo está la red que nadie ve: copias cifradas siete veces al día, archivos replicados en un segundo proveedor y una restauración nocturna en un proyecto gemelo aparte que demuestra que las copias funcionan. Con agentes escribiendo código a este ritmo, poder deshacerlo todo, datos incluidos, es lo que hace aceptable ese ritmo.

7. Cerrar el círculo y medir lo correcto

Cada incidente, cada comentario de revisión que se repite, cada migración que falló en staging termina con una pregunta: ¿qué línea del archivo de instrucciones lo habría evitado? Esa línea se añade. Las respuestas a clientes las redacta un agente y las envía una persona. Con los meses, esto es lo que convierte un equipo rápido en uno seguro: las reglas crecen con el producto.

Mide el tiempo desde el ticket hasta producción, la tasa de fallo de los cambios, las pull requests fusionadas por semana y los errores que encuentran los usuarios, el mismo tipo de métricas de entrega que usa la investigación DORA. No midas líneas de código; los agentes las producen gratis. Si quieres empezar, empieza por las barandillas y staging, no por más agentes. La comprobación de madurez de abajo muestra en qué punto está un código antes de añadir velocidad.

Conclusión
Los agentes pueden escribir la mayor parte del código. El proceso decide si eso es un riesgo o una ventaja: cambios pequeños y reversibles, dos puertas duras en manos de personas y cada lección escrita de vuelta en las reglas.

Proyectos reales relacionados

Del prototipo con IA a un SaaS en producción

Pruébalo tú mismo

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos