Loop engineering: el bucle es el producto, no el código

Durante años mi trabajo fue escribir el código. Ahora describo un objetivo, y un agente lo escribe, ejecuta los tests, lee el error y lo vuelve a intentar. El trabajo de verdad se ha movido un nivel hacia arriba: ya no escribo el código, diseño el bucle en el que el agente lo escribe. A eso lo llamo loop engineering. Y la idea que ordena todo lo demás es incómodamente simple: el bucle es el producto, no el código.

Si ya has montado un agente con Claude Code o con tu propio orquestador, esto te sonará. Funciona, pero iteras a ojo. Ajustas un prompt, lanzas, miras si el resultado parece mejor, repites. El salto de calidad casi nunca viene de un prompt más listo. Viene de diseñar mejor el bucle.

¿Qué es “el bucle”, exactamente?

El bucle es el ciclo que un agente repite hasta terminar una tarea: recibe contexto, decide una acción, observa el resultado, lo compara contra lo que buscabas y decide si vuelve a intentarlo o para. Es el clásico percepción-decisión-acción de los agentes, con un añadido que casi todo el mundo se salta: la comparación explícita contra un objetivo.

Cinco piezas componen una vuelta.

El contexto es todo lo que el modelo puede ver en ese momento: el objetivo, el estado del código, el error de la última vuelta, las herramientas disponibles. Lo que no está en el contexto, para el agente no existe, así que gestionarlo bien es media batalla. Si nunca has pensado el contexto como un recurso escaso, empieza por las buenas prácticas con la ventana de contexto.

La acción es la herramienta que el modelo elige y ejecuta: escribir un archivo, correr un test, consultar la base de datos. Eso es tool calling.

La observación es el resultado que el sistema devuelve al contexto después de ejecutar la acción. Un detalle que importa: el modelo lee la observación, no la inventa. La produce el mundo real (el test runner, el compilador, la API), y por eso la observación es la única parte de la vuelta que el agente no puede fabricar.

El feedback es la señal que dice si esta vuelta va mejor o peor que la anterior. Observar no es lo mismo que saber si progresas. Un test que falla es una observación; que ese fallo sea uno menos que la vuelta anterior es feedback.

La condición de parada decide cuándo el bucle se detiene: objetivo cumplido, presupuesto agotado o falta de progreso.

Si quieres la definición desmenuzada, la tienes en qué es exactamente un bucle agéntico y en el ciclo de un agente de IA explicado paso a paso. Aquí me interesa lo que pasa cuando escalas esa vuelta simple: ¿este bucle vive dentro de una tarea o gobierna todo el sistema?

Inner loop y outer loop: dos bucles, dos trabajos

En un sistema agéntico hay dos bucles operando a la vez, y confundirlos es la primera fuente de diseño malo. El inner loop es el ciclo corto dentro de una tarea. El agente genera un fragmento de código, corre el test, ve que falla y se corrige, todo en la misma sesión de razonamiento. Es el probar-corregir que Claude Code ejecuta en cada turno sin que tú hagas nada.

El outer loop es el ciclo largo. Es el sistema que lanza ese inner loop una y otra vez: le da trabajo, revisa el resultado, decide lo siguiente y vuelve a empezar, sin que teclees cada prompt. Aquí vive la mejora entre ejecuciones, la parte que convierte un agente que resuelve una tarea en un agente que resuelve tareas cada vez mejor.

La distinción no es académica, cambia dónde optimizas. Mejorar el inner loop es dar feedback más rápido y legible dentro de la sesión: tests que corren en segundos, errores que el modelo entienda. Mejorar el outer loop es orquestación, presupuesto y memoria entre ejecuciones. Y hay una regla que se aprende a base de tropiezos: cuando el inner loop se atasca, el outer loop debe replantear la estrategia entera, no repetir el mismo paso esperando otro resultado. Los feedback loops en agentes de IA merecen su propio artículo, porque son el mecanismo que conecta los dos.

Los dos bucles comparten un requisito. Sin una buena señal de feedback, ninguno converge. Da igual lo elegante que sea tu orquestación.

Qué hace que un bucle converja

Un bucle converge cuando cada vuelta lo acerca al objetivo, y eso solo pasa si tiene una señal de feedback que discrimina entre mejor y peor. Hay dos maneras de conseguir esa señal, y elegir bien entre ellas es buena parte del diseño.

La primera es el feedback determinista: tests, linters, type-checkers, gates. Pasa o no pasa. Es barato, inequívoco y no se puede discutir con él. Un test rojo es un test rojo, y el agente no lo puede negociar. Cuando el problema se puede reducir a una regla comprobable, esta es siempre la mejor señal. Los hooks de Claude Code para calidad determinista son exactamente esto: paredes que el bucle no puede saltar. Y si el agente escribe código, la estrategia de tests cuando la IA programa rápido es lo que le da al bucle una señal fiable.

La segunda es el juicio de un modelo: un LLM evalúa lo que otro produce. Sirve para lo que ningún test captura, como “¿esta respuesta es clara?” o “¿este texto suena natural?”. Es más caro y más ruidoso, pero cubre el territorio que la verificación determinista no alcanza. El patrón está en un modelo como juez.

Dimensión	Feedback determinista	Juicio de un modelo
Qué mide	Lo que se puede reducir a una regla: compila, pasa el test, cumple el tipo	Lo cualitativo: claridad, tono, si la solución tiene sentido
Coste por vuelta	Bajo	Alto: es otra llamada al modelo
Fiabilidad	Alta y repetible	Variable, hay que calibrarlo para que no puntúe todo igual
Cuándo usarlo	Siempre que el problema lo permita	Solo para lo que no se puede reducir a una regla

La regla práctica es preferir lo determinista siempre que puedas y reservar el juicio para lo que de verdad no se puede convertir en una regla. Un bucle con feedback ambiguo no converge: da vueltas porque la señal no le dice hacia dónde ir. Diseñar esa señal es un tema tan grande que le dedico cómo evaluar agentes de IA en producción entero.

Una señal fiable te dice hacia dónde ir. No te dice cuándo parar. Y ese es un problema distinto.

Por qué un bucle no termina

Un bucle sin condición de parada explícita no termina: se queda repitiendo el mismo estado o consume presupuesto hasta que alguien lo mata. La autonomía sin freno no es autonomía, es una fuga.

Cada bucle necesita un presupuesto (un máximo de vueltas o de tokens) y una definición de “hecho” que el propio bucle pueda comprobar. Pero el fallo más traicionero es otro: la falta de detección de no-progreso. Si dos vueltas seguidas producen el mismo diff o el mismo error, el agente no está avanzando, está atascado. Reintentar lo mismo esperando un resultado distinto no es iterar. Cuando eso pasa, lo correcto es replantear o escalar, no dar otra vuelta idéntica. El caso extremo, un agente atascado en bucle infinito, casi siempre es esto sin freno.

// El bucle para por objetivo cumplido, presupuesto agotado o falta de progreso
async function runLoop(agente: Agent, objetivo: Objetivo, budget: Budget) {
  let estado = estadoInicial(objetivo);
  for (let vuelta = 0; vuelta < budget.maxVueltas; vuelta++) {
    const accion = await agente.decidir(estado);
    const observacion = await ejecutar(accion);
    const señal = await verificar(observacion, objetivo); // tests, lint o juez
    if (señal.cumplido) return observacion;
    if (sinProgreso(estado, observacion)) break; // mismo diff/error: atascado
    estado = actualizar(estado, observacion, señal.feedback);
  }
  return escalarAHumano(estado); // el bucle no decide solo cuándo rendirse
}

Las paredes que impiden que un bucle se descontrole tienen su propio nombre y su propio diseño: los guardarraíles para agentes de IA. Poner un tope es la parte fácil. Lo difícil es que cada vuelta cuesta, y decidir cuántas vueltas merecen la pena es parte del diseño.

El coste de cada vuelta

Cada vuelta del bucle cuesta tokens, latencia, dinero y el riesgo de romper algo que ya funcionaba, así que diseñar el bucle es también decidir cuántas vueltas valen la pena. Un bucle que itera veinte veces para arreglar un typo es peor que uno que para en tres y te lo pasa a ti. Más vueltas no significan mejor resultado. Pasado cierto punto, un bucle sin señal nueva solo quema presupuesto.

El compromiso aparece en cada decisión. Un feedback más rico por vuelta, como correr la suite entera, cuesta más por vuelta pero suele converger en menos vueltas. Un feedback barato, como pasar solo el linter, es rápido pero puede necesitar muchas más. Y hay un coste que crece solo: el contexto se acumula con cada vuelta, más historia es más tokens por llamada, y a partir de cierto tamaño el modelo empieza a perder el hilo de lo que le pediste.

El presupuesto de vueltas es una decisión de negocio disfrazada de parámetro técnico. Y como toda decisión cara, no debería tomarla el agente solo.

Dónde va el humano en el bucle

El humano no debe estar en cada vuelta del bucle, sino en los puntos de decisión caros e irreversibles. Revisar cada vuelta convierte al agente en un autocompletado lento y caro: pierdes la ventaja de la automatización y sigues haciendo el trabajo aburrido a mano.

