ARTICULO
Loop engineering es el proceso de diseñar sistemas donde un agente de IA trabaja en ciclos repetitivos: ejecuta una tarea, verifica el resultado, corrige lo que falló y vuelve a ejecutar. El agente no espera instrucciones humanas en cada paso. Tiene un objetivo, reglas de detención y la capacidad de iterar hasta lograrlo.
Prompts largos y perfectos pierden valor. Lo que importa es la estructura del loop: qué dispara el trabajo, cómo se ejecuta, quién verifica, cuándo para.
El término explotó en 2026 con dos referencias centrales:
Addy Osmani (Google) publicó sobre loop engineering como el nuevo skill crítico para equipos de ingeniería: agentes que usan worktrees, skills y sub-agentes en ciclos de trabajo. Su framework nombra los componentes del loop y cómo encadenarlos.
Steinberger y Cherny popularizaron la idea de que "deberías estar diseñando loops que prompteen a tus agentes". La frase se volvió viral porque cambió el foco: no escribís mejores instrucciones, diseñás mejores sistemas de iteración.
Después vino el resto: la infraestructura que reemplaza al prompt engineering, los 15 loops que la gente ya está corriendo, los debates sobre si esto es una capa nueva o una evolución del harness de los agentes.
Cualquier loop de agente, por más complejo que sea, tiene estas piezas:
Si tu loop no tiene verifier, no es un loop: es un script que tira resultados sin control. Si no tiene stop rules, es un incendio de tokens.
El prompt engineering busca la instrucción perfecta. El loop engineering busca el sistema perfecto.
Con prompts, cada tarea nueva es un prompt nuevo. Con loops, diseñás una vez la arquitectura y el agente itera solo sobre los casos que van apareciendo.
Ejemplo concreto: mi sistema de contenido no le pide a la IA "escribí un artículo". Tiene un loop: detecta una idea nueva, arma el brief, genera el borrador, lo verifica contra las reglas de voz, corrige los problemas, y recién cuando pasa el control de calidad lo presenta para revisión humana. Cada etapa es un componente del loop. Ninguna depende de que yo escriba un prompt mejor.
Los loops más comunes que se están corriendo hoy:
Los que mejor funcionan comparten algo: el verifier es barato de correr, las stop rules son explícitas, y el loop puede correr sin supervisión durante horas sin quemar presupuesto al pedo.
Los loops no son una herramienta. Son un patrón. Los podés implementar en Claude Code con worktrees y sub-agentes, en Codex, en agentes tipo Hermes con skills, o con scripts que encadenan llamadas a APIs de modelos.
Lo que cambia según la plataforma es la infraestructura: cómo se guarda la memoria, cómo se invocan las skills, cómo se aisla el trabajo (worktrees, sandboxes, ramas). Pero la lógica del loop es la misma: disparar, ejecutar, verificar, corregir, parar.
Porque la capacidad de los modelos ya no es el cuello de botella. El cuello de botella es la orquestación: cuánto trabajo podés dejar correr solo, con qué calidad, y con cuánta supervisión mínima.
Los equipos que dominan loop engineering publican más, codean más y analizan más con la misma cantidad de gente. No porque la IA sea mágica: porque diseñaron sistemas que iteran solos y solo escalan cuando algo se rompe.
Loop engineering no es hype. Es la respuesta práctica a una pregunta incómoda: si los agentes ya saben hacer las cosas, ¿por qué seguís diciéndoles cómo hacerlas una por una?
La respuesta es que no deberías. Diseñás el loop, definís los controles, y dejás que el sistema trabaje. El prompt engineering te daba mejores instrucciones. El loop engineering te da mejores sistemas.
Y eso, a la larga, escala mucho mejor.
Preguntas Frecuentes
No exactamente. Un agente autónomo puede ser parte de un loop, pero el loop es la arquitectura completa: trigger, ejecución, verificación, memoria, skills y reglas de detención. El agente es el que ejecuta; el loop es el sistema que lo contiene.
Ayuda pero no es obligatorio. Muchas plataformas de agentes permiten configurar loops con interfaces visuales o archivos de configuración. Lo que sí necesitás es entender los componentes: qué dispara, qué verifica, cuándo para.
Lo complementa. Los prompts siguen existiendo, pero ahora son skills y componentes dentro del loop, no la pieza central. El diseño del sistema pesa más que la redacción de la instrucción.
Depende del loop. Con verifiers baratos y stop rules claras, un loop puede correr horas por centavos. Sin control, un loop descontrolado puede quemar presupuesto en minutos. El costo se diseña, igual que la calidad.
Con un loop chico: elegí una tarea repetitiva que hagas seguido, armá el ciclo trigger → ejecución → verificación → stop, y dejala correr. Después iterás: agregás memoria, skills, y recién ahí lo hacés más complejo.
