Qué es Loop Engineering: ejemplo práctico con Codex

Se está empezando a hablar bastante de Loop Engineering. Como pasa siempre que aparece una etiqueta nueva, hay una parte de hype y otra parte que sí me parece interesante: cuando algo recibe nombre, podemos discutirlo mejor.

Para mí, el Loop Engineering no va de dejar a la IA programando sola en plan “a ver qué pasa”. Eso al final no funciona y solo te hace perder el tiempo. Lo útil de esto es cómo diseñas el flujo completo de trabajo: cómo le pasas la información al agente, dónde toca código, cómo valida que no ha roto nada, y sobre todo, cuándo te pide ayuda y cuándo debes intervenir tú.

En este artículo vamos a montar la idea con Codex, hilos especializados, Git Worktrees, Pull Requests y revisores automáticos. No como una demo de “mira qué listo es el modelo”, sino como una arquitectura mínima que puedes replicar en un repositorio real.

Qué es realmente un loop

Cuando empezamos a programar con IA, lo normal es hacerlo de forma muy directa: abrimos el chat, pedimos una función, copiamos, pegamos, probamos y corregimos si falla. Eso ya es un bucle, pero es manual. Depende al 100% de que estés encima del chat guiando al modelo en cada paso.

Para montar un ciclo automático de verdad, necesitas estructurarlo un poco:

• Una fuente de estado: un backlog, una issue, una especificación en markdown… algo donde el agente pueda leer qué tiene que hacer.
• Un entorno aislado: para que pueda probar y hacer cambios sin pisar el trabajo de otros agentes (o el tuyo).
• Fase de verificación: tests, linter, compilación, typecheck… señales automáticas y objetivas de si el código funciona.
• Mecanismo de feedback: una forma de decirle al agente qué ha fallado para que intente corregirlo solo.
• Puntos de control humano: decidir cuándo entra el cambio a producción y cuándo el agente se para y te pide ayuda.

Con esto, la clave no es que el LLM sea mágicamente más inteligente de un día para otro. Lo importante es que dejas de centrarte tanto en escribir el prompt perfecto y pasas a diseñar el ciclo completo de trabajo.

La arquitectura mínima

Antes de ponerte a lanzar agentes en paralelo, tienes que definir muy bien qué piezas hay y qué hace cada una. Si no, vas a acabar con un montón de chats tocando el mismo repositorio a la vez, pisándose los unos a los otros, duplicando tareas y perdiendo el control del estado del proyecto.

Una arquitectura mínima y funcional se puede estructurar con cuatro partes:

• Un archivo de estado: por ejemplo, un features.md o un feature_list.json que sirva como única fuente de verdad con las tareas, sus estados y sus dependencias.
• Un hilo Manager: el cerebro que lee ese archivo y decide qué tareas se pueden poner en marcha.
• Hilos Worker: los agentes que implementan cada tarea concreta.
• Un hilo PR Reviewer: especializado en revisar las Pull Requests y dar feedback.

El archivo de estado no tiene que ser nada del otro mundo. Solo hace falta que el Manager pueda leerlo para saber qué hay pendiente, qué está bloqueado por dependencias y qué tareas han terminado bien. Con un JSON sencillo en el propio repositorio ya tenemos de sobra:

[
  {
    "id": "feature-auth",
    "title": "Añadir login con email",
    "status": "pending",
    "depends_on": [],
    "evidence": []
  }
]

No te hace falta montar una base de datos, colas de tareas ni herramientas raras para empezar. Con un simple archivo versionado en el propio repositorio es más que suficiente para probar que el flujo funciona.

La idea: un manager y varios workers

En Codex podemos crear hilos independientes con su propio contexto, lo que permite algo muy interesante: separar el trabajo por roles.

El hilo principal hace de Manager. Su rol no es tirar código, sino mirar las tareas pendientes, decidir el orden, gestionar las dependencias y coordinar a otros hilos.

Por otro lado tenemos a los workers, que son los que se ensucian las manos. Reciben una tarea muy acotada, la implementan en su espacio de trabajo, validan que todo compile y, al terminar, abren una Pull Request.

