Ingeniería de loops: diseñar sistemas que hagan prompts a los agentes

• Dejar atrás la forma de hacer prompts directamente al agente de código en cada turno y pasar a una forma de trabajo en la que se diseña un sistema que hace prompts al agente
• Un loop es una meta recursiva en la que la IA repite hasta completar el objetivo una vez que este se define, y consta de unos cinco componentes
• Los cinco elementos son Automations, Worktrees, Skills, Plugins·connectors y Sub-agents, y tanto Claude Code como Codex ya cuentan con los cinco
• El sexto elemento, la memoria, es un archivo markdown o un tablero de Linear que guarda estado fuera de una sola conversación y compensa a los modelos que olvidan en cada ejecución
• Aún está en una etapa temprana y es indispensable tener cuidado con el costo de tokens; la verificación y la comprensión siguen siendo tarea humana (build the loop, stay the engineer)

---

Definición de la ingeniería de loops y por qué surge

• La ingeniería de loops consiste en reemplazar a uno mismo por un sistema en el rol de quien hace prompts al agente y diseñar directamente ese sistema que hace el trabajo
  • Un loop es una meta recursiva (recursive goal) donde, al definir un objetivo, la IA repite hasta completarlo
  • Puede ser la forma futura de trabajar con agentes de código, pero aún está en fase temprana y es indispensable prestar atención al costo de tokens (los patrones de uso cambian mucho según si se es token rich o token poor)
• Citas
  • Peter Steinberger: "Ya no le hagas prompts al agente de código; diseña el loop que le hace prompts al agente"
  • Boris Cherny (responsable de Claude Code en Anthropic): "Ahora ya no le hago prompts a Claude, sino que ejecuto un loop que le hace prompts a Claude y decide qué hacer. Mi trabajo es escribir el loop"
• Durante cerca de los últimos dos años, la forma de trabajo fue dar buenos prompts y suficiente contexto, intercambiar turno a turno y tener al agente directamente en la mano como herramienta, pero esa forma se está terminando
• Ahora se trata de crear un pequeño sistema que encuentre y distribuya trabajo, valide, registre lo completado y decida la siguiente tarea, para que ese sistema sea quien pinche al agente
  • Está por encima de artículos anteriores sobre agent harness engineering (el entorno donde corre un agente) y el factory model (el sistema que produce software)
  • Un harness que se ejecuta con temporizador, crea pequeños helpers y se alimenta a sí mismo
• Ya no es un problema de herramientas: hace un año, si querías loops, tenías que escribir y mantener por tu cuenta scripts bash improvisados, pero ahora los componentes ya vienen integrados dentro del producto
  • La lista de Steinberger coincide casi exactamente con la app de Codex y es casi idéntica en Claude Code, así que en vez de discutir qué herramienta usar, se trata de diseñar loops que funcionen en ambas

Los cinco componentes del loop y la memoria

• Un loop necesita cinco cosas, y además un lugar donde recordar el estado
  • Automations — se activan según una programación y hacen descubrimiento y triage por sí solas
  • Worktrees — evitan que dos agentes trabajando en paralelo choquen entre sí
  • Skills — registran conocimiento del proyecto que, de otro modo, el agente intentaría rellenar adivinando
  • Plugins·connectors — conectan al agente con las herramientas que ya usas
  • Sub-agents — uno propone ideas y otro las verifica
• El sexto elemento es la memoria, como archivos markdown o tableros de Linear, que vive fuera de una sola conversación y guarda lo completado y lo siguiente por hacer
  • Parece demasiado simple, pero es el mismo truco del que dependen todos los agentes de larga duración (artículo anterior sobre long-running agents)
  • El modelo olvida todo entre ejecuciones, así que la memoria no debe estar en el contexto sino en el disco; el agente puede olvidar, pero el repo no
• Ambos productos ya tienen hoy los cinco elementos; solo cambian un poco los nombres, no las capacidades

Automations: el latido del loop

• Automations es lo que convierte al loop en un loop real, y no en una sola ejecución
  • En la app de Codex se crea desde la pestaña Automations, eligiendo proyecto, prompt a ejecutar, frecuencia y si será un checkout local o un worktree en segundo plano
  • Las ejecuciones que encuentran algo van a la bandeja de entrada de Triage, y las que no encuentran nada se archivan solas
  • OpenAI lo usa internamente para tareas aburridas como triage diario de issues, resúmenes de fallas en CI, redacción de briefings de commits y caza de bugs agregados la semana pasada
  • La automatización puede invocar un skill, de modo que en vez de pegar una pared enorme de instrucciones se dispara $skill-name y el trabajo repetitivo sigue siendo mantenible
