Loop engineering: diseña el bucle que da instrucciones a tu agente de IA

Deja de darle instrucciones a tu agente de una en una. Construye el bucle que lo haga por ti. Ese cambio de mentalidad ya tiene nombre, loop engineering, y cambia en qué inviertes las horas cuando trabajas con agentes de IA.

El problema de las dos de la madrugada

Imagina una noche larga con un agente de código. Escribe un parche. Ejecutas los tests y fallan tres. Pegas la salida en rojo en el chat y escribes «arregla esto». El agente lo vuelve a intentar y tú vuelves a pegar. En la quinta ronda caes en la cuenta: cada mensaje que envías es mecánico. Ejecuta los tests. Lee el fallo. Señala la causa probable. Inténtalo otra vez. Para cuando todo esté en verde.

Eres el componente más capaz de ese sistema y te están usando como portapapeles.

Miles de ingenieros chocaron con el mismo muro hacia mediados de 2026, y la idea que salió de ahí fue tajante: deja de escribirle prompts al agente y diseña el bucle que se los escriba.

De los prompts a los bucles

El loop engineering es el último peldaño de una escalera que el sector lleva años subiendo. Cada peldaño envuelve al anterior en lugar de sustituirlo. Primero se ajustaron las palabras, luego los datos, luego el entorno. Ahora toca diseñar el propio ciclo.

• El prompt engineering (aproximadamente de 2022 a 2024) pregunta qué palabras usar. Su límite es evidente: ninguna redacción puede darle a un modelo un dato que nunca recibió.
• El context engineering (2025) pregunta qué datos ve el modelo en el momento de la inferencia.
• El harness engineering (principios de 2026) pregunta qué rodea al modelo: herramientas, un sandbox, validadores.
• El loop engineering (2026) pregunta qué ciclo debe ejecutarse y cuándo termina.

Tu papel se desplaza con él. Empiezas como operador que teclea prompts, pasas a ser un gestor que supervisa varios agentes en paralelo y acabas como diseñador de sistemas. En ese punto defines qué significan «bien» y «terminado», y dejas que la máquina persiga esos objetivos.

Una definición de trabajo: el loop engineering consiste en diseñar deliberadamente el bucle en el que funciona un agente, incluidos su disparador, su objetivo, sus comprobaciones, su memoria y sus reglas de parada, en lugar de escribir a mano cada siguiente instrucción.

Todo agente ya funciona en un bucle

La gracia está en que ningún agente carece de bucle. Casi todos tienen uno, y pocas personas lo moldean a propósito. Esa diferencia separa al agente que termina el trabajo sin ruido del que se funde un presupuesto durante la noche convencido de que avanza.

El ciclo de fondo es el patrón ReAct de 2022: pensar, actuar llamando a una herramienta, observar el resultado y repetir hasta terminar. No es nada nuevo. Lo que cambió en 2026 es que este ciclo se trata como lo principal que hay que diseñar, con el mismo cuidado que se le daría a una API. Cuando los agentes de código difieren en calidad, rara vez es por el modelo base. Suele ser por el diseño del bucle.

El verificador es el cuello de botella

Si solo te quedas con una idea, que sea esta: en cualquier bucle, quien limita los resultados es el verificador, no el modelo.

Un bucle no es más que un generador conectado a un verificador. El generador, que es el modelo, es barato y nunca se cansa, así que mil intentos no cuestan casi nada. El verificador es el que decide si toda esa actividad produce algo útil o un montón de basura.

Los bucles compensan gracias a una asimetría a veces llamada la ley del verificador: en muchas tareas, comprobar una respuesta es mucho más fácil que producirla. Esa es toda la economía. Generas, compruebas, vuelves a generar y sigues saliendo ganando, porque la comprobación cuesta muy poco.

Hay dos tipos de verificadores, y elegir entre ellos es la mayor parte del oficio:

• Las comprobaciones deterministas ejecutan los tests, validan el esquema o confirman una puntuación. Son baratas, fiables y difíciles de engañar, así que prefiérelas siempre que puedas.
• Los montajes LLM-as-judge ponen a un segundo modelo a calificar la salida con una rúbrica. Sirven para objetivos difusos, pero se pueden engañar, y los sesgos de posición, verbosidad y autopreferencia están bien documentados.

El riesgo es fácil de pasar por alto. Un verificador débil no falla de forma ruidosa. Produce basura con total seguridad, cientos de veces seguidas. Por eso escribir el verificador se ha convertido en el nuevo prompt engineering.