Parece una tontería, pero cambia por completo cómo funciona el sistema. Si le pides a un solo hilo que entienda todo el proyecto, escriba el código, lo pruebe, lo revise y gestione los fallos, su ventana de contexto se convierte en una sopa. Separando los roles, cada hilo se enfoca en una sola cosa.

El Manager controla el panorama general, los workers hacen la tarea asignada, y podemos tener un tercer hilo que solo se dedique a revisar el código resultante.

Por ejemplo, en lugar de pedirle al Manager un “impleméntame la app entera”, es mucho mejor darle un prompt centrado en la coordinación:

Eres el Manager de este repositorio. Tu trabajo es leer feature_list.json,
detectar qué tareas están pendientes y sin dependencias bloqueantes, y lanzar
un hilo worker por cada tarea ejecutable.

Cada worker debe usar la skill feature-flow, trabajar en un Git Worktree
aparte y crear una Pull Request cuando termine.

No implementes features directamente. Mantén el estado del proyecto, coordina
workers, revisa dependencias y pide intervención humana si hay un conflicto que
no puedas resolver con seguridad.

Este punto es vital: el Manager no debe ponerse a escribir código. En el momento en que se ensucia las manos con la implementación, pierde la perspectiva y la limpieza de contexto necesaria para gestionar el sistema.

Por qué los Git Worktrees son la pieza clave

El primer dolor de cabeza cuando quieres paralelizar tareas es el espacio de trabajo. Si pones a tres agentes a tocar archivos en la misma carpeta local, se van a pisar seguro. Uno modifica un componente, otro cambia el mismo archivo, las dependencias se rompen y terminas con un caos imposible de arreglar.

Aquí es donde Git Worktrees te salva la vida.

Un worktree te permite tener varias ramas del mismo repositorio abiertas en carpetas físicas distintas a la vez. Comparten el historial de Git, pero cada una funciona de forma independiente. Para trabajar con agentes, esto es oro.

Con esto, cada worker tiene su propia carpeta aislada:

• El worker de la tarea A hace cambios en su rama sin molestar a nadie.
• El de la tarea B trabaja en otro directorio paralelo.
• Ambos pueden instalar dependencias, compilar y pasar tests de forma independiente.
• Cuando terminan, cada uno abre su Pull Request.

Esto no te libra de los conflictos si ambos tocan la misma línea de código, lógicamente. Pero traslada el problema del desorden local a un flujo de desarrollo normal de toda la vida: ramas, PRs y merges.

Lo bueno de usar Codex es que no te hace falta crear los worktrees a mano ejecutando comandos en tu terminal. Le puedes pedir directamente al Manager que asocie cada hilo de un worker a su propio worktree. La herramienta se encarga de aislar la carpeta y tú solo tienes que pasarle unas instrucciones claras al worker:

Lanza un nuevo hilo en un Git Worktree para la tarea feature-auth.
Ese hilo debe implementar solo esta tarea y trabajar de forma aislada.
Ejecuta tests, lint y build antes de terminar.
Cuando esté validado, crea una Pull Request y deja el enlace en feature_list.json.

Haciéndolo así, te quitas de encima el lío de andar gestionando ramas y directorios locales a mano, y reduces a cero la posibilidad de que dos agentes se pisen el trabajo local. Si surge algún conflicto, lo gestionarás donde se debe: en GitHub o al integrar contra main.

El revisor automático como loop dentro del loop

La siguiente pieza es el PR Reviewer, un hilo especializado únicamente en revisar las Pull Requests abiertas.

Funciona en segundo plano: cada pocos minutos mira si hay PRs nuevas, descarga el diff, analiza el código y deja comentarios. Si ve fallos, te lo dice en la propia PR. Si todo está correcto, da luz verde para que el Manager sepa que se puede integrar.

Así, la revisión se convierte en un bucle cerrado:

1. El worker hace el trabajo.
2. Abre la PR.
3. El reviewer analiza los cambios.
4. Si hay comentarios, el Manager le vuelve a asignar la tarea al worker con ese feedback.
5. El worker corrige y actualiza la PR.
6. El reviewer vuelve a comprobarlo.

Aquí no hay ninguna magia rara. Son solo estados, señales claras y responsabilidades separadas. Esa es la verdadera diferencia entre dejar a un agente suelto haciendo cosas y tener un sistema fiable en el que puedes confiar.

