Loop engineering: qué es y en qué se diferencia del harness

Escribes el prompt. Lees lo que vuelve. Pegas el error en el chat. Vuelves a escribir.

Una y otra vez.

Ese bucle lo has estado ejecutando tú, con los dedos y la paciencia, durante un par de años. Eres tú quien decide cuándo el agente vuelve a intentarlo, qué contexto le das, si ha terminado o si hay que insistir. El loop engineering propone algo incómodo: que ese bucle deje de ser tuyo.

No que la IA programe sola mientras tú miras Twitter. Eso es otra cosa, y suele acabar mal. La idea es más sutil y más exigente: diseñas el circuito que trabaja, se comprueba, recuerda lo que pasó y sabe cuándo devolverte el marrón. Tú dejas de ser el dedo que pulsa “enter” cada turno y pasas a ser el que diseña la máquina que lo pulsa.

Esto es lo que vas a encontrar:

• Qué es exactamente el loop engineering y cuál es su anatomía
• En qué se diferencia del prompt, el context y el harness engineering (y por qué no es lo mismo)
• Las seis piezas que componen un loop y cómo las traen ya Claude Code y Codex
• Por qué la condición de parada es más difícil que el propio bucle
• Patrones de loop que valen la pena y otros que solo queman tokens
• Cómo montar tu primer loop sin pegarte un tiro en el pie

Qué es el loop engineering ¶

Loop engineering es diseñar el ciclo de trabajo que permite a un agente avanzar sobre una tarea con feedback, memoria, validación y condiciones de parada, sin depender de que tú escribas cada siguiente prompt.

Addy Osmani, que viene de catorce años en Google liderando experiencia de desarrollador en Chrome y, más tarde, en IA, lo formula como reemplazarte a ti mismo en el papel de “persona que prompta al agente”: en vez de promptar, diseñas el sistema que lo hace por ti. Boris Cherny, responsable de Claude Code en Anthropic, lo dice todavía más directo: que su trabajo ya no es promptar a Claude, sino escribir loops que prompten a Claude y decidan qué hacer.

La definición técnica más limpia es esta:

🔑 Un loop es un objetivo recursivo. Defines un propósito y el agente itera hasta cumplirlo. La gracia no está en el “itera”, está en el “hasta cumplirlo”: alguien tiene que decidir si ya está hecho.

La anatomía que se repite, la quites de donde la quites, es siempre la misma:

Trigger → contexto/estado → acción del agente → verificación → decisión → repetir/parar/escalar

Dicho en humano: algo despierta al agente, el agente sabe qué hacer y con qué información, cambia algo, ejecuta pruebas o revisiones, guarda lo aprendido y decide si sigue, se detiene o te devuelve el volante antes de estamparse con elegancia contra el muro.

Lo importante de esa cadena es que la última flecha —repetir, parar o escalar— ya no la pulsas tú. La pulsa el sistema. Y ahí es donde el loop engineering deja de ser un nombre nuevo para un while de toda la vida y se convierte en una decisión de diseño.

En qué se diferencia del prompt, el context y el harness engineering ¶

Esta es la pregunta que importa, porque las cuatro etiquetas suenan parecidas y se mezclan en cualquier conversación de pasillo.

La forma más rápida de no liarte es pensar en cuál es la unidad de trabajo de cada disciplina.

El context engineering se ocupa de construir la ventana de contexto con la información correcta: instrucciones, herramientas, historial, memoria. Si ese término todavía te suena a humo, lo desmenucé pieza a pieza en la arquitectura de agentes de IA para programadores, y el problema concreto que ataca —el context rot, esa degradación de calidad según se llena la ventana— lo trato a fondo en la guía de GSD.

El harness engineering sube un piso. Ya no es solo el contexto, sino todo lo que rodea al modelo: las herramientas que puede tocar, los permisos, los guardarraíles, los bucles de verificación. El contexto es una parte del harness, no al revés. Si no tienes claro qué es un harness ni por qué importa más que el modelo que uses, párate aquí y lee primero qué es el AI harness y el harness engineering; el resto de este artículo da por hecho que esa pieza la tienes.

¿Y dónde encaja entonces el loop?

👉 El loop engineering vive un piso por encima del harness.

El harness es el entorno donde un agente trabaja. El loop es el sistema que encuentra el trabajo, lo reparte, lo comprueba, guarda el estado y decide el siguiente paso una y otra vez en el tiempo. El harness responde a “¿con qué trabaja el agente?”. El loop responde a “¿quién decide cuándo y sobre qué vuelve a trabajar, y cuándo para?”.

