Loop Engineering: el paso después del Prompt Engineering

Si trabajás todos los días con Claude Code, Codex, Cursor o Grok, seguramente reconocés este ciclo: escribís un prompt, esperás la respuesta, copiás el resultado, lo corregís a mano y volvés a prompt-ear. Funciona, pero tiene un techo claro: vos seguís siendo el cuello de botella. El agente no avanza si no estás ahí para empujarlo.

Ese techo es justamente lo que el loop engineering propone romper. No es una herramienta nueva ni un framework más: es un cambio de rol. En vez de ser la persona que prompt-ea al agente, pasás a ser la persona que diseña el sistema que prompt-ea al agente por vos.

Qué es loop engineering, en una frase

Un loop es un objetivo recursivo: definís un propósito y el agente itera —muchas veces con sub-agentes, verificación automática y estado externo— hasta que ese objetivo se cumple o el sistema decide escalar la decisión a un humano.

La diferencia con el prompt engineering tradicional es de fondo, no de forma. El prompt engineering optimiza la instrucción puntual: cómo redactar mejor un pedido para obtener una mejor respuesta. El loop engineering optimiza el sistema completo: cómo lograr que el agente trabaje, se autoverifique, se corrija y sepa cuándo pedir ayuda, sin que vos estés mirando cada paso.

Hay un repositorio de referencia que ordena bastante bien esta idea: loop-engineering, de Cobus Greyling, inspirado en publicaciones de Addy Osmani y en comentarios de Boris Cherny, responsable de Claude Code en Anthropic.

La frase que resume el cambio de mentalidad

El repo cita directamente a Boris Cherny describiendo cómo cambió su propio flujo de trabajo: ya no escribe prompts para Claude, tiene loops corriendo que prompt-ean a Claude y deciden qué hacer. Su trabajo pasó a ser escribir loops, no escribir prompts.

Esa frase es el resumen perfecto de hacia dónde va la programación asistida por IA: de sesión de chat a sistema operativo para equipos de software.

Los cinco bloques que componen un loop

El repositorio estructura cualquier loop alrededor de seis piezas. No son herramientas exóticas, son cosas que probablemente ya tenés disponibles en tu stack actual:

• Automatizaciones y scheduling: el disparador que activa la triage del loop con una cadencia definida (cada día, cada hora, en cada push).
• Worktrees: ejecución paralela segura, sin que un loop le pise el código a otro.
• Skills: el conocimiento persistente del proyecto, para que el agente no tenga que reaprender el contexto en cada corrida.
• Plugins y conectores (MCP): la forma en que el loop llega a tus herramientas reales —repos, tickets, CI, mensajería—.
• Sub-agentes: la separación entre el que hace (implementer) y el que revisa (verifier), para no confiar todo a un solo modelo.
• Memoria y estado: la columna vertebral que sobrevive entre conversaciones, normalmente un archivo como STATE.md que el loop lee y actualiza en cada ciclo.

Patrones de loop que ya están documentados

Lo interesante del repositorio no es solo el concepto, sino que viene con patrones concretos, cada uno con su cadencia recomendada y su costo en tokens:

• Daily Triage: reporte diario de lo que necesita atención, costo bajo, ideal para arrancar en modo «solo reporte».
• PR Babysitter: vigila pull requests cada 5-15 minutos, costo alto porque corre con frecuencia.
• CI Sweeper: detecta y corrige fallos de integración continua, el de costo más elevado del set.
• Dependency Sweeper: actualiza dependencias en modo «solo parches», costo medio.
• Changelog Drafter: redacta el changelog en cada tag o una vez al día, costo bajo.
• Post-Merge Cleanup: tareas de limpieza después de cada merge, pensado para correr en horarios de baja carga.

Cada patrón se puede arrancar con un starter clonable (hay versiones para Grok, Claude Code y Codex) y se audita con CLIs propias del repo: una para estimar costo en tokens, otra para medir si tu repositorio está listo para soportar un loop, y otra para scaffoldear el loop desde cero.

El rollout no es todo o nada: L1, L2, L3

Uno de los puntos más prácticos del repositorio es que no plantea pasar de cero a «agente autónomo» de un salto. Propone una progresión en tres niveles:

• L1 — Reporte: el loop observa y reporta, no toca nada. Es la fase de confianza.
• L2 — Asistido: el loop aplica correcciones acotadas, normalmente dentro de un allowlist explícito.
• L3 — Desatendido: el loop opera sin supervisión directa, con gates de verificación y reglas de escalamiento a humano ya probadas.

Esta progresión importa porque resuelve el miedo lógico que genera la idea de «agentes corriendo solos»: no se trata de soltar todo de golpe, sino de ganar evidencia de que el sistema se comporta bien antes de darle más autonomía.

Las advertencias que el propio repositorio hace

Lo que le da credibilidad a este enfoque es que no lo vende como solución mágica. El repositorio es explícito sobre los riesgos:

• Los costos en tokens pueden explotar con sub-agentes y loops de larga duración.
• La verificación sigue siendo tu responsabilidad. Un loop desatendido comete errores desatendidos.
• La deuda de comprensión crece más rápido si no leés lo que el loop va generando y mergeando.
• Dos personas pueden correr exactamente el mismo loop sobre el mismo repo y obtener resultados opuestos. El loop no sabe distinguir; vos sí.

Hay una cita de Addy Osmani en el repo que resume bien el espíritu correcto para encarar esto: construí el loop, pero construilo como alguien que tiene intención de seguir siendo el ingeniero a cargo, no solo la persona que aprieta «go».

Por qué esto importa más allá de un repo puntual

El cambio real que describe loop engineering no es técnico, es de diseño de trabajo. Durante los últimos dos años, la conversación sobre IA generativa en programación giró casi exclusivamente alrededor del prompt: cómo redactarlo, qué contexto darle, qué ejemplos incluir. Esa conversación sigue siendo válida, pero ya no es donde está el mayor apalancamiento.

El apalancamiento se mudó al sistema: a la capa que decide cuándo correr el agente, qué herramientas puede tocar, cómo verifica su propio trabajo y en qué momento exacto te devuelve el control. Esa capa es lo que separa «tengo un asistente de IA» de «tengo un equipo de software que opera solo mientras yo superviso lo importante».

Loop engineering no reemplaza al prompt engineering, lo sube de nivel. Seguís necesitando instrucciones claras —ahora dentro de skills, configuraciones de sub-agentes y reglas de verificación—, pero el foco pasa de «¿cómo le pido esto al agente?» a «¿qué sistema necesito para que el agente lo resuelva solo, de forma segura, y me avise cuando algo realmente requiera mi criterio?».

Si trabajás con agentes de código todos los días, vale la pena mirar el repositorio completo: tiene patrones listos para clonar, checklists de seguridad y, sobre todo, una forma honesta de hablar de los riesgos que todavía nadie resolvió del todo.