Para implementarlo en Codex, lo más sencillo es levantar un hilo independiente y meterle un heartbeat. No necesitas crear un chat para cada Pull Request; como el heartbeat corre en el mismo hilo, el PR Reviewer mantiene la memoria de lo que ya ha revisado y no repite trabajo.

Un prompt muy directo para arrancar sería este:

Crea un heartbeat para que, cada cinco minutos, compruebes si hay algún
Pull Request abierto en este repositorio.

Si lo hay, revísalo. Si ves puntos que mejorar, déjalos como comentario en
la PR. Si no ve nada relevante, comenta exactamente: "listo para integrar".

A partir de aquí, lo puedes complicar todo lo que necesites: que levante la rama en otro worktree para compilarla, que pase la suite de tests, que busque patrones concretos de arquitectura… pero la base es siempre la misma: un hilo persistente comprobando el código en segundo plano.

Lo único imprescindible es que use etiquetas claras en sus comentarios, como:

• necesita cambios: para devolver la tarea al worker.
• bloqueado: si falta información o hace falta que entre una persona.
• listo para integrar: luz verde para el merge.

El reviewer no tiene que hacer merges ni tomar decisiones de negocio; su única misión es dar un feedback objetivo y estructurado que el Manager pueda interpretar.

El caso difícil: conflictos y dependencias

La cosa se pone interesante cuando entran en juego las dependencias del mundo real.

Imagina que el Manager lanza tres hilos de trabajo a la vez:

• El worker 1 termina su feature, abre PR y el PR Reviewer la marca como listo para integrar.
• El worker 2 también abre PR, pero se basaba en un estado anterior de main.
• La tarea 3 depende de que la tarea 2 esté integrada, así que todavía no debería arrancar.

Aquí es donde los típicos sistemas automáticos de juguete fallan. Escribir código en un entorno ideal es sencillo; lo complicado es reaccionar cuando el estado del repositorio cambia a mitad de camino.

En la demo que grabé pasa exactamente eso. Lanzamos varias PRs a la vez, el reviewer deja notas, los workers las corrigen y, en cuanto fusionamos la primera en main, las otras se quedan desactualizadas y con conflictos. Es el Manager el que tiene que mover ficha.

Un Manager bien diseñado tiene que ocuparse de:

• Detectar que hay una PR aprobada y hacer el merge (si lo tenemos automatizado).
• Ver qué PRs se han roto por culpa del merge anterior.
• Pasar el feedback al hilo del worker correspondiente (no a un chat nuevo, sino al que ya conoce la tarea).
• Esperar a que el worker actualice su rama local contra main y resuelva el conflicto.
• Lanzar la tarea 3 en cuanto vea que su dependencia (la tarea 2) se ha integrado.

Al igual que con el reviewer, el Manager necesita su propio heartbeat en segundo plano. En el vídeo lo organizo en dos fases.

La primera fase se encarga de conectar al reviewer con los workers. Como el Manager sabe qué hilo lleva cada tarea, puede cerrar el circuito:

Cada 10 minutos, revisa si hay comentarios nuevos del PR Reviewer en las
Pull Requests abiertas.

Si hay comentarios con cambios pedidos, envía esa información al hilo worker
correspondiente para que actualice su worktree y vuelva a subir la PR.

La segunda fase, opcional si quieres el flujo 100% automático, gestiona los merges:

Si una Pull Request está marcada como "listo para integrar", integra ese cambio
en main, cierra el hilo correspondiente, elimina el worktree y deja trazabilidad
de lo que has hecho.

En producción yo no automatizaría este merge directo a main sin que un humano le eche un ojo, pero para trastear y probar la arquitectura es divertidísimo ver cómo se gestiona todo solo.

Con esa información, el Manager puede actualizar feature_list.json:

• Si una PR tiene listo para integrar, la marca como ready.
• Si tiene necesita cambios, manda el feedback al hilo worker que creó esa PR.
• Si al integrar una PR aparece un conflicto, avisa al mismo worker para que actualice su worktree contra main.
• Si una tarea dependía de otra que ya está integrada, lanza un nuevo hilo en un worktree para continuar.

El flujo completo y ordenado queda así:

1. El Manager comprueba el archivo de tareas.
2. Lanza trabajadores solo para las tareas libres de dependencias.
3. Cada worker abre su PR desde su propia carpeta aislada.
4. El reviewer comprueba la PR y deja su veredicto.
5. El Manager reacciona a la etiqueta del comentario.
6. Si hay fallos, el worker corrige. Si está ok, se hace el merge.
7. Al integrarse la tarea, se desbloquean las que dependían de ella y el bucle vuelve a empezar.

Dónde entra la persona

La tentación con estas herramientas es intentar automatizarlo todo al 100%: que el agente escriba, revise, fusione y despliegue a producción sin que nadie lo mire. Aunque técnicamente se puede hacer, en la práctica suele ser mala idea.

El papel de las personas sigue siendo clave en las decisiones importantes, como:

• Elegir el enfoque de la solución o la arquitectura.
• Dar el visto bueno final a la PR antes de que entre en la rama principal.
• Decidir si un error detectado es crítico o podemos seguir adelante.
• Validar que el comportamiento de la feature tiene sentido para el usuario, más allá de que pasen los tests.

En lugar de intentar apartar al desarrollador para que no haga nada, lo inteligente es liberarlo de las tareas más repetitivas y aburridas (como formatear código, pasar tests a mano, resolver conflictos tontos o actualizar ramas) para que pueda centrarse en el diseño y en aportar su criterio.

Los límites siguen estando ahí

Esto tampoco hace milagros. Los agentes siguen teniendo los mismos límites de siempre, solo que ahora trabajan en un entorno más ordenado.

Si no tienes cuidado, te vas a encontrar con problemas de cajón:

• Si defines mal la tarea, el agente programará perfectamente algo que no sirve de nada.
• Si tus tests son flojos, dará por buena una solución que tiene fallos.
• Si organizas mal el backlog, el Manager intentará paralelizar cosas que en realidad dependen unas de otras.
• Si no mides lo que pasa por detrás, puedes acabar con agentes dando vueltas y consumiendo tokens sin avanzar.
• Si no separas bien los contextos de cada hilo, la ventana de contexto se llenará de ruido enseguida.

Por eso me gusta enfocar esto desde el punto de vista del flujo de trabajo y no de la “autonomía de los agentes”. La autonomía total suena muy bien en una demo de Twitter/X, pero en el día a día suele ser bastante frágil.

Un checklist mínimo para montar tu propio loop

Si quieres probar a montar algo por tu cuenta, te sugiero empezar con pasos pequeños:

1. Define un archivo o issue tracker simple como fuente de tareas.
2. Reparte los roles en hilos de Codex: un Manager y los Workers que hagan falta.
3. Dile a Codex que levante un Git Worktree para cada Worker independiente.
4. Fuerza a que toda entrega sea a través de Pull Request (nada de commits directos a main).
5. Levanta un hilo PR Reviewer en bucle (heartbeat) para comentar las PRs abiertas con etiquetas estándar.
6. Añade otro heartbeat al Manager para enlazar los comentarios del reviewer con el worker adecuado.
7. Usa estados lógicos en tu JSON/Markdown (pending, in_progress, review, blocked, done).
8. Apóyate en scripts automáticos en local para validar (tests, linter, compilación) antes de dar por buena una tarea.
9. Decide qué acciones críticas requieren sí o sí que tú estés en el loop.

Con este esqueleto mínimo ya pasas de tener un chat con IA a tener un flujo de trabajo real. Un sistema que avanza, encuentra problemas, aprende del feedback y se autocorrige.

La clave no es la autonomía, es el control

Al final, la conclusión es bastante sencilla: programar con IA no va de dar con el prompt mágico. Va de diseñar un buen sistema alrededor de la herramienta.

Cualquier modelo actual te puede generar código funcional. La diferencia real está en cómo organizas ese trabajo: cómo aíslas los entornos, cómo gestionas las revisiones, las dependencias y los límites de seguridad.

Por eso me parece útil hablar de Loop Engineering. No porque sea un concepto revolucionario inventado ayer, sino porque nos ayuda a centrarnos en lo que de verdad importa: cómo llevar una tarea desde la idea inicial hasta que está integrada en producción de forma segura y fiable.

Y en esta forma de trabajar, todavía queda mucho camino por recorrer.