Loop engineering en Codex: cómo crear agentes que trabajan solos

Un loop en Codex es un sistema donde el agente arranca solo, trabaja solo, y para solo cuando el trabajo está terminado o algo necesita tu atención.

La diferencia con usarlo en modo chat es estructural:

• Modo chat: vos escribís, Codex responde, vos corregís. Vos sos el loop.
• Modo loop: una automatización dispara el trabajo, Codex ejecuta con su propio contexto, verifica contra criterios que definiste, y escala cuando encuentra algo que no puede resolver solo.

El loop tiene las mismas 6 piezas que cualquier sistema de agentes: trigger, ejecución, verificación, stop rules, memoria y skills. La diferencia es cómo se implementan en Codex.

1. Trigger — Automations

Codex tiene una pestaña de Automations donde definís qué dispara un trabajo. Las opciones más usadas:

• Cron: cada día a las 9, cada hora, cada lunes.
• Evento de GitHub: cuando se abre un issue, cuando un PR cambia de estado, cuando hay un merge.
• Manual: vos lo lanzás cuando querés, pero con un prompt completo y contexto de proyecto.

La clave: la automatización no es un prompt suelto. Es un trabajo con objetivo, contexto y criterios de éxito.

2. Ejecución — el agente trabaja

Cuando la automatización se dispara, Codex arranca un agente con acceso al repositorio. Ejecuta en un entorno controlado: puede leer archivos, escribir código, correr comandos, hacer commits y abrir PRs.

Lo importante: el agente trabaja con checkouts reales, no con respuestas teóricas. Si dice que los tests pasan, los tests realmente corrieron.

3. Verificación — quién controla

Acá está la diferencia entre un loop serio y un loop de juguete. Codex puede:

• Correr los tests del proyecto después de cada cambio.
• Ejecutar linters y validaciones.
• Revisar su propio diff antes de commitear.
• Escalar a un humano cuando algo falla o cuando el cambio es sensible.

La regla: sin verificación, no es un loop. Es un script con opiniones.

4. Stop rules — cuándo para

Un buen loop sabe cuándo terminar. Las reglas típicas:

• Todos los tests pasan.
• El objetivo de la automatización está cumplido.
• Se alcanzó un máximo de iteraciones.
• Algo bloqueante requiere decisión humana.

Si el loop no tiene stop rules claras, dos cosas: o nunca termina (quema tokens al pedo) o termina sin control de calidad (merges rotos).

5. Memoria — qué recuerda entre ciclos

Codex mantiene contexto entre ejecuciones si lo diseñás bien: archivos de estado, historial de decisiones, notas de lo que ya se probó. Sin memoria, cada corrida arranca de cero y repite los mismos errores.

6. Skills — conocimiento reutilizable

En lugar de repetir el contexto del proyecto en cada automatización, lo empaquetás en skills (SKILL.md): cómo se estructura el repo, qué convenciones seguís, qué no hay que tocar. La automatización invoca el skill y el agente ya sabe con qué se come.

Una de las piezas más potentes de loop engineering en Codex son los worktrees: ramas de trabajo aisladas donde cada agente corre sin pisarse con los demás.

En vez de un solo agente trabajando en la rama principal, podés tener:

• Un agente en el worktree A arreglando un bug.
• Otro en el worktree B implementando una feature.
• Otro en el worktree C actualizando dependencias.

Cada uno tiene su checkout, sus tests, su contexto. Cuando terminan, mergean sus cambios. Los conflictos se resuelven al mergear, no durante el trabajo.

Esto es lo que convierte a Codex de un asistente a una fábrica de cambios.

Armemos un ejemplo concreto: un loop de "dependencias seguras".

1. Trigger: cron semanal, lunes 9am.
2. Contexto: repositorio + skill con las convenciones del proyecto.
3. Objetivo: actualizar dependencias, correr tests, abrir PR si todo pasa.
4. Ejecución: el agente revisa dependencias desactualizadas, las actualiza de a una, corre los tests de cada una.
5. Verificación: si los tests fallan, revierte el cambio de esa dependencia y sigue con la siguiente. Si algo no se puede resolver, escala a un humano con un reporte.
6. Stop: cuando terminó con todas, o cuando encontró algo que requiere decisión.
7. Output: PR con cambios + resumen de qué se actualizó, qué se revirtió y por qué.

Ese loop corre todas las semanas sin que nadie lo toque. La única intervención humana es revisar el PR que abrió.

• Loop sin verificación: el agente commitea sin correr tests. Cagada asegurada.
• Loop sin stop rules: la automatización itera hasta agotar presupuesto.
• Worktree mal aislado: los agentes compiten por los mismos archivos y los merges son un infierno.
• Skills flojas: el contexto del proyecto va en el prompt de la automatización, que se repite y se desactualiza.
• Escalar a humano por cualquier cosa: si cada corrida te trae 5 preguntas, el loop no está bien diseñado. Las reglas de decisión autónoma tienen que cubrir el 90% de los casos.

Codex se destaca en tres cosas:

• Automatizaciones nativas con triggers de cron y GitHub, sin plugins externos.
• Worktrees como ciudadano de primera clase: el paralelismo es parte del diseño, no un add-on.
• Checkouts reales: el agente trabaja contra el repo de verdad, no contra una abstracción.

Claude Code tiene un ecosistema más maduro de skills y Hermes Agent es más avanzado en loops autónomos complejos, pero Codex es probablemente la puerta de entrada más directa: instalás el CLI, creás una automatización, y en 20 minutos tenés tu primer loop corriendo.

Loop engineering en Codex no es una feature que activás. Es un cambio de cómo pensás el trabajo: de "le pido a la IA que haga X" a "diseño un sistema que hace X solo, lo verifica y me avisa cuando importa".

El primer loop es incómodo porque confiás poco. El décimo ya no lo mirás, y ese es el punto.

Más sobre loop engineering:

• Loop Engineering con agentes de IA: guía práctica 2026Leer →
• Qué es loop engineering: guía completaLeer →
• WTF Is a Loop? Steinberger vs ChernyLeer →