💡 Si lo quieres en una frase: el harness es el coche; el loop es el copiloto que decide la ruta, repite el tramo cuando hay niebla y te avisa de que pares a repostar antes de quedarte tirado.

Hay una distinción que me parece la más útil de todas, y la planteó Kenji en su análisis del tema: una automatización ejecuta una secuencia fija; un loop contiene una decisión. La automatización hace siempre lo mismo en el mismo orden. El loop, en cada vuelta, se pregunta: ¿hemos alcanzado el objetivo? Y si no, ¿reintento, busco más evidencia, cambio de estrategia, escalo o paro? Esa pregunta es la frontera. Sin ella tienes un cron job con sombrero.

Dos cosas que vas a necesitar antes de seguir, y que ya he tratado por separado: saber dónde poner el límite de autonomía según lo que te juegas, que aterrizo en cómo hacer bien vibe coding, y tener una estrategia de verificación que no se quede en “tests verdes”, porque la puerta de calidad es lo que sostiene todo el loop; eso lo desarrollo en la guía de testing con IA, desde mutation testing hasta verificación en el navegador. Si esos dos cimientos te flojean, el loop más bonito del mundo se te cae.

Las seis piezas de un loop ¶

En su versión completa, un loop necesita seis bloques. Cinco hacen el trabajo y uno se encarga de que el sistema no tenga amnesia entre vueltas.

La parte interesante es que estas piezas ya no son bricolaje. Hace un tiempo, montar un loop significaba escribir una montaña de Bash que mantenías tú solo para siempre jamás. Hoy las piezas vienen de serie dentro de los productos, y lo más llamativo es que la lista es casi idéntica en Codex y en Claude Code:

Cada una de estas piezas la has visto suelta en algún otro sitio. Las skills son, en esencia, componentes de harness empaquetados y reutilizables; si todavía no las usas a diario, la guía de Agent Skills para Claude Code, Codex y Cursor te ahorra el “explicar el proyecto otra vez” en cada vuelta del bucle. El estado suele ser un AGENTS.md o un fichero de progreso, y para escribir uno que el agente respete de verdad tienes para qué sirve AGENTS.md y cómo usarlo bien y, si vas con Claude Code, cómo configurar CLAUDE.md y rules.

La memoria merece un párrafo aparte, porque suena demasiado tonta para importar tanto.

Puede ser un Markdown. Puede ser un tablero de Linear. Cualquier cosa que viva fuera de la conversación y recuerde qué está hecho y qué queda pendiente. ¿Por qué importa? Porque el modelo olvida todo entre ejecuciones, así que la memoria tiene que estar en disco y no en el contexto. El agente olvida; el repositorio no. Sin ese fichero de estado, mañana por la mañana el loop empieza de cero como un becario con amnesia el primer día.

Tres apuntes para situarte antes de la parte difícil. Si vienes del Spec-Driven Development, la especificación es la condición de parada del loop antes de tener nombre, y la idea de “constitución de proyecto” la tienes en Spec Kit de GitHub. Si te pica construir tu propio harness sobre el que montar el loop en vez de depender de uno cerrado, el equipo de Astro publicó Flue, un framework de agent harness en TypeScript. Y si quieres ver la versión más radical de un loop —el agente que experimenta, mide y decide sin humano de por medio— está en Karpathy y Auto Research.

La condición de parada es más difícil que el bucle ¶

Aquí está la trampa, y conviene decirla sin anestesia.

Cualquiera sabe escribir un while que llame a un modelo. Eso no es ingeniería, es un viernes por la tarde. Lo difícil —lo que separa un loop útil de una chimenea de tokens con pretensiones— es el check que decide si el trabajo está bien hecho.

Simon Taylor lo clavó: el titular viral es “escribir loops”, pero el trabajo real es escribir quality gates. Sin una puerta de calidad —tests, build, navegador, verificación externa— un loop solo genera trabajo más rápido que luego tienes que revisar igualmente. Has movido el cuello de botella, no lo has eliminado.

Mira la diferencia entre las dos versiones del mismo bucle:

# Loop ingenuo: genera trabajo, no garantías
while True:
    result = agent.run(task)
    if agent.thinks_its_done():   # el agente se autoevalúa: mala idea
        break

# Loop con quality gate: la parada depende de evidencia, no de opinión
MAX_ITERATIONS = 5
budget = TokenBudget(limit=200_000)