• Claude Code llega al mismo punto con scheduling y hooks
  • Con /loop ejecuta prompts o comandos a intervalos, permite programar tareas tipo cron y lanzar comandos de shell con hooks en puntos concretos del ciclo de vida del agente
  • Si se quiere que siga corriendo incluso después de cerrar la laptop, se puede mover todo a GitHub Actions
• Existe una segunda primitiva dentro de la sesión, muy cercana al núcleo de este artículo
  • /loop vuelve a ejecutar según el intervalo definido
  • /goal sigue hasta que una condición escrita por ti sea realmente verdadera, y después de cada turno un modelo pequeño aparte verifica si ya se cumplió, para que el agente que escribió el código no sea también el juez
    • Ejemplo: dejar condiciones como "todas las pruebas en test/auth pasan, lint clean" e irte de la silla
  • Codex también ofrece /goal, funcionando turno tras turno hasta que se cumpla una condición de parada verificable, con soporte para pause, resume y clear

Worktrees: que el paralelismo no se vuelva caos

• En el momento en que ejecutas más de un agente, los archivos empiezan a chocar; ahí es donde suele fallar todo
  • Que dos agentes escriban el mismo archivo da el mismo dolor de cabeza que dos ingenieros haciendo commit sobre la misma línea sin hablar entre sí
  • git worktree resuelve esto: comparte el historial del mismo repo, pero da a cada uno un directorio de trabajo separado sobre su propia rama, así que los cambios de un agente no pueden tocar el checkout del otro
• Codex trae soporte de worktree integrado, así varios hilos pueden tocar un mismo repo al mismo tiempo sin chocarse
• Claude Code ofrece el mismo aislamiento con git worktree, la bandera --worktree para abrir una sesión en su propio checkout y la configuración isolation: worktree en subagents (cada helper recibe un checkout nuevo que se limpia solo al terminar)
• Los worktrees eliminan los choques mecánicos, pero el cuello de botella sigues siendo tú: la cantidad real que puedes correr no la define la herramienta, sino tu ancho de banda para revisar (artículo anterior sobre the orchestration tax)

Skills: para no volver a explicar el proyecto cada vez

• Un skill es la forma de dejar de repetir en cada sesión el mismo contexto del proyecto como si el agente fuera un pez dorado
  • Ambas herramientas usan el mismo formato: una carpeta con SKILL.md que contiene instrucciones y metadatos, y opcionalmente scripts, referencias y assets
  • En Codex se invoca con $ o /skills, o se ejecuta solo si la tarea coincide con la descripción del skill, así que funcionan mejor las descripciones breves y aburridas que las muy ingeniosas
  • Claude Code funciona de la misma manera (artículo anterior sobre agent skills)
• El skill es donde la intención deja de convertirse en un costo repetido
  • El agente empieza cada sesión en frío y rellena los huecos de intención con conjeturas seguras de sí mismas (artículo anterior sobre the intent debt)
  • El skill externaliza esa intención: convenciones, pasos de build o cosas como "esto no se hace así por aquel incidente"; se escribe una vez y el agente lo lee en cada ejecución
  • Sin skills, el loop vuelve a deducir todo el proyecto desde cero en cada ciclo; con skills, se acumula y compone como interés compuesto
• El skill es un formato de autoría y el plugin es la forma de distribución: cuando se comparte entre varios repos o se empaqueta, se convierte en plugin (igual en Codex y Claude Code)

Plugins·connectors: para que el loop toque herramientas reales

• Un loop que solo puede ver el sistema de archivos es un loop pequeño
  • Un connector basado en MCP permite que el agente lea el issue tracker, consulte la base de datos, llame APIs de staging o envíe mensajes a Slack
  • Tanto Codex como Claude Code hablan MCP, así que un connector hecho para uno normalmente también funciona tal cual en el otro
  • Un plugin empaqueta connector y skill, para que un compañero lo instale de una vez en lugar de reconstruir todo de memoria
• Esa es la diferencia entre un agente que dice "aquí hay una propuesta de cambio" y un loop que abre el PR, vincula el ticket de Linear y manda un ping al canal cuando CI queda green
  • El connector es lo que hace que el loop no se limite a hablar de posibilidades, sino que actúe dentro del entorno real

Sub-agents: separar al que construye del que revisa

• En un loop, la estructura más útil con diferencia es separar al que escribe código del que lo revisa
  • El modelo que escribió el código suele ser demasiado indulgente al calificar su propia tarea
  • Un segundo agente, con instrucciones distintas y a veces incluso con otro modelo, detecta lo que el primero ya se había dado por satisfecho
