"Agentic coding" fue nuestro primer acto: delegarle una tarea bien definida a un agente de IA, de a una por vez, y revisar lo que volvía. Esto es el segundo acto — cerrar el loop entero. No delegar una tarea, sino correr un ciclo cerrado que lleva un issue del backlog a código desplegado en un ambiente de test, casi sin que un humano lo empuje en el medio.
Con "loop engineering" no nos referimos a usar IA para escribir código. Nos referimos a diseñar un sistema con un puñado de puntos de control deliberados — un humano aprobando un refinamiento, un build promocionándose — y una serie de gates automáticos que frenan todo apenas algo falla. Todo lo que pasa entre esos puntos de control corre solo.
Este post cuenta cómo está armado ese loop hoy en DIZENZ: las dos etapas que lo componen, qué modelo hace qué tarea y por qué, por qué nuestro gate de calidad corre en la máquina de un desarrollador en vez de en GitHub Actions, y los números reales del proyecto que corrió este loop por más tiempo.
El Loop, de Punta a Punta
El loop son dos etapas encadenadas, cada una un agente o skill de Claude Code corriendo sobre el board del proyecto.
Etapa 1 — Refinar el backlog. Un agente toma un issue crudo y lo contrasta contra el repositorio real — nunca inventa un path ni un comportamiento, todo lo verifica leyendo el código. Deja el issue con un título claro, una historia de usuario, criterios de aceptación observables, detalle técnico y un checklist de QA manual.
Cuando el backlog tiene varios issues en cola, el mismo agente calcula además un mapa de impacto cruzado: cuáles issues se bloquean entre sí, cuáles tocan el mismo archivo y no se pueden paralelizar, cuáles son totalmente independientes. Ese mapa va a aprobación humana antes de escribir una sola línea — recién ahí un issue queda realmente "listo para desarrollar".
Título claro e historia de usuario
Convierte un issue crudo de una línea en un título e historia sobre los que cualquiera del equipo puede actuar.
Criterios de aceptación observables
Criterios escritos para que un test — humano o automatizado — pueda decir pasa o no pasa, no solo "parece correcto".
Detalle técnico, verificado
Cada path y comportamiento que cita está chequeado contra el repositorio real, nunca asumido.
Checklist de QA manual
Un checklist listo para QA antes de que exista una sola línea de código.
Mapa de impacto cruzado
Marca qué issues se bloquean entre sí y cuáles tocan el mismo archivo y no pueden correr en paralelo.
Gate de aprobación humana
El mapa y el issue refinado van a un humano antes de que el issue quede marcado como listo para desarrollar.
Etapa 2 — Implementar y desplegar. Un segundo agente toma esos issues ya refinados, uno por vez, hasta que cada uno queda terminado: escribe un plan de implementación, codifica contra ese plan, abre el PR, lo somete a nuestra propia revisión de código, corre el gate de calidad local, espera el deploy, mueve el issue a QA, y tilda del checklist solo lo que un test automatizado realmente probó. Todo lo que necesita un dispositivo real o un ojo humano se deja sin tildar, a propósito. Termina con un hand-off en lenguaje llano para QA: por cada issue, exactamente qué queda por verificar a mano.
Refinar
Convierte un issue crudo del backlog en criterios de aceptación, detalle técnico y checklist de QA — verificado contra el repo real, más un mapa de impacto cruzado para aprobación humana.
Planear
Escribe un plan de implementación para un issue ya refinado antes de que se escriba una línea de código.
Implementar
Codifica contra el plan aprobado y abre el pull request.
Revisar
Un agente de Opus de solo lectura caza en el PR bugs de correctness, seguridad y convenciones.
Verificar
Un agente de Opus separado vuelve a leer el código real para confirmar que cada hallazgo es cierto antes de arreglar nada.
Desplegar
Mergea, espera el deploy, mueve el issue a QA, y tilda solo lo que un test realmente probó.
Qué Modelo Hace Qué
Cada etapa del loop corre en un modelo específico de Claude Code, elegido por lo que esa etapa realmente demanda:
| Tarea | Modelo |
|---|---|
| Investigar / refinar issues | Sonnet |
| Plan de implementación | Opus |
| Escribir el código | Sonnet |
| Revisar el código (buscar bugs) | Opus, effort alto, solo lectura |
| Verificar cada hallazgo del review | Opus, un agente separado del anterior |
| Arreglar lo que el review encontró | Sonnet |
Investigar / refinar issues
Sonnet
Plan de implementación
Opus
Escribir el código
Sonnet
Revisar el código (buscar bugs)
Opus, effort alto, solo lectura
Verificar cada hallazgo del review
Opus, un agente separado del anterior
Arreglar lo que el review encontró
Sonnet
el trabajo de razonamiento profundo va a Opus, el volumen ya encauzado va a Sonnet
No es "un modelo para todo". El razonamiento profundo — planear, revisar — va a Opus. El trabajo de volumen que ya viene encauzado por un plan aprobado va a Sonnet.
La revisión usa a propósito dos llamadas de Opus independientes: una que caza defectos, y un agente separado que vuelve a leer el código real para confirmar que cada hallazgo es cierto antes de arreglar nada. Esa segunda pasada es lo que evita que gastemos un commit de fix arreglando un falso positivo.
Cazar
Un agente de Opus de solo lectura, con effort alto, caza en cada PR bugs de correctness, problemas de seguridad e integridad de datos, desvíos de convenciones y criterios de aceptación sin ningún test detrás.
Verificar
Un agente de Opus separado vuelve a leer el código real de cada hallazgo y confirma que es cierto antes de que pase a arreglo.
ningún commit de fix gastado en un falso positivo
Por Qué el Gate de Calidad Corre en tu Máquina, no en GitHub Actions
Empezamos como cualquiera: lint, typecheck, tests y build corrían en GitHub Actions en cada PR.
Terminamos moviendo todo a hooks locales — pre-commit, pre-push — más un comando único que corre las mismas verificaciones a mano. Correrlo en Actions quema minutos de CI, y es más lento: un runner en frío contra una máquina de desarrollo con el caché ya caliente. El agente que recién termina de implementar corre el gate ahí mismo, en segundos, sin esperar ninguna cola. GitHub Actions quedó reservado exclusivamente para lo único que de verdad no puede correr en una laptop: el deploy.
Eso no sale gratis. Depende de que los hooks estén instalados en cada checkout — es una decisión deliberada de mover dónde se paga la verificación, no una forma de evitar pagarla.
Cada agente que implementa corre exactamente esta secuencia antes de siquiera abrir un PR:
Un gate completo antes de cada push
Corre en la máquina del desarrollador, segundos después de terminar la implementación — sin cola.
Resultados
El proyecto que corrió este loop por más tiempo es Crashout, nuestro juego de carreras multijugador para eventos en vivo, con corte a agosto de 2026. Son números posteriores y más grandes que los publicados en el propio post de Crashout, que se escribió con un corte anterior:
499
commits desde el primer scaffold (28 de febrero de 2026)
160
issues → 160 PRs → 160 squash merges
23
días activos de merge (~7 merges por día activo)
51
merges entre las 00:00 y las 06:00
~46.000
líneas de código de aplicación + tests (Go + TS)
2.368
casos de test automatizados
Todo PR que se abrió se mergeó — cero abandonados. 71 de los 160 merges ocurrieron en los últimos 7 días, 65 en la semana pico. Los 2.368 tests se desglosan en 463 en Go, 1.656 en Vitest y 249 en Playwright sobre 50 specs E2E. El PR mediano son 456 líneas en 7 archivos.
Dos cosas vale la pena decirlas en el propio texto, no en letra chica. "Shipped" acá significa mergeado y desplegado a un ambiente de test, listo para que QA lo pruebe — no en producción.
Y son los números de un proyecto con un solo ingeniero humano coordinando el loop, no un promedio de toda la agencia.
Qué Cambia Para el Ingeniero
El loop no reemplaza al ingeniero — cambia qué hace. Cada vez menos escribir código línea por línea; cada vez más diseñar el loop en sí, calibrar qué cuenta como criterio de aceptación y decidir qué hallazgo de review realmente importa.
Recién estamos empezando a cerrar este loop todavía más. Si tenés curiosidad de cómo se vería un sistema así para tu equipo, hablemos.