for attempt in range(MAX_ITERATIONS):
    result = agent.run(task, state=state)

    # La puerta de calidad es determinista, no la opinión del modelo
    checks = run_quality_gate(result)   # tests, lint, build, navegador
    state.record(attempt, result, checks)

    if checks.all_passed():
        break
    if budget.exceeded():
        escalate_to_human(state)        # devuelve el volante a tiempo
        break
    # si no, otra vuelta con el estado actualizado y los fallos como contexto

La pieza clave del segundo ejemplo es run_quality_gate. No le preguntas al modelo si lo ha hecho bien, porque el modelo que escribió el código es demasiado buena gente corrigiéndose a sí mismo. Le pides evidencia: que pasen los tests de test/auth, que el lint esté limpio, que el navegador real muestre lo que tiene que mostrar.

Esto, por cierto, es justo lo que hace por dentro el comando /goal de Claude Code. /loop re-ejecuta un prompt en una cadencia (cada cinco minutos, cada hora); /goal mantiene la sesión trabajando turno tras turno hasta que una condición que tú escribiste se cumple de verdad. Y después de cada turno, un modelo pequeño y separado comprueba si has terminado, de modo que el agente que escribió el código no es el mismo que lo califica. Codex tiene el mismo primitivo, también llamado /goal, con pausa, reanudación y reinicio. Maker y checker separados, aplicado a la propia condición de parada.

🛡️ Antes de soltar un loop a su aire, ponle tres cosas: un presupuesto de tokens, un número máximo de iteraciones y una puerta de calidad determinista. Si falta cualquiera de las tres, no tienes un loop, tienes una factura sorpresa.

Si tu única puerta de calidad son los tests, ten cuidado con otra trampa: el agente puede aprender a satisfacer el test sin resolver el problema. Por eso la verificación en serio mezcla comprobaciones deterministas con revisión de otro modelo, y por eso conviene tener una estrategia de testing pensada para esto, como la que enlazaba más arriba.

Patrones de loop que valen la pena ¶

Los casos donde un loop brilla comparten tres rasgos: son repetitivos, verificables y con poco margen de interpretación. Cuanto más subjetivo es el “está bien hecho”, peor encaja un loop y más te toca pilotar a mano.

Estos son los patrones que tienen sentido de verdad:

OpenAI documenta que su equipo usa automatizaciones para justo esto: triaje diario de issues, resúmenes de fallos de CI, briefings de commits y caza de bugs que alguien metió la semana pasada. No son demos de conferencia, es la fontanería aburrida que nadie quiere hacer a mano un lunes.

Hay un caso que va un paso más allá de la programación pura y que merece la pena mirar: el bucle de Auto Research de Karpathy, donde el agente experimenta, mide y decide sin intervención humana, sacando al humano del cuello de botella. Es la versión “de laboratorio” de la misma idea que aquí aplicamos a issues y CI.

Fíjate en lo que no está en la tabla: “diseña la arquitectura del módulo de pagos”, “decide si migramos a otro framework”, “escribe la nota de prensa con el tono justo”. Todo eso tiene margen de interpretación a raudales, y meterlo en un loop es pedirle a una lavadora que te elija la ropa. El criterio humano todavía aporta, y mucho, en la parte exploratoria. Dónde poner ese límite según lo que te juegas es justo la conversación del vibe coding que enlazaba al principio.

Cómo se ve un loop entero ¶

Pongamos las seis piezas a trabajar juntas en un solo ejemplo, porque en abstracto todo suena precioso y en la práctica es donde un loop aguanta o gotea por todas partes.

Imagina este montaje, que es de los más útiles que existen:

1. Una automatización se dispara cada mañana sobre el repo.
2. Su prompt llama a una skill de triaje que lee los fallos de CI de ayer, las issues abiertas y los commits recientes, y escribe los hallazgos en un fichero Markdown o en un tablero de Linear (eso es el estado).
3. Por cada hallazgo que valga la pena, el hilo abre un worktree aislado y manda un subagente a redactar el fix.
4. Un segundo subagente revisa ese borrador contra las skills del proyecto y los tests existentes. El que hace no es el que revisa.
5. Los conectores dejan que el loop abra el PR y actualice el ticket.
6. Lo que el loop no sabe resolver aterriza en una bandeja de triaje para ti.

El fichero de estado es la columna vertebral de todo el invento. Recuerda qué se intentó, qué pasó y qué sigue abierto, así que mañana por la mañana la ejecución arranca donde lo dejó la de hoy.

