Hay una frase que se hizo viral en junio de 2026 y que resume bastante bien hacia dónde se mueve el desarrollo asistido por IA. La dijo Boris Cherny, responsable de Claude Code en Anthropic: ya no escribe prompts a Claude; escribe bucles que escriben los prompts por él. Su trabajo, dice, es escribir bucles. Días después, Peter Steinberger lo formuló de forma parecida: no deberías estar prompteando a tus agentes de código, deberías estar diseñando los bucles que los promptean a ellos. Addy Osmani, de Google, le puso nombre y estructura: loop engineering.
Conviene quitarle hierro al hype desde el principio. El término tiene semanas de vida, gran parte de lo que se ha escrito son blogs con incentivo comercial, y nada de esto sustituye a saber programar. Pero por debajo del ruido hay un cambio real en cómo se trabaja con estas herramientas, y merece la pena entenderlo bien.
El bucle que ya estás usando sin saberlo
Cuando le pides algo a Claude Code, Codex o Cursor, internamente corre un bucle: razona sobre qué hacer, ejecuta una acción (lee un archivo, edita, corre un test), observa el resultado y vuelve a razonar contra el nuevo estado. La documentación de Claude Code lo describe en tres fases que se entrelazan: reunir contexto, actuar y verificar resultados, encadenando docenas de acciones y autocorrigiéndose por el camino.
Esto no es nuevo conceptualmente. El patrón viene de ReAct (Yao et al., 2022) y, si rascas más, del OODA loop militar de John Boyd: observar, orientar, decidir, actuar. Reflexion (Shinn et al., 2023) añadió la capa de autocrítica. Lo verdaderamente nuevo es que un modelo con capacidad de razonamiento ya es lo bastante bueno como para ocupar el rol de "decidir" en tareas abiertas, y que la acción es una llamada a herramientas sobre tu propio repositorio.
Loop engineering opera un piso por encima de eso. En lugar de pilotar cada turno a mano, construyes un bucle externo que se dispara solo (por un schedule, por un PR, por un "go"), se alimenta de trabajo, lanza ayudantes y mantiene estado entre iteraciones.
Tres capas que se acumulan, no que se reemplazan
La forma más útil de situar el concepto es como el tercer escalón de una progresión:
Prompt engineering: optimizas cómo formulas una instrucción concreta.
Context engineering: optimizas qué entra en la ventana del modelo (documentación, historial, definiciones de herramientas). Anthropic lo describe como la evolución natural del prompt engineering: pasas de optimizar palabras a optimizar qué configuración de contexto es más probable que produzca el comportamiento que buscas.
Loop engineering: optimizas el sistema autónomo que decide qué promptar, cuándo, y si el resultado es aceptable.
El matiz importante es que las capas inferiores no desaparecen. Un prompt malo dentro de un bucle produce trabajo malo, sólo que más rápido y más veces. Si tu contexto está sucio, el bucle multiplica el problema. Diseñar bucles no te exime de las otras dos disciplinas; las da por supuestas.
El enemigo número uno: context rot
Si vas a quedarte con un solo concepto técnico, que sea este. El context rot es la degradación medible de la calidad del output a medida que crece el input, incluso antes de llenar la ventana del modelo.
La investigación de Chroma evaluó en 2025 dieciocho modelos frontier y concluyó que los modelos no usan su contexto de forma uniforme: su rendimiento se vuelve cada vez menos fiable a medida que crece la longitud del input. El origen conceptual es el famoso "Lost in the Middle" (Liu et al., 2023), que documentó la curva en U: los modelos rinden mejor cuando la información clave está al principio o al final del contexto, y peor cuando está en el medio, con caídas de precisión de más del 30%.
Los agentes de código maximizan este problema por tres razones: acumulan contexto sin parar (cada archivo leído, cada grep, cada salida de herramienta se queda en la ventana), tienen alta densidad de distractores (una búsqueda de código devuelve muchos resultados parecidos entre sí) y trabajan en horizontes largos. Los síntomas que ya habrás visto: el agente se repite, ignora una restricción que le pusiste antes, se contradice, se vuelve más verboso y empieza a dar respuestas seguras pero equivocadas.
Anthropic formaliza tres técnicas contra esto:
Compaction: resumir la conversación cerca del límite y reiniciar la ventana con ese resumen, descartando salidas verbosas de herramientas antiguas.
Structured note-taking: el agente mantiene un fichero de notas o de tareas fuera del contexto y lo relee tras cada reset. El estado vive en disco, no en la conversación.
Sub-agentes: cada uno trabaja en su propia ventana limpia y devuelve sólo un resumen condensado al agente principal.
La técnica Ralph: el origen antes del nombre
Antes de que "loop engineering" tuviera nombre, Geoffrey Huntley describió a mediados de 2025 algo casi vergonzosamente simple: correr un agente dentro de un bucle de bash trivial que, en cada vuelta, le pasa el mismo fichero de instrucciones. Lo bautizó "Ralph" por Ralph Wiggum, el personaje de Los Simpson, porque es "deterministamente malo en un mundo indeterminado".
La idea no obvia es el reset de contexto. Cada iteración es un agente nuevo, con ventana limpia, que lee el estado del repositorio y la lista de tareas desde disco, hace una unidad de trabajo, commitea y termina. La inteligencia no vive en una sesión heroica de dos horas que se va contaminando, sino en especificaciones granulares, una memoria externa que el modelo no puede ensuciar, y resultados verificables.
Huntley llama "back pressure" a las restricciones (tests, typechecks, linters, build) que rechazan el trabajo inválido y obligan al agente a arreglarlo antes de poder commitear. Es la pieza que convierte un bucle ingenuo en uno fiable.
Las piezas que tu herramienta ya trae
Lo interesante de 2026 es que lo que hace un año eran scripts caseros hoy son funcionalidades de producto. En Claude Code, /goal fija una condición de finalización y el agente sigue trabajando sin que promptees cada paso; un modelo pequeño y rápido lee el transcript después de cada turno y decide si la condición se cumple. /loop re-ejecuta en intervalos. Codex añadió su propio /goal, además de automatizaciones, worktrees, skills y sub-agentes. La técnica Ralph, básicamente, se ha convertido en un comando.
Un detalle crítico de /goal: el evaluador no llama a herramientas, sólo juzga lo que el agente ya ha volcado en la conversación. Por eso la condición de parada tiene que ser verificable desde el propio transcript. "Todos los tests de la carpeta auth pasan y el linter está limpio" es una buena condición. "La aplicación está lista para producción" no lo es, porque nadie puede comprobarlo leyendo el log.
Escribe la condición de parada como un contrato, no como un deseo: un estado final medible, la evidencia que lo demuestra, las restricciones (qué no tocar) y un presupuesto (parar tras N turnos, lo que llegue primero). Ese límite de turnos es, hoy por hoy, tu mejor defensa contra un bucle que se va de coste.
Maker-checker: que escriba uno y verifique otro
El consenso más sólido de todo esto: el modelo que escribió el código es demasiado generoso calificando su propio trabajo. Un segundo sub-agente, con instrucciones distintas y a veces un modelo más potente, atrapa lo que el primero se auto-convenció de que estaba bien. El reparto habitual es uno que explora, uno que implementa y uno que verifica contra la especificación. El equipo de Cognition, detrás de Devin, reporta un hallazgo contraintuitivo: el patrón funciona mejor cuando el agente que escribe y el que revisa no comparten contexto previo.
Un debate que no está cerrado: un hilo o varios
Hay una tensión real que conviene conocer porque afecta a cómo diseñas tus bucles. Cognition publicó un texto titulado, sin rodeos, "no construyas multi-agentes": argumentan que los sub-agentes en paralelo son frágiles porque toman decisiones implícitas que entran en conflicto entre sí, y prefieren un único hilo lineal con el contexto completo. Anthropic defiende lo contrario para tareas de investigación: un orquestador delegando en sub-agentes paralelos supera al agente único.
La síntesis de 2026 es contextual. Para programación secuencial y profunda, el hilo único con sub-agentes acotados suele ser lo más fiable. El paralelismo masivo brilla en exploración e investigación, donde las ramas son independientes. No adoptes paralelismo por defecto sólo porque tu herramienta lo permita.
Seguridad: el "YOLO mode" y la trifecta letal
Hay una cita que circula mucho y que vale la pena tener presente: un agente de IA es un modelo destrozando su entorno dentro de un bucle. El modo de auto-aprobar todo (saltarse los permisos) es clave para la productividad por fuerza bruta, pero peligroso. Tres riesgos concretos: comandos destructivos, exfiltración de código o secretos, y uso de tu máquina como proxy para un ataque.
Las mitigaciones son sensatas y conocidas: correr en un sandbox (un contenedor con lista de hosts permitidos), usar el ordenador de otro (un Codespace, un entorno cloud), y dar credenciales sólo de staging con límite de gasto. La "trifecta letal" de Simon Willison (datos privados + contenido no confiable + capacidad de comunicación externa) sigue sin resolverse y es la raíz de los ataques de prompt injection. Si tu bucle reúne las tres, tienes un problema de seguridad, no de productividad.
Una hoja de ruta sensata
No saltes directo a "agentes trabajando mientras duermo". El camino realista, de menos a más riesgo:
Primero, domina el bucle interno. Antes de cualquier automatización, asegúrate de tener una suite de tests limpia: es el amplificador número uno del valor de un agente, porque le da una señal de verdad/mentira sobre su propio trabajo. Documenta tus convenciones y los comandos exactos de build y test en un fichero que el agente lea siempre.
Después, aplica el bucle a tareas de prueba y error. Problemas con criterio de éxito claro y trabajo tedioso: arreglar tests que fallan, actualizar dependencias, optimizar una consulta lenta midiendo el impacto, reducir el tamaño de una imagen de contenedor. Credenciales de staging, sandbox para el modo agresivo.
Luego, introduce condiciones de parada verificables. Tareas acotadas con una condición que el transcript pueda demostrar, scope cerrado y límite de turnos. Comprueba a propósito que la condición no se auto-certifica como cumplida cuando el trabajo está roto: ese es el fallo que te puede costar caro.
Más adelante, maker-checker y paralelismo. Sólo cuando revisar el código se haya convertido en tu cuello de botella, no generarlo. Y aquí está el límite real de todo esto: tu ancho de banda para revisar lo que el bucle produce, no el número de agentes que puedas lanzar. Puedes tener diez worktrees corriendo; no puedes revisar diez PRs a la vez con criterio.
Lo que no conviene automatizar
Decisiones de visión y arquitectura. Tareas con juicio humano ambiguo. Cualquier cosa que toque sistemas externos en vivo sin un fallback claro: un agente marcará "hecho" sin haber verificado de verdad un flujo end-to-end contra un sistema real. Y, sobre todo, mantén la disciplina de revisar lo que el bucle genera. Hay un concepto que Addy Osmani llama "deuda de comprensión": si el código se acumula más rápido de lo que tú lo entiendes, el bucle deja de trabajar para ti y empiezas a trabajar tú para el bucle.
Conclusión
Loop engineering no es magia ni reemplaza al ingeniero; en todo caso premia al que sabe distinguir código bueno de código malo y puede corregir el output. El cambio mental es real: dejas de pensar en "qué le pido al agente" y pasas a pensar en "qué bucle monto, con qué señal de verificación y con qué límites". La parte aburrida (tests limpios, condiciones verificables, sandbox, revisión humana) es justamente la que separa un bucle que multiplica tu trabajo de uno que multiplica tus errores a la misma velocidad. Construye el bucle, pero sigue siendo el ingeniero.
Rutas de aprendizaje
