Loop Engineering: ¿moda del momento o próximo salto?

A mediados de junio, un post de Peter Steinberger, desarrollador conocido por haber construido y luego vendido PSPDFKit, circula durante semanas entre los expertos: los agentes de IA ya no se promptean, se diseñan los loops que los hacen funcionar. Pocas líneas, tono de revelación, y en cuestión de pocos días el término "loop engineering" aparece en todas partes, desde Analytics Vidhya hasta los blogs corporativos especializados en infraestructuras para agentes como Requesty. Incluso Boris Cherny, entre los arquitectos de Claude Code, refuerza la idea hablando de un salto comparable al del código fuente compilado a los agentes autónomos, como relata BDTechTalks reconstruyendo la génesis del debate.

Suena familiar. En los últimos tres años, el sector ya ha atravesado el mismo rito casi cada seis meses: prompt engineering, luego context engineering, luego harness engineering, cada vez con el anuncio de un cambio de paradigma. La pregunta honesta que debemos hacernos no es si el loop engineering existe —existe, lo demuestran las herramientas que lo implementan concretamente—, sino si representa realmente un salto conceptual o si es el último capítulo de una historia más larga, contada cada vez con un nombre nuevo.

Del prompt al sistema

Para entender qué cambia, hace falta reconstruir la secuencia. El prompt engineering, entre 2022 y 2023, se refería a la formulación de la instrucción individual, la elección de las palabras, la estructura del contexto inmediato para obtener una respuesta mejor de un modelo todavía relativamente miope. Con el alargamiento de las ventanas de contexto y la aparición de los primeros agentes capaces de usar herramientas, la atención se desplazó al context engineering, es decir, a qué poner dentro de esa ventana, qué documentos recuperar, cómo organizar la memoria, qué herramientas poner a disposición en un momento dado.

El paso siguiente, el que BDTechTalks describe en su artículo sobre el harness engineering de principios de junio, se refiere al andamiaje alrededor del modelo, el llamado harness —el conjunto de herramientas, permisos, sandboxes y reglas que transforman un modelo de lenguaje en un agente capaz de operar en un entorno real sin supervisión constante—. Es aquí donde la comparación con la anatomía se vuelve útil: si el modelo es el cerebro, el harness es el cuerpo que le permite actuar en el mundo.

El loop engineering, en esta progresión, desplaza aún más el centro de gravedad. Ya no se refiere solo a qué sabe el modelo o con qué puede interactuar; se refiere a cómo el ciclo de ejecución se repite en el tiempo, cuándo se detiene, quién verifica el resultado antes de que se considere definitivo. Es la diferencia entre construir una buena herramienta y construir el proceso que decide cuándo esa herramienta ha terminado su trabajo. Requesty, en una guía práctica pensada para quienes construyen agentes en producción, distingue cuatro variantes operativas: loops de latido continuo para la monitorización, loops planificados de forma temporal para tareas recurrentes, loops activados por eventos externos como un push en un repositorio, y loops orientados a un objetivo que se detienen solo al alcanzar una condición de éxito explícita; véase su visión general sobre los tipos de loops.

El centro de gravedad se desplaza de verdad, por tanto, del contenido del prompt al sistema de control que lo rodea. Queda por preguntarse, sin embargo, si este desplazamiento merece una etiqueta propia o si es simplemente la evolución natural, casi inevitable, del camino ya trazado por el harness engineering.

No nació ayer

Aquí vale la pena reducir la velocidad, porque es el punto en el que el entusiasmo del momento corre el riesgo de hacer perder la memoria técnica. La idea de un sistema que genera un intento, lo observa, lo corrige y vuelve a intentarlo no nace con los agentes LLM de 2026. El patrón ReAct, publicado por un grupo de investigación de Princeton y Google en 2022, ya formalizaba el ciclo de razonamiento y acción entrelazados que hoy muchos llaman simplemente "el loop". El año siguiente, Reflexion añadía un nivel de autocrítica verbal: el agente que vuelve a leer su propio error y lo transforma en una lección para el intento siguiente. Y la separación entre quien genera una solución y quien la verifica, el llamado patrón maker-checker, es un principio de ingeniería de software tan viejo como la propia code review, mucho antes de que a alguien se le ocurriera aplicarlo a un modelo de lenguaje.

Incluso la literatura más reciente confirma la continuidad más que la ruptura. Un trabajo de 2024 de la Universidad Tsinghua propone un framework de refinamiento iterativo de la experiencia para agentes que desarrollan software, en el que el agente acumula y filtra progresivamente sus propias experiencias pasadas a lo largo de ciclos sucesivos —una arquitectura conceptualmente cercana a muchos loops actuales, publicada cuando el término "loop engineering" aún no había sido acuñado, como se lee en el paper original—.

Hay una imagen que transmite bien la idea, tomada prestada de un ámbito ajeno a la informática. En el videojuego de investigación The Forgotten City, el protagonista revive el mismo día decenas de veces, no para sufrir el tiempo que se repite como un castigo sino para usarlo; cada ciclo afina la comprensión de un misterio que en la primera vuelta parecía irresoluble. No es casualidad que Douglas Hofstadter, en Gödel, Escher, Bach, ya hubiera dado un nombre filosófico a esta idea: la "strange loop", un ciclo que volviendo sobre sí mismo produce un nivel de comprensión más alto del que había partido. El loop engineering, en el fondo, intenta hacer lo mismo con el código, con la diferencia de que al cerrar el círculo ya no está solo la intuición humana sino un segundo agente que hace de controlador.

Entonces, ¿qué es realmente nuevo? No la teoría, que se hunde en años de investigación sobre agentes y sistemas multiagente. Es nueva la sistematización práctica, la aparición de comandos dedicados como /loop en Claude Code o las automatizaciones recurrentes en Codex, que hacen que un patrón antes artesanal sea finalmente componible y reutilizable a escala, como confirma también el análisis técnico publicado por max-gherman.dev sobre la anatomía de los loops modernos. Es la diferencia, ya surgida en una conversación anterior sobre este mismo artículo, entre una revolución teórica y una maduración de ingeniería —menos espectacular de anunciar, probablemente más útil de tener—. Esquema conceptual de Loop Engineering

Quién gana, quién arriesga

¿Dónde funciona de verdad este enfoque? Los ejemplos más sólidos llegan de tareas con un criterio de éxito objetivo y verificable mecánicamente: el agente que corrige código hasta que la suite de tests pasa, el que monitoriza los logs de producción y abre un ticket cuando la tasa de error supera un umbral, el que revisa pull requests más antiguas de unos días señalando los bloqueos a los autores. En estos casos, el loop tiene un árbitro claro —el test que pasa o falla, el número que supera o no supera el umbral— y la verificación no requiere juicio humano en tiempo real.

El problema empieza cuando ese árbitro falta o es débil. Si el criterio de éxito es vago —"el informe es bastante bueno", "el análisis está completo"—, el loop arriesga lo que el análisis técnico de max-gherman.dev llama aprobación alucinada: un segundo agente que declara terminado un trabajo solo parcialmente hecho porque su propio juicio no está anclado a nada verificable mecánicamente. Requesty, en su propia guía operativa, enumera los mismos riesgos con otros nombres: la fuga incontrolada de iteraciones sin un techo máximo, la degradación de contexto en los loops muy largos, la amnesia de estado cuando el agente pierde el rastro de lo que ya ha procesado entre un ciclo y otro.

¿Quién gana en este escenario? Ganan probablemente los equipos que afrontan tareas repetitivas y bien definidas, con un presupuesto para experimentar la infraestructura necesaria: revisión automática del código, monitorización continua, extracción de datos a gran escala. Ganan también los proveedores de infraestructura —gateways de enrutamiento de modelos, plataformas de orquestación— que encuentran en el loop engineering un vocabulario nuevo para vender un problema en realidad ya existente: el de gestionar con seguridad y costes previsibles un número de llamadas al modelo que crece en órdenes de magnitud respecto a un simple chat. Quienes más arriesgan son los equipos que importan el entusiasmo sin la infraestructura de verificación subyacente, convencidos de que basta con añadir un ciclo de repetición a un prompt ya frágil para obtener una fiabilidad que antes no existía. Un loop alrededor de un mal criterio de éxito no produce un resultado mejor; solo produce un error repetido con más seguridad.

La cuenta en tokens

La última pregunta, quizás la más concreta para quienes debéis decidir si invertir tiempo en este enfoque, se refiere a la relación entre calidad ganada y recursos consumidos. Un loop no es gratis: cada iteración es una nueva llamada al modelo, a menudo más de una si el ciclo prevé un generador y un verificador separados o varios agentes especializados que se dividen el trabajo. Requesty estima que un loop de revisión diaria con varios subagentes puede costar decenas de dólares al día a precio completo en los modelos más potentes, cifra que baja sensiblemente enrutando solo los pasos que realmente requieren razonamiento avanzado hacia los modelos más caros, y delegando la clasificación y el cribado a modelos más económicos, como se describe en su análisis sobre los costes de enrutamiento.

Esto abre una pregunta que el entusiasmo general tiende a dejar en segundo plano: ¿cuánto vale de verdad una iteración más? Si el segundo intento del loop corrige un error que de otro modo habría acabado en producción, el coste probablemente esté bien gastado; si, en cambio, el ciclo sigue girando produciendo variaciones marginales de un resultado ya aceptable al primer intento, se trata de un gasto que ningún dashboard de costes justifica a posteriori. La medida seria del valor de un loop, por tanto, no es cuántas iteraciones realiza, sino cuánto mejora de verdad el resultado respecto al coste marginal de cada ciclo adicional —un cálculo que demasiados artículos entusiastas sobre el tema simplemente no hacen—.

Una disciplina de control, no una nueva inteligencia

Volviendo a la pregunta de apertura, ¿merece el loop engineering la atención que está recibiendo? La respuesta honesta es sí, con una premisa que redimensiona el alcance del anuncio. No estamos asistiendo al descubrimiento de un principio nuevo; el ciclo genera-verifica-corrige ya estaba escrito en los papers sobre agentes de 2022 y aún antes en las prácticas de ingeniería de software tradicional. Lo que está madurando efectivamente es la capacidad de hacer ese principio operativo a escala, con herramientas nativas, estado persistente fuera del contexto, enrutamiento de costes y criterios de parada más rigurosos que un simple juicio subjetivo.

Vale la pena preguntarse, entonces, si dentro de un año se seguirá hablando del loop engineering como una categoría en sí misma, o si el término será simplemente absorbido por el vocabulario ordinario de la ingeniería de agentes —tal como hoy ya nadie habla del prompt engineering como una disciplina separada, sino que se da por hecho en cada conversación técnica—. Quizás sea precisamente este el destino más probable para el loop engineering: no una revolución para recordar, sino una pieza que en unos meses dejará de necesitar un nombre propio para ser practicada.