Loop Engineering: qué es y cómo funciona
Tabla de contenidos
En julio, en la conferencia de desarrolladores de Anthropic, Boris Cherny, creador de Claude Code, explicó que ya no escribe prompts para su propio producto: monta loops que se los escriben por él y deciden qué hacer a continuación.
Días después, Peter Steinberger, creador de OpenClaw, publicó su propia versión del mismo argumento. Y Addy Osmani, ex de Google, lo resumió así: dejas de ser tú quien instruye al agente turno a turno y pasas a diseñar el sistema que lo hace por ti.
Tres menciones casi simultáneas, y de repente «loop engineering» está en todas partes.
Pero si has leído nuestro artículo sobre Harness Engineering, ya conocías la idea.
El motivo por el que aparece justo ahora tiene que ver con los límites técnicos que hasta hace poco tenían los agentes: con ventanas de contexto de apenas 200.000 tokens, cualquier tarea ambiciosa había que trocearla en ejecuciones más pequeñas y encadenarlas.
El «loop» nació, literalmente, como una forma de sortear esa limitación; no como una idea nueva de gestión, sino como un parche de ingeniería que ha durado más de lo esperado.
¿Qué es Loop Engineering?
Loop Engineering es la técnica de diseñar un bucle que ejecuta un agente de IA repetidamente contra un objetivo, comprobando en cada vuelta si ese objetivo ya se cumplió, en vez de darle una instrucción cada vez de forma manual. El propio agente (o un bucle externo) decide si sigue trabajando o si el resultado ya es correcto.
De dónde viene el loop engineering: el Ralph Wiggum Loop
Hace justo un año, el ingeniero Geoffrey Huntley publicó la técnica que dio origen a todo esto. La llamó «Ralph», por el hijo del jefe de policía en Los Simpson: torpe, pero increíblemente insistente. En su versión más simple, es literalmente un bucle de bash: coge un archivo de prompt, se lo pasa al agente y en cuanto termina vuelve a empezar, sin parar hasta que el objetivo se cumple.
El patrón completo tiene cuatro pasos:
- arrancar con un objetivo claro y sus criterios de éxito,
- crear un plan de trabajo,
- ejecutar un elemento del plan por vuelta con una ventana de contexto limpia,
- y comprobar el resultado antes de seguir. Si hace falta, el propio bucle puede lanzar sub-agentes.
Diagrama original del proceso Ralph. Fuente Geoffrey Huntley
Huntley fue explícito sobre los límites de su propia técnica: sigue haciendo falta criterio de ingeniero senior para guiarla y cualquiera que diga que una herramienta puede hacer el 100% del trabajo sin supervisión no está siendo sincero sobre cómo funciona esto en la práctica.
De hack casero al comando/goal en loop engineering
Durante meses, montar un Ralph loop significaba construir tú mismo la infraestructura: el bucle, el seguimiento de estado, cuándo parar. Eso cambió en cuestión de semanas.
En abril, Codex lanzó el comando/goal: en vez de decirle al agente qué hacer, le defines qué condición tiene que cumplirse antes de devolver el control.
Un par de semanas después, tanto Hermes como Claude Code lanzaron su propia versión del mismo comando, con la misma lógica de fondo: mantener el objetivo activo entre turnos hasta que se cumpla, sin que tengas que reescribir el prompt en cada vuelta.
Lo que antes exigía montar tu propia infraestructura, hoy es un solo comando en cualquiera de los harnesses principales.
Fuente: Open AI
Casos reales de Loop Engineering
Más allá de los anuncios, ¿para qué los usan los developers en el día a día? La respuesta: triggers y cron jobs, según el análisis que recogió Gergely Orosz (The Pragmatic Engineer) al preguntarlo directamente.
Algunos ejemplos concretos:
- Un ingeniero dejó un flujo donde, cada vez que se registra un error en Sentry, un agente revisa si ya hay un PR abierto para ese problema y, si no, lo crea.
- En PostHog, un developer dejó un loop revisando tests inestables uno a uno hasta encontrar la causa y proponer un arreglo. Consiguió 13 PRs de estabilización de una sola vez.
- En Incident.io usan loops para construir integraciones de telemetría: ejecutar la consulta, comprobar que el resultado es correcto, y repetir hasta que lo sea.
- En Elastic, otro equipo deja que el agente revise planes de diseño en bucle hasta que una vuelta completa no encuentra ya ningún problema nuevo.
- También hay quien lo usa para trabajo nocturno: revisar los tests end-to-end que fallan cada noche, decidir si es un fallo real o un falso negativo y dejar el PR listo para revisar por la mañana.
- Un caso distinto: un fundador de startup migró toda su aplicación de React a React Native con Expo sin crear un épico de 50-100 tickets. En su lugar, dejó una skill que detectaba qué parte del código convertir a continuación, aplicaba el cambio y actualizaba el progreso , montada sobre un cron que corría cada 30 minutos. Según él mismo contó, gestionar así la migración le resultó mucho más manejable mentalmente que llevar un plan gigante con dependencias cruzadas.
El matiz que conecta el loop con el harness
No todos los developers que probaron esto se quedaron satisfechos. Algunos abandonaron los loops al ver que el agente se desviaba del objetivo con cada vuelta, o que mantener a un humano revisando cada paso daba mejores resultados que dejar el bucle correr solo.
En empresas que pagan precio de API por token, además, un loop mal acotado se encarece rápido, hay quien ya lo describe como «tokenmaxxing»: el bucle sigue dando vueltas, consumiendo tokens, mucho después de que dejara de aportar valor real.
Hay incluso quien sostiene que el propio concepto de «loop» fue, en realidad, un parche temporal mientras las herramientas se ponían al día, y una vez que /goal llegó a todos los arneses principales, gran parte de la necesidad de construir tu propio bucle desapareció de un plumazo.
La velocidad no es solo de los labs: en cuestión de semanas ya han aparecido paquetes de código abierto dedicados en exclusiva a esto, con bastante tracción en GitHub. Su propia documentación de seguridad ya advierte de riesgos muy concretos: fuga de secretos a través de prompts, bucles de arreglo infinitos que agotan el presupuesto, PRs de la cadena de suministro sin revisar. Si hasta la herramienta construida para esto necesita avisar de sus propios riesgos, la cautela no es exagerada.
Un director de ingeniería lo resumió con una idea que vale la pena considerar: si un flujo de trabajo es automatizable o se vuelve una tarea táctica porque la IA ya la resuelve sola, o es simplemente la automatización de toda la vida, un cron, un trigger, con un nombre nuevo.
Esa es, en el fondo, la relación con lo que ya llamamos Harness Engineering: un loop no es una capa nueva por encima del harness, es una de las técnicas que ya vive dentro de él, el mismo tipo de mecanismo de feedback que describimos como «sensores». Diseñar bien el loop es diseñar bien una parte del arnés, no practicar una disciplina aparte.
Cuándo usar Loop Engineering (y cuándo no)
Los loops rinden mejor en tareas acotadas, repetibles y con un criterio de éxito verificable: arreglar un test que falla, triar un error conocido, ejecutar trabajo nocturno con un formato de salida claro. Pierden fuerza en tareas abiertas o que exigen criterio humano en cada paso, donde el coste de dejarlo correr sin supervisión supera el tiempo que ahorra.
Para la mayoría de developers que no están construyendo infraestructura de IA, la habilidad que más rédito da probablemente no es diseñar loops sofisticados, sino dominar bien el contexto que ese loop necesita en cada vuelta, de eso hablamos en nuestro artículo sobre Context Engineering.
Loop Engineering no es una skill nueva que añadir a tu perfil ni un rol distinto que perseguir. Es una técnica más dentro de lo que ya construyes como Agentic Engineer o Harness Engineer: una forma concreta de diseñar el mecanismo de feedback que decide cuándo un agente ha terminado. Practicar Loop Engineering es afinar una pieza más de tu arnés, no aprender una disciplina desde cero.
En el Máster AI4Devs trabajamos estas técnicas aplicadas a proyectos reales, dentro del marco completo de Harness Engineering, no como conceptos sueltos que cambian de nombre cada mes.