¿Y sabes qué es lo más bonito de ese montaje? Que lo diseñaste una vez. No prompteaste ninguno de esos pasos. Ese es el cambio del que habla Cherny, hecho realidad. Y es el mismo loop tanto en Codex como en Claude Code, porque las piezas son las mismas piezas.

Si te pica el gusanillo de construir tu propio harness sobre el que montar todo esto en lugar de depender de uno cerrado, ahí es donde entra Flue, el framework de agent harness en TypeScript que enlazaba antes: te deja escribir tu propio Claude Code y desplegarlo donde quieras.

Cómo montar tu primer loop hoy ¶

No empieces por el sistema de seis piezas con subagentes adversariales y conectores a producción. Eso es como aprender a conducir en un Fórmula 1.

Empieza pequeño y crece a partir de lo que funcione:

1. Elige una tarea aburrida y verificable. Un test que se rompe a menudo, un chequeo de dependencias, un resumen de CI. Nada con criterio subjetivo.
2. Escribe la condición de parada antes que el loop. “Pasan todos los tests de test/payments y el lint está limpio” es una buena condición. “Cuando esté bien” no lo es.
3. Ponle un presupuesto. Número máximo de iteraciones y tope de tokens. Que el loop pueda fracasar y avisarte es una característica, no un bug.
4. Arranca con /loop o /goal en tu herramienta. En Claude Code, /goal para “trabaja hasta que esto sea verdad” y /loop para “revisa esto cada X”. Las tareas son de sesión: viven en la conversación actual.
5. Vigila la primera vuelta. No te vayas a hacer café en el primer ciclo de un loop nuevo. Míralo trabajar una vez antes de confiar en él.
6. Añade la memoria cuando el loop tenga que sobrevivir entre sesiones. Un fichero Markdown de estado es suficiente para empezar.

💡 Si solo te llevas una cosa de aquí: la condición de parada se escribe primero. El bucle es lo fácil; saber cuándo parar es el trabajo.

Y si vienes del mundo del Spec-Driven Development, esto encaja como un guante: la especificación es la condición de parada del loop antes de tener nombre, como apuntaba con Spec Kit más arriba.

Los riesgos que se repiten ¶

Un loop bien diseñado es una palanca enorme. Uno mal diseñado es una forma elegante de transferir dinero de tu bolsillo a los laboratorios de IA. Estos son los peligros, y casi todos tienen el mismo origen: dar autonomía sin poner frenos.

1. Token burn. Si el loop no tiene presupuesto ni condición de parada, se convierte en una chimenea de tokens. El consumo puede dispararse, sobre todo con subagentes, porque cada uno hace su propio trabajo de modelo y herramientas.
2. Slop acelerado. Si el agente itera sin un buen verificador, produce más cantidad de mala solución, más rápido. Velocidad sin puerta de calidad es solo deuda generada antes.
3. Comprehension debt. Cuanto más rápido genera el loop código que tú no has escrito, mayor es la distancia entre lo que existe y lo que entiendes. Un loop fluido hace crecer esa deuda más deprisa, a menos que leas lo que produce.
4. Overfitting a los tests. Si el único verificador es “tests verdes”, el agente puede aprender a satisfacer el test sin resolver el problema.
5. Autonomía insegura. Si el loop toca GitHub, Linear, Slack, staging o producción, la pregunta ya no es solo si completó la tarea, sino si cada acción estaba autorizada, acotada y respaldada por evidencia. Eso son permisos, auditoría y límites, no buena fe.
6. Rigidez excesiva. Convertirlo todo en loop puede matar la parte exploratoria donde el criterio humano sigue siendo lo más valioso que pones encima de la mesa.

Hay un riesgo más que es psicológico y por eso el más traicionero. Cuando el loop se ejecuta solo, es tentador dejar de tener opinión y aceptar lo que devuelva. Dos personas pueden montar el mismo loop exacto y obtener resultados opuestos: una lo usa para ir más rápido sobre trabajo que entiende a fondo; la otra, para evitar entender el trabajo. El loop no nota la diferencia. Tú sí.

Construye el loop, sigue siendo el ingeniero ¶

El loop engineering no es magia ni es el fin de tu trabajo. Es un cambio en dónde está la palanca.