Tu sitio es donde equivocarse es caro de deshacer: aprobar una hipótesis antes de gastar en ejecutarla, o autorizar un merge a main que el agente no puede revertir sin consecuencias. El mejor ejemplo que conozco de esto bien hecho es la metodología de cómo hago que mis agentes se mejoren a sí mismos, donde el único punto de intervención humana es aprobar cada hipótesis antes de implementarla. Todo lo demás corre solo.

Ese patrón, humano en la hipótesis y máquina en la iteración, tiene un nombre cuando lo llevas al extremo.

Un bucle que se mejora a sí mismo

El outer loop llevado al extremo es un bucle que no solo resuelve la tarea, sino que mejora la forma en que la resuelve. En vez de iterar sobre el código, iteras sobre el propio sistema que escribe el código.

El caso de estudio completo es la metodología experiment-driven optimization: medir contra un baseline congelado, proponer una hipótesis, implementarla, validar si el número mejora y documentar el experimento aunque se descarte. Cada ejecución no produce solo un resultado, produce información sobre cómo producir mejores resultados. Ese es el techo del loop engineering: el sistema se optimiza a sí mismo, y tú solo apruebas hipótesis.

Un concepto nuevo cada semana

Suscribirme

Errores comunes

Iterar porque “parece mejor”

Sin una señal que compare contra la vuelta anterior, “parece mejor” es una opinión, y las opiniones no convergen. Un número o un test que diga por qué esta vuelta supera a la anterior es la única forma de saber si de verdad estás iterando.

El bucle sin freno

Un bucle sin presupuesto ni detección de no-progreso es una fuga esperando a ocurrir. Ponle un tope de vueltas antes de ponerle nada más.

El humano revisando cada vuelta

Si apruebas cada paso, no has automatizado nada, solo le has añadido latencia a tu propio trabajo. Reserva tu atención para las decisiones que son caras de deshacer y deja que el bucle corra en el resto.

Confundir más vueltas con más calidad

Pasado cierto punto, cada vuelta adicional sin señal nueva solo suma coste y riesgo de que el agente rompa algo que ya funcionaba. Un bucle que converge en pocas vueltas y para es mejor que uno que da veinte y sigue dando.

Feedback que no discrimina

El más sutil de todos. Un juez que puntúa todo con un 7, o una suite que pasa siempre, dan la ilusión de señal sin serlo. Antes de confiar en tu feedback, comprueba que de verdad separa una salida buena de una mala. Si no distingue, el bucle está ciego aunque parezca que ve, y ninguna cantidad de vueltas lo va a arreglar.

Checklist para diseñar tu bucle

• Cada vuelta tiene una señal de feedback que dice si va mejor o peor que la anterior
• La señal es determinista (tests, lint, type-check) siempre que el problema lo permita, y el juicio de un modelo queda para lo que no se puede reducir a una regla
• El bucle tiene condición de parada explícita, con al menos dos salidas más allá de “objetivo cumplido”: presupuesto agotado y no-progreso detectado
• Hay un presupuesto de vueltas (máximo de iteraciones o de tokens) definido antes de lanzarlo
• El humano interviene solo en las decisiones caras o irreversibles, no en cada vuelta
• Cuando el bucle se atasca, escala o replantea en vez de repetir el mismo paso

Preguntas Frecuentes

¿Loop engineering es lo mismo que prompt engineering?

No: el prompt engineering afina una sola llamada al modelo; el loop engineering diseña el ciclo completo que la rodea, incluido qué contexto entra, cómo se verifica la salida y cuándo se para.

¿Cuál es la diferencia entre inner loop y outer loop?

El inner loop es el ciclo corto de probar y corregir dentro de una sola tarea, como cuando un agente escribe código, corre el test y se corrige en la misma sesión. El outer loop es el ciclo largo que lanza esa tarea muchas veces, revisa el resultado y decide lo siguiente, y es donde el sistema se mejora entre ejecuciones.

¿Cuántas iteraciones son demasiadas?

Depende del coste de cada vuelta y del valor de acertar, pero la alarma no es el número, es la falta de progreso. Si dos vueltas seguidas producen el mismo resultado o el mismo error, ya has iterado de más aunque solo lleves tres. Pon un presupuesto máximo por seguridad y una detección de no-progreso para el caso normal.

¿El loop engineering sirve para cualquier agente?

Sirve para cualquier agente cuya tarea tenga una métrica de calidad que puedas calcular, aunque sea con un modelo como juez. El problema aparece con tareas sin métrica definible: “redacta un email que convenza a este cliente” no tiene test ni criterio claro de acierto, y sin una forma de decir si un borrador supera a otro, el bucle no tiene de dónde agarrarse. Ese suele ser el primer trabajo antes de automatizar nada: convertir “que quede bien” en algo que puedas medir.