Apila bucles alrededor de bucles

Lo que convierte esto en un oficio es el anidamiento. Piensa en cuatro bucles concéntricos, cada uno con un reloj más lento. El interior hace el trabajo, y cada anillo exterior vuelve el sistema más fiable, más autónomo y, al final, capaz de mejorarse a sí mismo.

1. El bucle del agente. El modelo llama a herramientas hasta completar la tarea.
2. El bucle de verificación. Un evaluador puntúa la salida con una rúbrica y la devuelve con comentarios si no llega.
3. El bucle dirigido por eventos. Webhooks, tareas cron o mensajes entrantes lanzan ejecuciones, de modo que el agente trabaja mientras duermes y una persona puede aprobar antes de que nada se publique.
4. El bucle de hill climbing. Un agente de análisis aparte lee las trazas de producción y reescribe el propio harness: prompts, herramientas y rúbrica. El sistema mejora el sistema.

El consejo habitual es avanzar hacia fuera, hacia los bucles tres y cuatro, donde las ganancias se acumulan. Es sensato, con una salvedad. Un cuarto bucle alrededor de un verificador débil solo automatiza basura segura de sí misma a gran escala. Así que apila hacia fuera para ganar alcance, pero solo cuando el verificador más interno sea sólido.

Escribe el contrato, no el prompt

Así se ve el cambio en la práctica. Dejas de escribir instrucciones y escribes en su lugar una definición de «terminado», es decir, una función de recompensa más una regla de parada, y dejas que el bucle la persiga:

Goal: get the test suite passing.
Done when: all tests green - and no test was skipped or deleted to fake it.
Loop: run tests -> read failures -> fix the likely cause -> run again.
Stop when: done, or after 6 rounds (then summarize what's left).

Ni una sola instrucción llegó al modelo, y eso es loop engineering en su forma más pequeña.

Acota el bucle o él acotará tu presupuesto

Un bucle multiplica tu esfuerzo, y eso corta en ambos sentidos. Dale a cada bucle tres salidas: éxito cuando el verificador aprueba, rendición cuando se agota un límite o el presupuesto, y traspaso cuando escala a una persona. La regla de oro es que el harness, nunca el agente, debe garantizar que el bucle termine.

Cada fallo típico tiene su salvaguarda:

• El girar sin fin se resuelve con un tope estricto de iteraciones y la detección de ejecuciones que no avanzan.
• El coste desbocado se resuelve con comprobaciones de presupuesto antes de cada llamada y un triaje barato antes del trabajo caro.
• Un «terminado» alucinado se resuelve con un verificador determinista e independiente. Nunca dejes que un agente califique su propio trabajo.
• El reward hacking se resuelve con criterios endurecidos y una aprobación humana para las acciones sensibles.

Antes de que un bucle funcione sin supervisión, prueba el verificador con casos que sabes que son buenos y casos que sabes que son malos. Confirma que rechaza la salida mala, y no solo que acepta la buena. Un verificador que nadie ha probado es solo una opinión.

No sueltes el volante

Automatizar no significa salirse del proceso. Pon un punto de control humano donde importa: aprobar llamadas a herramientas arriesgadas, calificar resultados críticos y dar el visto bueno antes de que un cambio en el harness entre en producción. También hay un coste más discreto. Cuando un bucle publica una corrección, has publicado algo que quizá no entiendes del todo. A esa brecha se la ha llamado deuda de comprensión, y puede que resulte ser la próxima forma de deuda técnica.

La ética cabe en una frase: construye el bucle, pero constrúyelo como alguien que piensa seguir siendo el ingeniero y no solo la persona que pulsa el botón de inicio.

Las dos de la madrugada, otra vez

Vuelven a ser las dos de la madrugada, y esta vez estás dormido. Horas antes saltó un webhook. Por la mañana te espera un borrador de pull request. El bucle se detuvo antes de hacer merge porque esa decisión no puede tomarla solo, y dejó un resumen limpio de qué cambió y por qué.

Ya no eres el portapapeles. Eres quien diseñó la maquinaria, y cada pieza remite a una decisión tuya: el objetivo, el verificador, los límites y los puntos en los que tiene que detenerse y preguntar.

Eso es loop engineering. Construye uno, y constrúyelo de forma que sigas siendo el ingeniero.