Durante dos años la palanca estuvo en el prompt. Luego en el contexto. Luego en el harness, el entorno alrededor del modelo. Ahora hay una capa más: el ciclo que decide cuándo el harness vuelve a ponerse a trabajar y cuándo te devuelve el control. El trabajo no se ha vuelto más fácil; el punto de apoyo se ha movido.

La verificación sigue siendo tuya. Un loop que se ejecuta sin supervisión es también un loop que comete errores sin supervisión. Por eso separas al que hace del que revisa, y aun así “hecho” es una afirmación, no una demostración. Tu trabajo, el de siempre, es entregar código que has confirmado que funciona.

Así que monta tus loops. Pero móntalos como alguien que tiene intención de seguir siendo el ingeniero, no la persona que aprieta el botón de “play” y mira para otro lado.

El futuro no es escribir mejores prompts. Es construir un buen “no sigas por ahí, criatura” y saber exactamente cuándo te toca volver a coger el volante.

Preguntas frecuentes ¶

¿Qué es el loop engineering? ¶

Es la disciplina de diseñar el ciclo de trabajo de un agente de IA para que avance sobre una tarea con feedback, memoria, validación y condiciones de parada, sin que tú escribas cada prompt. En lugar de promptar al agente, diseñas el sistema que lo prompta por ti.

¿En qué se diferencia el loop engineering del harness engineering? ¶

El harness engineering diseña el entorno donde un agente trabaja: herramientas, permisos, guardarraíles y verificaciones. El loop engineering vive un piso por encima: es el sistema que encuentra el trabajo, lo reparte, lo comprueba, guarda el estado y decide cuándo el harness vuelve a actuar o para.

¿Es lo mismo que el context engineering? ¶

No. El context engineering construye la ventana de contexto con la información correcta para un turno. El loop engineering se ocupa del ciclo completo a lo largo del tiempo: muchos turnos, con verificación y memoria entre ellos. El contexto es una pieza dentro del loop, no al revés.

¿Un loop no es solo un bucle while con un LLM? ¶

Mecánicamente, sí. Pero un while no es el trabajo difícil. Lo difícil es la condición de parada y la puerta de calidad que deciden si el resultado es válido. Sin ese check determinista, el loop solo genera trabajo más rápido del que puedes revisar.

¿Qué diferencia hay entre una automatización y un loop? ¶

Una automatización ejecuta una secuencia fija siempre igual. Un loop contiene una decisión: en cada vuelta se pregunta si alcanzó el objetivo y, si no, decide si reintenta, busca más evidencia, cambia de estrategia, escala o para.

¿Para qué sirven los comandos /loop y /goal de Claude Code? ¶

/loop re-ejecuta un prompt en una cadencia (cada cierto intervalo). /goal mantiene la sesión trabajando turno tras turno hasta que se cumple una condición verificable; después de cada turno, un modelo pequeño y separado comprueba si la condición se cumple.

¿Cuáles son las piezas mínimas de un loop? ¶

Cinco que hacen el trabajo —automatizaciones, worktrees, skills, conectores/MCP y subagentes— más una sexta para la memoria externa. La memoria puede ser tan simple como un fichero Markdown o un tablero de Linear que persista entre ejecuciones.

¿Por qué conviene separar el agente que escribe del que revisa? ¶

Porque el modelo que escribió el código tiende a aprobar su propio trabajo con demasiada facilidad. Un segundo agente, con instrucciones distintas y a veces otro modelo, detecta lo que el primero se autoconvenció de que estaba bien. Es la base de una parada de loop fiable.

¿Qué tareas encajan bien en un loop y cuáles no? ¶

Encajan las repetitivas y verificables con poco margen de interpretación: arreglar tests, actualizar dependencias, triar issues, vigilar PRs. Encajan mal las que dependen de criterio subjetivo o aprobaciones externas, como decisiones de arquitectura o de producto.

¿Cuál es el mayor riesgo de los loops? ¶

El consumo descontrolado de tokens cuando no hay presupuesto ni condición de parada, y la deuda de comprensión: cuanto más código genera el loop que tú no lees, más se separa lo que existe de lo que entiendes. La verificación humana sigue siendo innegociable.

Fuentes ¶

• Addy Osmani, “Loop Engineering”
• Claude Code Docs, “Run prompts on a schedule” (/loop, /goal)
• OpenAI Developers, “Automations – Codex app”
• OpenAI Developers, “Subagents – Codex”
• Simon Taylor, sobre quality gates en loops
• Firecrawl, “Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops”
• Kenji, “The New Coding Style: Engineering in Loops”

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter