Loop Engineering: Cómo diseñar bucles de agentes
La primera vez que construí un bucle sin una condición de parada real, me costó $12 y funcionó durante 28 minutos antes de que lo matara. El agente no estaba roto. Hizo exactamente lo que le dije: seguir adelante hasta que la tarea esté "completa". El problema era que nunca definí "completa" de una forma que una máquina pudiera verificar. Así que siguió generando, siguió refinando, siguió quemando tokens — estando de acuerdo consigo mismo en repetición mientras mi billetera se vaciaba silenciosamente. Esa única mala ejecución me enseñó más sobre loop engineering que cualquier tutorial.
Este es el cambio que está ocurriendo ahora mismo, y la mayoría de los constructores aún no se han puesto al día. La habilidad que importa en 2026 no es escribir un prompt inteligente. Es escribir el bucle que instruye al modelo por ti — y saber exactamente cómo ese bucle decide que ha terminado. Boris Cherny, el creador y líder de Claude Code en Anthropic, lo dijo sin rodeos en el escenario de Acquired Unplugged el 2 de junio de 2026: "Ya no hago prompts a Claude. Tengo bucles ejecutándose que hacen prompts a Claude y descubren qué hacer. Mi trabajo es escribir bucles."
Eso no es una frase descartable. Es una descripción de puesto que cambia en tiempo real.
Una nota rápida antes de profundizar, porque dos cosas comparten la misma palabra. Si quieres la revisión práctica de lo-que-se-rompió del skill que productiza la construcción de bucles, lo cubrí por separado en mi análisis de el skill Launch Your Agent de Anthropic y la ejecución descontrolada del agente que produjo. Ese post es una reseña de herramienta. Este trata sobre la ingeniería debajo — la disciplina de diseñar el bucle en sí, sin importar en qué herramienta lo viertas. Los dos son adyacentes, no iguales. Lee este para el por qué y la forma; lee ese para el cómo se sintió ejecutarlo.
Al final de esto, podrás diseñar un bucle con una condición de parada real y verificable — y, igual de importante, sabrás cuándo un bucle es la herramienta equivocada por completo. Esa segunda parte es donde la mayoría de la gente se quema.
¿Qué es loop engineering?
Loop engineering es la práctica de diseñar el trigger, la acción y la condición de parada de un bucle de agente autónomo para que pueda ejecutarse, verificar su propio trabajo y detenerse según criterios objetivos — en lugar de depender de un único prompt escrito por humanos. Trata al bucle, no al prompt, como la unidad de trabajo.
Piensa en cómo has estado usando agentes de codificación con IA. Escribes un prompt. Lees la salida. Escribes otro prompt. Tú eres el bucle. Tus ojos son el paso de verificación, tu juicio es la condición de parada, y tus dedos son lo que re-activa la siguiente iteración. Loop engineering mueve los tres de tu cabeza al código.
Cherny describió su propia evolución en tres etapas, y se mapea perfectamente a lo que la mayoría de los constructores serios están viviendo. Hace aproximadamente un año, escribía código a mano con autocompletado ayudando en los márgenes. Luego pasó a ejecutar de cinco a diez sesiones de Claude en paralelo, haciendo prompts manualmente a cada una — cambiando pestañas como un cocinero de comida rápida. Ahora escribe bucles que hacen prompts a Claude por él; un par de cientos de agentes leen su GitHub, su Slack y su Twitter, y deciden qué construir después. El humano pasó de escribir código, a escribir prompts, a escribir la maquinaria que escribe prompts.
El término en sí se cristalizó a principios de junio de 2026 — "escribe bucles, no prompts" — y una vez que internalizas el marco, no puedes dejar de verlo. Peter Steinberger, quien construyó OpenClaw (el nuevo repositorio con más estrellas en la historia de GitHub), lo publicó aún más claramente el 7 de junio de 2026: "Ya no deberías estar haciendo prompts a agentes de codificación."
Afirmación fuerte. Mayormente correcta. Pero "mayormente" carga peso, y llegaremos a donde se rompe.
El ciclo razonar → actuar → observar → evaluar
Cada bucle de agente, despojado hasta los huesos, es el mismo ritmo de cuatro tiempos repitiéndose. Los nombres varían — algunos dicen Percibir/Decidir/Actuar/Observar, algunos dicen Observar/Pensar/Actuar/Verificar — pero la música es idéntica. Yo lo pienso como: razonar → actuar → observar → evaluar la condición de parada, y luego volver al inicio.
Razonar: el agente mira el estado actual y decide qué hacer a continuación. Actuar: realiza una operación — escribe un archivo, ejecuta un comando, llama a una API. Observar: captura lo que cambió — la salida del comando, el error, el nuevo contenido del archivo, la captura de pantalla. Evaluar: verifica esa observación contra la condición de parada. ¿Terminado? Salir. ¿No terminado? Razonar de nuevo con la nueva información en mano.
Las guerras de nomenclatura no importan. Lo que importa es el cuarto tiempo. La mayoría de los bucles fallidos que he visto — incluyendo mi desastre de $12 — tienen un ciclo fuerte de razonar-actuar-observar y un paso de evaluación falso. El agente observa su propia salida y se pregunta: "¿Suficientemente bueno?" Y por supuesto dice que sí, porque está calificando su propia tarea sin rúbrica. Un bucle sin nada que empuje de vuelta es solo el agente estando de acuerdo consigo mismo en repetición.
Todo el juego consiste en hacer real ese cuarto tiempo.
Por eso ahora diseño bucles al revés. Antes de escribir el trigger, antes de escribir una sola acción, escribo la condición de parada y hago una pregunta: ¿qué cosa concreta en el mundo me dirá que esto está hecho, que el agente no pueda falsificar? Un test que pasa. Un verificador de tipos que se pone en verde. Un pipeline de CI que pasa de rojo a verde. Un HTTP 200 de un endpoint que hace un minuto era 500. Si no puedo nombrar esa cosa, no construyo el bucle todavía. El bucle no está listo — la definición no está lista.
Así que desglosemos bien la anatomía, porque cada una de las tres partes tiene sus propios modos de fallo.
Trigger, acción, condición de parada: la anatomía de un bucle de agente
Un bucle tiene exactamente tres partes que soportan carga. Falla en cualquiera de ellas y todo el conjunto se tambalea.
El trigger es lo que inicia el bucle. Puede ser un comando humano ("refactoriza este módulo"), un horario (cada quince minutos), un evento (un nuevo issue en GitHub, un mensaje en Slack, un test fallido en CI), u otro agente pasando trabajo. La configuración de Cherny con un par de cientos de agentes se activa por su propia actividad — sus commits, sus mensajes, sus posts se convierten en señales que los agentes recogen y sobre las que actúan. El trigger responde: ¿cuándo tiene este bucle el derecho de existir y empezar a gastar tokens?
La acción es el conjunto de operaciones que el agente tiene permitido realizar dentro de cada iteración. Aquí es donde dibujas el radio de explosión. Una acción podría ser "editar archivos en este directorio y ejecutar la suite de tests." Podría ser "generar una imagen y guardarla." Cuanto más ajustado y específico sea el espacio de acción, más predecible será el bucle. Cuanto más vago — "haz lo que sea necesario" — más creativo, y más peligroso. La mayoría de los desbocamientos que queman tokens que he visto vienen de un espacio de acción que era demasiado amplio para la capacidad de la condición de parada de detectar un giro equivocado.
La condición de parada es la puerta de verificación — los criterios objetivos para "terminado." Esta es la parte que todos subconstruyen. Tiene que ser algo externo a la propia opinión del agente. Matthew Berman, quien lanzó la Loop Library el 18 de junio de 2026, enmarca la verificación claramente: puede ser "un test unitario que pasa, un pipeline CI en verde, o un LLM diciendo 'sí, eso está completo.'" Nota el orden de confianza ahí. Un test unitario es un hecho. Un pipeline verde es un hecho. Un LLM juzgando completitud es una opinión — útil, pero la más débil de las tres, y la más propensa a sellar mediocridad.
Aquí está la ilustración de diseño que mantengo en mi cabeza. Supongamos que quiero un bucle que arregle tests fallidos en un repositorio. Trigger: una ejecución programada, o un push que pone CI en rojo. Acción: leer el test fallido, editar el código fuente, re-ejecutar la suite — y solo esas operaciones. Condición de parada: toda la suite pasa, punto. Esa última cláusula es todo el punto. El bucle no puede declarar victoria diciéndose a sí mismo que el código se ve correcto. Declara victoria cuando npm test termina con código cero. El test es la cosa en el bucle que puede decir no. Sin algo que pueda decir no, no tienes un bucle — tienes un costoso adulador.
Esa distinción — entre una condición de parada que es un hecho y una que es una opinión — resulta ser todo el juego. Lo que me lleva a la parte de la que nadie habla lo suficiente.
Por qué la fidelidad de verificación hace o destruye un bucle
No todas las condiciones de parada son iguales, y la brecha entre una buena y una mala es el mayor predictor de si un bucle produce algo útil o algo que simplemente parece terminado.
Yo llamo a esto fidelidad de verificación: qué tan fielmente tu condición de parada mide lo que realmente te importa. Alta fidelidad significa que la puerta verifica el objetivo real. Baja fidelidad significa que la puerta verifica un proxy que es fácil de satisfacer y fácil de engañar.
La Loop Library de Berman es una mina de oro para ver esto en acción, y quiero ser preciso aquí — estos son bucles que él y sus colaboradores construyeron y probaron en batalla, no los que yo personalmente ejecuté. Pero ilustran el problema de fidelidad mejor que cualquier cosa que yo pudiera construir.
Toma su bucle de creación de miniaturas. La configuración: genera diez miniaturas, puntúalas contra miniaturas de referencia estilo MrBeast, itera sobre las tres mejores. Aproximadamente 27 minutos por ejecución. El trigger y la acción son nítidos. ¿Pero la condición de parada? "Puntúalas contra miniaturas de MrBeast." Eso es subjetivo. No hay npm test para "¿es esta miniatura convincente?" La verificación es un LLM mirando una imagen y formando una opinión estética, y las opiniones estéticas son blandas. El bucle ejecuta, produce miniaturas, pero la definición de "terminado" es suave — lo que significa que el bucle puede converger en algo que el modelo piensa que es bueno mientras un creador humano podría estar en total desacuerdo. Baja fidelidad no es un bug en el código. Es un bug en lo que significa "terminado".
Ahora mira su bucle de three.js — construir un avión 3D con three.js, alrededor de 37 minutos, con verificación visual iterativa renderizando en un navegador. Mayor fidelidad que las miniaturas, porque el agente puede realmente renderizar la escena y mirarla en cada iteración. Pero aún así no logró completamente la transparencia de visión a través. La verificación podía confirmar "existe un avión y renderiza," pero "la transparencia se ve bien" fue más difícil de anclar a una verificación objetiva. El bucle se acercó. Cerca no es terminado.
Luego está la recreación de Abbey Road de los Beatles en HTML/CSS — limitada a ocho intentos, aproximadamente siete iteraciones realmente ejecutadas, verificada por comparación de capturas de pantalla. Mejoró incrementalmente en cada pasada y terminó lejos de perfecto. Y honestamente, ese ejemplo es el más instructivo de los tres, porque muestra el límite del bucle tan claramente. La verificación por captura de pantalla tiene fidelidad media: puede detectar "el diseño está ampliamente mal" pero lucha con "este gradiente específico está ligeramente desviado." El límite duro de ocho intentos es el héroe no reconocido aquí — es una condición de parada secundaria que previene una persecución infinita e insatisfacible. Cuando tu verificación primaria es difusa, un límite duro de iteraciones es lo que evita que el bucle se convierta en mi desastre de $12.
La lección se acumula limpiamente. Las condiciones de parada objetivas (un test que pasa, un código de salida, un estado HTTP) producen bucles en los que puedes confiar para ejecutar sin supervisión. Las condiciones de parada subjetivas (¿se ve bien esto?, ¿es esto convincente?) producen bucles que necesitan un humano al volante, o como mínimo un límite duro de intentos para que fallen rápido en lugar de fallar caro.
Si quieres una regla de toda esta sección: ajusta la autonomía del bucle a su fidelidad de verificación. ¿Puerta de alta fidelidad? Déjalo ejecutar. ¿Puerta de baja fidelidad? Limita los intentos y mantén la mano en el interruptor de emergencia.
Hasta ahora hemos hablado de un agente en un bucle. Pero los patrones más poderosos — y los que Cherny está ejecutando realmente — involucran agentes controlándose entre sí.
Maker-checker y flotas anidadas: escalando más allá de un solo bucle
Un solo agente haciendo razonar-actuar-observar-evaluar funciona bien para tareas acotadas. La arquitectura interesante comienza cuando separas el hacer del verificar — y cuando los bucles empiezan a generar bucles.
El patrón maker-checker es la mejora más limpia que puedes hacer a un bucle de baja fidelidad. En lugar de un agente que tanto produce el trabajo como juzga si está terminado (el problema de calificar tu propia tarea), divides los roles. Un agente hace — escribe el código, genera el diseño, redacta la copia. Un segundo agente separado verifica — lo puntúa, lo califica contra criterios, busca la falla. El trabajo completo del verificador es encontrar razones para decir no. Porque no produjo el trabajo, no tiene ego invertido en llamarlo terminado. Esa separación es lo que le da al bucle un verdadero adversario, y un bucle con un verdadero adversario es un bucle que realmente puede converger en calidad.
Me apoyo en esto constantemente ahora. Cuando una condición de parada tiene que ser subjetiva — digamos, "¿está limpio este diseño de API?" — no le pido al creador que se autoevalúe. Inicio un segundo agente con una rúbrica afilada y un mandato de ser duro. La calidad de salida salta, porque ahora hay algo en el bucle construido para empujar de vuelta.
Luego están las flotas anidadas — gerentes dirigiendo sub-agentes, bucles orquestando bucles. Esto es lo que "un par de cientos de agentes leyendo mi GitHub y Slack y decidiendo qué construir" de Cherny realmente es. Un bucle de nivel superior observa su actividad y razona sobre prioridades. Despacha sub-bucles para manejar construcciones específicas. Cada sub-bucle tiene su propio trigger, espacio de acción y condición de parada, y reporta de vuelta. La condición de parada del bucle gerente no es "¿escribí código?" — es "¿mi flota entregó las cosas correctas?" Son bucles hasta el final, con puertas de verificación en cada capa.
Si estás tratando de arquitecturar algo a esta escala, los patrones de orquestación merecen su propio tratamiento profundo — describí cómo estructurar gerentes, sub-agentes y el paso de mensajes entre ellos en mi análisis de la arquitectura de enjambre de agentes Claude Code. La versión corta: las flotas anidadas multiplican tanto tu throughput como tu superficie de fallo. Cada capa que carece de una condición de parada real es una capa donde la mediocridad puede entrar y propagarse hacia arriba sin ser notada.
Y el arnés debajo de todo esto importa más que los agentes mismos. La forma en que Anthropic diseña su arnés de agente de larga duración — cómo el estado persiste a través de iteraciones, cómo se gestiona el contexto para que el bucle no se ahogue en su propia historia — formó fundamentalmente cómo pienso sobre la durabilidad de bucles; lo desempaqué en mi artículo sobre el diseño del arnés de agente de Anthropic. Un bucle es tan bueno como el arnés en el que ejecuta.
Si estás asintiendo pensando "genial, voy a poner bucles a todo" — para. Este es exactamente el punto donde tengo que frenar, porque la habilidad más importante de loop engineering es saber cuándo no construir uno.
Cuándo NO escribir un bucle
Aquí están los datos incómodos que la multitud de "deja de hacer prompts, empieza a hacer bucles" tiende a saltarse. Una encuesta de 2025 de 306 profesionales encontró que el 68% de los agentes en producción ejecutan diez pasos o menos antes de que un humano intervenga. Lee eso de nuevo. Los sistemas de agentes que realmente funcionan en producción no son enjambres autónomos de doscientos. Son pequeños. Son supervisados. Ejecutan un puñado de pasos y luego un humano toma el volante.
Eso no es un fallo de la tecnología. Es la tecnología siendo usada por personas que aprendieron por las malas dónde se rompen los bucles.
El modo de fallo tiene un nombre ahora: agent slop. Es lo que obtienes cuando automatizas más allá del punto donde todavía puedes responder por la salida. El bucle sigue produciendo, el volumen sigue subiendo, y la calidad se degrada silenciosamente porque nada en el sistema fue construido para detectar la deriva. Terminas con mil commits en los que no puedes confiar y que no leíste. Slop no es código malo — es código irresponsable, generado más rápido de lo que cualquier humano puede verificar.
Así que aquí está mi lista honesta de cuándo saltarse el bucle por completo:
Sáltatelo si eres un constructor independiente en un plan de consumidor. Los bucles gastan tokens en cada iteración, y un bucle desbocado en un plan medido es una factura real. (Pregúntame cómo lo sé — $12 en 28 minutos, y ese fue uno pequeño.) Si eres sensible al costo, las matemáticas de los bucles autónomos se ponen feas rápido. Desglosé la economía completa de tokens en mi guía de optimización de costos de agentes IA, y el titular es simple: sin una puerta dura, los bucles fallan silenciosamente y siguen gastando. Fallo silencioso más facturación medida es la peor combinación en todo este campo.
Sáltatelo si tu código no tiene verificación automatizada. ¿Sin tests, sin verificador de tipos, sin CI? Entonces tu única condición de parada posible es la opinión de un LLM — la puerta de menor fidelidad que existe. No tienes un bucle; tienes una forma cara de generar diffs que parecen plausibles. Construye los tests primero. La infraestructura de verificación es la infraestructura del bucle. Un bucle sin una puerta dura que empuje de vuelta es el agente estando de acuerdo consigo mismo en repetición, y eso es precisamente la máquina de slop.
Sáltatelo si tu verdadero cuello de botella es la capacidad de revisión, no la velocidad de escritura. Este es sutil y atrapa a buenos ingenieros. Los bucles hacen la producción más rápida. No hacen nada por la revisión. Si ya te estás ahogando en PRs que no puedes revisar lo suficientemente rápido, agregar un bucle que genera diez veces más código no ayuda — te entierra. La restricción simplemente se movió. Optimizaste la parte que no era el problema. Antes de construir un bucle, pregúntate honestamente: ¿es escribir mi cuello de botella, o es responder por el código mi cuello de botella? Si es responder, un bucle empeora las cosas.
El principio unificador: un bucle es tan confiable como la cosa dentro de él que puede decir no. Sin test, sin verificación de tipos, sin error real al cual reaccionar — sin bucle. Solo un agente asintiendo consigo mismo mientras el medidor corre.
Qué cambia esto realmente en tu trabajo
Entonces, ¿dónde te deja esto prácticamente, esta semana?
La lectura honesta del movimiento "escribe bucles, no prompts" es que es direccionalmente correcto y tácticamente exagerado. El futuro genuinamente son bucles — Cherny no está equivocado en que su trabajo ahora es escribir la maquinaria, no los prompts. Pero el número del 68% es el chequeo de realidad: los bucles que sobreviven al contacto con producción son pequeños, controlados y supervisados. El sueño de una flota de doscientos agentes ejecutándose sin supervisión es real para las personas que han construido verificación a prueba de balas alrededor de cada capa. Para todos los demás, es un generador de slop con tarjeta de crédito.
Lo que realmente haría, empezando hoy: toma una tarea repetitiva que haces con un agente de IA — la que donde sigues escribiendo el mismo tipo de prompt una y otra vez. Escribe primero su condición de parada, antes que cualquier otra cosa. Hazla un hecho, no una opinión: un test, un código de salida, un chequeo de estado. Si no puedes nombrar ese hecho, acabas de descubrir que la tarea no está lista para bucle, y te has ahorrado una lección de $12. Si puedes nombrarlo, ya tienes construida la parte más difícil del bucle. El trigger y la acción son la mitad fácil.
El modelo mental que quiero que te lleves es lo suficientemente pequeño para caber en una nota adhesiva: un bucle es una máquina para repetir razonar-actuar-observar hasta que una cosa que puede decir no diga sí. Diseña esa "cosa que puede decir no" primero. Todo lo demás es fontanería.
Ese bucle desbocado que me costó $12 no fue un fallo del agente. Fue un fallo de definición — construí la fontanería antes de construir la puerta. Construye la puerta primero. Entonces puedes dejar el bucle ejecutar, y realmente confiar en lo que te entrega cuando se detiene.
Preguntas frecuentes
¿Qué es loop engineering?
Loop engineering es la disciplina de diseñar el trigger, la acción y la condición de parada de un agente autónomo para que pueda ejecutarse, verificar su propia salida y detenerse según criterios objetivos — en lugar de depender de un único prompt escrito por humanos. La unidad de trabajo se desplaza del prompt al bucle mismo. Para la anatomía completa, consulta la sección de trigger/acción/condición de parada arriba.
¿Es loop engineering lo mismo que prompt engineering?
No. Prompt engineering optimiza una única instrucción que le das al modelo; loop engineering optimiza la maquinaria que hace prompts al modelo repetidamente y decide cuándo el trabajo está terminado. Como dijo Boris Cherny: "Mi trabajo es escribir bucles" — el prompt se convierte en un detalle interno del bucle, no en la cosa que elaboras a mano.
¿Cuándo no deberías usar un bucle de agente?
Sáltate un bucle de agente si eres un constructor independiente en un plan de consumidor (los costos de tokens se acumulan en cada iteración), si tu código no tiene verificación automatizada (tests, tipos, CI) para servir como condición de parada objetiva, o si tu verdadero cuello de botella es la capacidad de revisión en lugar de la velocidad de escritura. Una encuesta de 2025 de 306 profesionales encontró que el 68% de los agentes en producción ejecutan diez pasos o menos antes de que un humano intervenga — pequeño y supervisado le gana a autónomo e irresponsable.
¿Qué es el patrón maker-checker en agentes de IA?
El patrón maker-checker divide un bucle de agente en dos roles: un agente produce el trabajo y un agente separado lo califica contra criterios. Como el verificador no creó la salida, no tiene incentivo para sellarla — dándole al bucle un verdadero adversario que puede empujar de vuelta. Es la solución más limpia para bucles cuya condición de parada sería de otro modo subjetiva.
¿Qué hace confiable la condición de parada de un bucle de agente?
Fidelidad de verificación. Una puerta objetiva — un test unitario que pasa, un pipeline CI en verde, un HTTP 200 — es un hecho que el agente no puede falsificar, así que el bucle puede ejecutar sin supervisión. Una puerta subjetiva, como un LLM juzgando si una imagen "se ve bien," es una opinión fácil de engañar, así que necesita un humano al volante o un límite duro de intentos. Ajusta la autonomía del bucle a qué tan fielmente su puerta mide el objetivo real.
Trabajemos juntos
¿Busca construir sistemas de IA, automatizar flujos de trabajo o escalar su infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (desarrollo personalizado e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y marca): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