• Codex crea subagents solo cuando se le solicita, los ejecuta en paralelo y combina los resultados en una sola respuesta
  • Las definiciones de agentes propios van en .codex/agents/ como archivos TOML (name, description, instructions, y opcionalmente model y reasoning effort)
  • Ejemplo: un revisor de seguridad puede usar un modelo fuerte con high effort, mientras que un explorer puede usar un modelo rápido de solo lectura
• Claude Code lo maneja de forma equivalente con subagents en .claude/agents/ y equipos de agentes que se pasan tareas entre sí
  • En ambas herramientas, el reparto habitual es un agente que explora, otro que implementa y otro que valida contra la especificación (artículos anteriores sobre the code agent orchestra y adversarial code review)
• Como el loop corre mientras no estás mirando, necesitas un verificador (verifier) confiable para poder levantarte de la silla
  • Los subagents ejecutan su propio trabajo de modelo y herramientas, así que consumen más tokens; conviene usarlos donde una segunda opinión realmente valga la pena
  • Eso mismo hace internamente /goal en Claude Code: un modelo nuevo decide si el trabajo ya terminó en lugar del que lo realizó, aplicando la separación maker/checker a la propia condición de parada

Cómo se ve un loop concreto

• Cuando se junta todo, un solo hilo se convierte en un pequeño panel de control; esta es una forma repetible de usarlo
  • Una automation corre cada mañana en el repo; su prompt invoca un skill de triage que lee las fallas de CI de ayer, los issues abiertos y los commits recientes, y registra el resultado en un archivo markdown o en un tablero de Linear
  • Por cada elemento que valga la pena, el hilo abre un worktree aislado y le encarga a un sub-agent un borrador del arreglo; luego un segundo sub-agent revisa ese borrador contra el skill del proyecto y las pruebas existentes
  • Un connector permite que el loop abra el PR y actualice el ticket; lo que el loop no pueda resolver entra en la bandeja de entrada de triage
  • Un archivo de estado (state file) es la columna vertebral de todo: recuerda qué se intentó, qué pasó y qué sigue abierto, para que la ejecución de la mañana siguiente continúe donde la de hoy se detuvo
• Lo clave es que ninguno de esos pasos se vuelve a promptear: se diseñó una sola vez; sea en Codex o en Claude Code, los componentes son los mismos y por eso el loop también

Lo que el loop todavía no reemplaza

• El loop cambia el trabajo, pero no borra a la persona; de hecho, cuanto mejor se vuelve el loop, más agudos se vuelven tres problemas
• La verificación sigue siendo tu tarea
  • Un loop que corre sin supervisión también es un loop que se equivoca sin supervisión
  • La razón de separar al sub-agent verificador del que construye es dar significado al "ya quedó" del loop, pero aun así "done" es una afirmación, no una prueba (artículo anterior sobre code review in the age of AI: el trabajo es enviar código cuyo funcionamiento fue confirmado)
• La comprensión se pudre si la dejas de lado
  • Cuanto más rápido despaches código que no escribiste tú mismo, más crece la brecha entre lo que existe y lo que realmente entiendes
  • Eso es la comprehension debt; un loop pulido agranda esa brecha todavía más rápido si no lees lo que el loop produjo
• La postura cómoda es la postura peligrosa
  • Si el loop corre solo, es fácil dejar de tener criterio y aceptar sin más lo que te devuelve (cognitive surrender)
  • Diseñar loops con criterio funciona como antídoto; diseñarlos para evitar pensar funciona como acelerador: la misma acción, resultados opuestos

Construye el loop, pero sigue siendo ingeniero

• Parece un adelanto de cómo evoluciona el trabajo, pero si se deja de revisar el código directamente o se depende solo de loops automáticos, la calidad del producto cae y se entra en una espiral descendente hacia un agujero cada vez más profundo
• Conviene configurar loops, pero seguir haciéndole prompts directamente al agente también sigue siendo efectivo; la clave está en encontrar el equilibrio adecuado
• Los loops pueden producir resultados opuestos según la persona: de dos personas que construyen el mismo loop, una puede usarlo para avanzar más rápido en algo que entiende a fondo, mientras la otra puede usarlo para no entender el trabajo
  • El loop no conoce esa diferencia, pero tú sí
• Esa es la razón por la que diseñar loops no es más fácil que la ingeniería de prompts, sino más difícil: el punto de Cherny no es que el trabajo se haya vuelto más simple, sino que el punto de apalancamiento se movió
• Conclusión: construye el loop, pero hazlo como alguien que va a seguir siendo ingeniero, no solo la persona que aprieta el botón de inicio

[shakespeares]

La verificación sigue siendo responsabilidad de uno mismo

La comprensión se pudre si se deja descuidada

Una postura cómoda es una postura peligrosa

=> Al final, hace falta crear prompts para verificar directamente por cuenta propia y minimizar el trabajo repetitivo.