Agent loops: ¿Cómo montar un sistema de agentes autónomos?

Te levantas, coges el café y abres GitHub. Hay once pull requests nuevas.

Ninguna la has abierto tú.

No es que hayas currado hasta las tres de la mañana. Es que mientras dormías había cuatro loops distintos dando vueltas: uno cazando fallos de CI, otro puliendo tests frágiles, otro revisando dependencias y uno más redactando documentación que se había quedado desfasada. Cada uno encontró su trabajo, lo hizo, lo verificó y dejó la PR lista para que tú decidas si entra.

Esto ya no es ciencia ficción de conferencia. Es lo que Peter Steinberger, creador de OpenClaw y ahora en OpenAI, resumió en su famoso “recordatorio mensual”: no deberías estar prompteando a tus agentes, deberías estar diseñando los loops que los promptean por ti.

Boris Cherny, responsable de Claude Code en Anthropic, dijo casi lo mismo unos días antes desde un escenario: su trabajo ya no es promptar a Claude, es escribir los loops que lo hacen.

Hasta aquí, la teoría. Y la teoría ya la desmenucé en qué es el loop engineering y en qué se diferencia del harness: qué es un loop, su anatomía, las seis piezas y por qué la condición de parada pesa más que el bucle. Si ese post no lo has leído, léelo primero, porque este da por hecho que ya sabes montar uno.

Porque hoy no va de montar un loop.

Va de qué pasa cuando tienes cinco.

Esto es lo que vas a encontrar:

• Por qué pasar de un loop a un sistema de loops cambia el problema por completo
• El tablero como sala de control: cómo ver y dirigir lo que hacen tus agentes sin promptarlos
• El patrón manager/worker: separar el que reparte del que ejecuta
• Loops que se retroalimentan: el cerebro compartido que hace que el sistema componga
• Los guardarraíles que la demo nunca te enseña
• Cómo saber si todo esto de verdad funciona (y no solo quema tokens)

Un loop es un bucle; varios loops son una organización ¶

Un loop suelto es fácil de entender. Un trigger lo despierta, el agente mira el estado del mundo, hace algo, lo verifica y decide si sigue, para o te devuelve el marrón. Es un while con criterio, y ya te conté por qué ese criterio es lo difícil.

Pero cuando montas el segundo loop, y el tercero, aparece un problema nuevo que no tenías con uno solo: la coordinación.

¿Quién decide en qué trabaja cada uno? ¿Qué pasa si dos agentes tocan el mismo archivo a la vez? ¿Cómo se entera el loop de SEO de que el loop de soporte ha detectado una fricción que da pistas sobre qué contenido falta? ¿Y cómo evitas que la factura de tokens se convierta en una hipoteca?

Con un loop eres un desarrollador con un ayudante muy rápido. Con cinco, eres el tech lead de un equipo que trabaja en paralelo, no duerme y no pide vacaciones.

El harness —el entorno que envuelve a cada agente con sus herramientas y permisos— ya lo tienes montado. El reto ahora es otro: diseñar la organización. Los roles, el tablero, las reglas de convivencia y hasta dónde llega la autonomía de cada uno, que es la misma conversación de cómo hacer bien vibe coding pero multiplicada por cinco.

Ese salto es el que casi nadie te cuenta. La demo siempre es un agente, una tarea, un problema elegido a dedo que dura noventa segundos mientras alguien aplaude. La realidad de producción es una flota de agentes reintentando, pisándose y gastando dinero. Alguien tiene que poner orden.

Ese alguien eres tú, pero no promptando. Diseñando el sistema.

🔑 Un loop resuelve una tarea. Un sistema de loops resuelve el problema de decidir qué tareas se hacen, en qué orden, con qué permisos y quién comprueba que estén bien. Eso segundo es ingeniería de verdad; lo primero es un viernes por la tarde.

Curso gratis · paso a paso

Tus loops rinden lo que valen las specs que les das

Un sistema de agentes solo suma lo que sobrevive sin reescribir, y eso empieza por especificar bien cada tarea. En este curso recorres un ciclo completo de Spec Driven Development con OpenSpec sobre un proyecto real y en modo asistido: el método que convierte un ticket vago en trabajo que un agente sí puede cerrar.

Entra en el curso gratis →

El tablero es tu sala de control ¶

Aquí está la primera pieza que cambia todo cuando pasas a plural: necesitas ver lo que hacen tus agentes.

Cuando un agente ejecuta a solas, a las tres de la mañana, sin nadie mirando, la peor decisión posible es dejarlo sin ventana. Un sistema autónomo que trabaja a ciegas y del que no puedes inspeccionar nada es, sencillamente, peligroso.

Necesitas una superficie donde el estado del mundo sea visible de un vistazo: qué está en marcha, qué está en revisión, qué se ha terminado y qué se ha atascado esperándote.

A esa superficie la llamo la sala de control. Y lo bonito es que no tienes que construirla: ya la tienes.

Un tablero de GitHub Issues sirve. Un tablero de Linear sirve. Cualquier sitio donde una tarea tenga un estado, pueda cambiar de columna y admita comentarios.

Los agentes mueven los tickets de “en progreso” a “en revisión” a “hecho”, y en cada ticket dejan un comentario con lo que hicieron: qué tests ejecutaron, qué salida obtuvieron, qué PR abrieron. Igual que le pides a un desarrollador humano que adjunte evidencia en el ticket para que el revisor no tenga que fiarse de su palabra, se lo pides al agente.

La diferencia con la memoria de un loop suelto es de propósito. En el pilar hablé del estado como el fichero que evita la amnesia entre vueltas. La sala de control es otra cosa: es el estado hecho visible para ti, para que puedas dirigir sin escribir un solo prompt. Editas el tablero, no la conversación.

💡 Tú no dejas de estar en el sistema. Cambias de sitio. Antes estabas dentro del bucle pulsando “enter” cada turno. Ahora estás fuera, mirando el tablero y moviendo prioridades. Sigues pilotando, pero desde la torre de control, no desde la pista.

¿Cómo diriges desde ahí? Con etiquetas y estados. Marcas un ticket como “necesita revisión humana” y ningún agente lo tocará. Lo marcas como “listo para agente” y entrará en la cola de trabajo la próxima vuelta. Ese lenguaje de etiquetas es el protocolo entre tú y tu flota. Y es justo lo que hace posible el siguiente patrón.

El patrón manager y worker: separa el que reparte del que ejecuta ¶

El montaje más útil para empezar a pensar en plural son dos loops que se pasan el testigo. Uno reparte, otro ejecuta. Esta es la forma que tiene el sistema entero:

   ┌──────────────┐   etiqueta   ┌────────────────────────────┐
   │ MANAGER LOOP │─────────────▶│ TABLERO (sala de control)  │
   │  reparte     │              │  riesgo · tipo · estado    │
   └──────────────┘              └─────────────┬──────────────┘
                                               │ lee "listo p/ agente"
      TÚ mueves prioridades                    │ + riesgo bajo
      sobre el tablero  ↑↓                     ▼
                                       ┌──────────────┐
                                       │ WORKER LOOP  │
                                       │  ejecuta     │
                                       └──────┬───────┘
                                              ▼
           escribir → subagente revisa → abrir PR + evidencia

El manager loop hace de tech lead. Se dispara una vez al día (o cada vez que aparece un ticket nuevo) y su único trabajo es mantener el tablero limpio:

1. Lee todas las issues abiertas y las clasifica por tipo: bug, documentación, refactor, feature.
2. Les asigna un nivel de riesgo: alto o bajo.
3. Decide cuáles son aptas para un agente y cuáles necesitan criterio humano.
4. Revisa el código base y, si encuentra un bug o un desajuste con la documentación, abre él mismo un ticket.

Fíjate en lo que no hace: no escribe una sola línea de código de producción. Solo ordena el tablero. Ese límite es deliberado, y lo retomo cuando hablemos de guardarraíles.

El worker loop hace de ejecutor. Se despierta, pregunta al tablero “¿hay algo etiquetado como listo para agente y de riesgo bajo?”, coge esos tickets y ejecuta un pipeline interno por cada uno:

leer ticket → escribir código → subagente que revisa el diff →
checks adicionales → abrir PR → mover ticket a "en revisión" → comentar evidencia

La parte interesante es la tercera flecha. El worker no aprueba su propio trabajo: levanta un subagente distinto, en modo solo lectura, para que revise el diff contra las skills del proyecto y los tests existentes.

El que escribe no es el que revisa. Esa separación es la misma idea que sostiene cualquier condición de parada fiable, y la desarrollé en la guía de testing con IA.

Aquí las etiquetas del tablero dejan de ser decoración y se convierten en el cableado que conecta los dos loops. El manager escribe “listo para agente”; el worker lee “listo para agente”.

Tú, desde la sala de control, puedes intervenir en cualquier punto: subir una tarea a “necesita revisión humana” si te huele mal, o bajarla a “listo para agente” cuando le des el visto bueno.

Un apunte de implementación que ahorra sustos: no dejes que el worker trabaje varios tickets en paralelo el primer día. Van a chocar entre ellos, y muchas tareas tienen dependencias lógicas de todos modos.

Empieza secuencial, con un tope de tres tickets por ejecución, y ya subirás cuando confíes en el sistema. Ese aislamiento en paralelo, cuando llegue el momento, lo resuelven los worktrees, que ya estaban en la lista de las seis piezas del loop.

Loops que se retroalimentan: el cerebro compartido ¶

Dos loops que se pasan tickets ya es potente. Pero el salto de nivel llega cuando los loops comparten un cerebro y empiezan a componer entre ellos.

Te lo explico con un ejemplo que no es de programación pura, porque es donde la idea brilla más.

Imagina que además del sistema técnico tienes un loop de soporte que cada media hora revisa los tickets de atención al cliente, responde los que puede y anota las fricciones que detecta. En una vuelta se da cuenta de que tres personas distintas han preguntado cómo exportar sus datos.

En vez de resolver solo ese ticket y olvidarlo, el loop escribe una señal: un fichero Markdown que dice “hay fricción con la exportación de ficheros”, con enlaces a los casos concretos. Y lo deja en una carpeta compartida.

Ahora imagina un segundo loop, el de contenidos, que cada mañana analiza qué temas cubrir. Antes de decidir, lee esa carpeta de señales. Ve la de exportación. Y prioriza escribir la guía que a la gente le hace falta, porque otro loop, de otro departamento, le ha dejado la pista.

Eso es composición. Cada loop lee y escribe sobre el mismo sistema de ficheros:

   loop soporte     loop anuncios     loop contenidos
       │                 │                 ▲
       │ escribe         │ escribe         │ lee y prioriza
       ▼                 ▼                 │
   ┌─────────────────────────────────────────────┐
   │   CARPETA DE SEÑALES (cerebro compartido)    │
   │   todos leen y escriben aquí                 │
   │   · fricción al exportar         ← soporte   │
   │   · keyword sin contenido        ← anuncios  │
   └─────────────────────────────────────────────┘

Una señal que encuentra el loop de soporte alimenta al de contenidos. Un dato que descubre un loop de anuncios —“esta palabra clave tiene clics pero no tenemos contenido orgánico”— vuelve al loop de contenidos como prioridad. Todos comparten el mismo cerebro, así que el valor no se suma: se multiplica.

La arquitectura que sostiene esto es más aburrida de lo que suena, y esa es su virtud. Defines unos pocos tipos de artefacto —señales, tareas, tickets, documentos— y para cada uno una carpeta con un README que explica qué entra, qué no entra y con qué esquema.

Cada elemento es un Markdown con su cabecera de metadatos y su cuerpo, con la misma lógica de estado en disco que usas en el AGENTS.md de un solo agente. Nada de bases de datos exóticas el primer día.

🛡️ El agente olvida entre ejecuciones; el disco no. Si tus loops no escriben lo que aprenden en un sitio que otro loop pueda leer mañana, no tienes un sistema: tienes cinco ermitaños que reinician de cero cada vuelta.

Esta idea de sesión nueva cada vez con continuidad en disco es la que vertebra el ralph-loop que el Santander AI Lab publicó en GitHub, y la versión más radical del concepto —el agente que experimenta, mide y decide sin humano de por medio— la tienes en Karpathy y Auto Research.

El patrón se repite porque funciona: el estado vive fuera del modelo, y cualquier loop puede consultarlo.

De orquestar loops a construir agentes

La arquitectura que sostiene una flota de agentes

Orquestar varios loops pide más que buenos prompts: pide arquitectura. Aquí verás los seis niveles de un sistema multiagéntico —tools, guardarraíles, memoria, skills, MCP y orquestación— con código real, Mastra y Open Code, más evals con LLM as Judge para que la flota no se descontrole.

Ver la arquitectura entera →

Masterclass Web Reactiva Premium · 6 niveles de arquitectura en directo

Los guardarraíles que la demo nunca te enseña ¶

Todo lo anterior es una palanca preciosa. Sin frenos, es una forma elegante de mandar dinero a los laboratorios de IA y meter código roto en tu repo a toda velocidad.

Cuando construyes sistemas autónomos, la mayor parte del diseño no está en lo que los agentes pueden hacer, sino en lo que no pueden hacer. Los guardarraíles no son un extra que añades al final: son la razón por la que puedes irte a dormir tranquilo.

Estos son los que no deberían faltarte:

1. Mínimo privilegio por loop. El manager solo toca tickets, jamás empuja código. El worker solo trabaja tickets de riesgo bajo. Cada loop tiene los permisos justos para su función y ni uno más. Si el manager no puede desplegar, no va a desplegar por mucho que se líe.
2. Un tope por ejecución. Máximo tres tickets por vuelta, por ejemplo. Si hay un bug en el loop y de repente tienes cincuenta tickets, un agente trabajándolos todos te vacía la cartera. El límite es una característica, no una limitación.
3. Aborta si el entorno está sucio. Antes de empezar, el worker comprueba que la rama está limpia, sin cambios sin confirmar. Si algo no cuadra, se detiene. Prefieres un loop que no arranca a uno que pisa trabajo a medias.
4. Un segundo revisor que no sea el agente. Aunque el subagente ya haya revisado el diff, añade una verificación automática por encima: un linter estricto, un análisis de código, tus tests end-to-end de los flujos críticos. La condición de parada nunca depende de la opinión del que escribió el código.
5. Evidencia en el ticket, siempre. El agente adjunta la salida de los tests, un vídeo de la prueba en navegador, el diff. No para adornar: para que tú, en la revisión, confirmes que las cosas se ejecutaron de verdad y no son humo.

El cuarto punto merece que insistas, porque es el error más común y el más caro. El modelo que escribió el código es demasiado buena gente corrigiéndose a sí mismo: le preguntas “¿está bien?” y te dice que sí con una sonrisa.

Por eso la verificación en serio mezcla comprobaciones deterministas —que pasen los tests, que compile, que el navegador muestre lo que debe— con la revisión de otro modelo distinto.

Y hay un guardarraíl que no es técnico: dónde pones el límite de autonomía según lo que te juegas. Un loop que arregla un test frágil puede ir casi solo. Uno que toca el módulo de pagos, no.

Esa conversación sobre cuánta cuerda dar a cada tarea, la del vibe coding que enlazaba al principio, aplica igual cuando multiplicas loops: cuanto más subjetivo o arriesgado es el “está bien hecho”, más te toca pilotar a mano.

Prepara tu código para que los agentes trabajen solos ¶

Hay una pieza que se te olvida hasta que un loop se estrella contra ella: tu código base tiene que estar preparado para que un agente trabaje sin ti delante. Esto es territorio del harness que mencionaba antes, pero cuando montas varios loops se vuelve innegociable, así que lo aterrizo en tres propiedades concretas.

Legible. El agente tiene que saber dónde cambiar qué sin que tú se lo expliques cada vez. Un AGENTS.md en la raíz que apunte al resto de documentación es el punto de partida, escrito para que el agente lo respete de verdad.

El truco que marca la diferencia: mete tus reglas en un lint programático. Si no quieres que los agentes importen de una carpeta legacy, que salte un aviso automático cuando lo intenten, en vez de confiar en que lean la norma.

Ejecutable. El agente tiene que poder levantar el entorno de desarrollo con un solo comando, sin gastar tokens ni carga mental averiguando cómo. Un script tipo dev.local que arranque todo. Y, si vas a trabajar en paralelo, que el proyecto sea amigable con los worktrees, para que cinco agentes puedan levantar su entorno sin pisarse.

Verificable. El agente necesita herramientas para comprobar su propio trabajo y dejar constancia. Aquí las skills de tu proyecto que enlazaba antes son oro: encapsulan “cómo se hace esto aquí” y evitan reexplicar el proyecto en cada vuelta. Una skill de PR que liste los pasos obligatorios antes de abrir una pull request —incluido “levanta un verificador en solo lectura”— convierte tu criterio en proceso repetible.

Un código legible, ejecutable y verificable es útil aunque nunca montes un solo loop. Con loops, es la diferencia entre un sistema que trabaja solo y uno que te llama cada diez minutos.

Cómo saber si tu sistema de loops funciona ¶

Montas los loops, se ejecutan solos, abren PRs. Preciosa película. Pero, ¿lo están haciendo bien o solo rápido?

La respuesta la da una sola métrica: qué proporción de lo que produce el sistema sobrevive sin que la reescribas. Todo lo demás son detalles de esa cifra.

Un sistema autónomo sin forma de evaluarlo no es autónomo: es una apuesta. Así que antes de darle más cuerda, decide cómo vas a medirlo. Estas preguntas te sirven de termómetro:

• ¿Cuántos tickets cerró el agente a la primera, sin que tuvieras que devolverlos?
• ¿Cuánta ida y vuelta de feedback hizo falta antes de que la PR fuera aprobable?
• ¿Cuánto cuesta, en tokens, cada PR que de verdad acaba entrando?
• ¿Qué proporción de lo que produce el loop tienes que rehacer a mano?

Si el sistema abre veinte PRs pero tú reescribes quince, no has ganado velocidad: has movido el cuello de botella a la revisión. Si abre tres y las tres entran limpias, tienes algo que compone. La métrica que importa no es cuánto produce el loop, sino cuánto de lo que produce sobrevive sin tu intervención.

⚠️ Cuidado con el peligro psicológico, que es el más traicionero. Cuando el sistema se ejecuta solo, es tentador dejar de tener opinión y aceptar lo que devuelva. Dos personas montan el mismo sistema exacto: una lo usa para ir más rápido sobre trabajo que entiende a fondo; la otra, para no tener que entenderlo. El loop no nota la diferencia. Tú sí, y tu código base también.

Empieza por el sistema mínimo de dos loops ¶

No arranques con el organigrama completo de cinco loops que comparten cerebro y se conectan a producción. Eso es aprender a conducir en un Fórmula 1.

Monta el sistema mínimo que ya compone: dos loops y un tablero.

1. Pon el tablero primero. GitHub Issues o Linear. Sin sala de control, no tienes cómo dirigir ni cómo ver qué pasa. Es el cimiento, no un adorno.
2. Monta el manager loop. Que clasifique y etiquete los tickets: riesgo, tipo, apto para agente o no. Que no toque código. Míralo trabajar una vez entera antes de fiarte.
3. Monta el worker loop. Que coja solo los tickets de riesgo bajo aptos para agente, ejecute su pipeline interno con un subagente revisor y abra la PR con evidencia.
4. Ponle los frenos desde el minuto uno. Tope de tickets por ejecución, permisos mínimos, abortar si la rama está sucia, un revisor automático por encima del agente.
5. Añade el cerebro compartido cuando tenga sentido. Solo cuando tengas un tercer loop que se beneficie de leer lo que anota otro, monta la carpeta de señales. Antes es complejidad sin retorno.
6. Mide antes de escalar. Revisa la tasa de rehacer y el coste por PR aprobada durante una semana. Si compone, añade loops. Si no, arréglalo antes de multiplicarlo.

La regla de oro es la misma que con un loop suelto, solo que ahora en plural: la condición de parada se escribe primero, el presupuesto se pone antes de soltar, y la primera vuelta se mira. Un sistema que puede fracasar y avisarte es infinitamente mejor que uno que falla en silencio a escala.

Construye la fábrica, sigue siendo el ingeniero ¶

El salto de un loop a un sistema de loops no es magia ni es el fin de tu trabajo. Es, otra vez, un cambio en dónde está la palanca.

Con un loop, tu palanca es la condición de parada. Con un sistema, tu palanca es el diseño de la organización: quién reparte, quién ejecuta, quién revisa, qué pueden tocar y qué no, y cómo se pasan lo que aprenden. Dejas de ser el que pulsa “enter” y pasas a ser el que dibuja el circuito por el que circula todo.

Pero hay algo que no cambia, y conviene decirlo sin anestesia: la verificación sigue siendo tuya. Un sistema que se ejecuta sin supervisión es también un sistema que se equivoca sin supervisión, y más rápido, porque son varios a la vez.

Por eso separas al que hace del que revisa. Por eso pones evidencia en cada ticket. Por eso “hecho” es una afirmación del agente, no una demostración, hasta que tú la confirmas.

Once pull requests esperándote por la mañana suena a sueño cumplido. Y lo es, si las revisas como alguien que tiene intención de seguir siendo el ingeniero.

El futuro no es tener una flota de agentes que trabaja mientras miras a otro lado. Es diseñar la fábrica, ponerle los frenos buenos y saber exactamente cuándo te toca bajar a la pista y coger el volante.

Preguntas frecuentes ¶

¿Qué es un agent loop? ¶

Es un agente de IA ejecutándose en bucle: un trigger lo despierta, mira el estado del mundo, hace un trabajo, lo verifica y decide si sigue, para o escala. Cuando conectas varios de estos loops entre sí, con un tablero visible y un estado compartido, tienes un sistema de agentes autónomos que reparte, ejecuta y verifica trabajo sin que escribas cada prompt.

¿En qué se diferencia un sistema de loops de un solo loop? ¶

Un solo loop resuelve una tarea repetitiva y verificable. Un sistema de varios loops añade el problema de la coordinación: quién decide en qué trabaja cada uno, cómo evitan pisarse, cómo se pasan lo que aprenden y cómo controlas el gasto. El trabajo pasa de escribir un bucle a diseñar una organización con roles, tablero y límites.

¿Qué es el control plane o sala de control de los agentes? ¶

Es la superficie donde el estado de trabajo de tus agentes es visible y editable por ti: un tablero de GitHub Issues o Linear donde los tickets cambian de estado y los agentes comentan la evidencia de lo que hicieron. Te permite inspeccionar y dirigir el sistema editando el tablero, en lugar de promptar a cada agente.

¿Qué es el patrón manager y worker en loops de agentes? ¶

Son dos loops que se reparten el trabajo. El manager loop clasifica y etiqueta los tickets por riesgo y tipo, y decide cuáles son aptos para un agente, sin tocar código. El worker loop coge solo los tickets aptos y de riesgo bajo y ejecuta el pipeline de escribir, revisar con un subagente y abrir la pull request.

¿Cómo hago que varios loops se retroalimenten? ¶

Con un sistema de ficheros compartido donde cada loop lee y escribe. Cuando un loop detecta algo relevante, lo anota como una señal en una carpeta común; otros loops leen esa carpeta antes de decidir su siguiente acción. Así una fricción que encuentra un loop se convierte en prioridad para otro, y el valor del sistema se multiplica en vez de sumarse.

¿Qué guardarraíles necesita un sistema de agentes autónomos? ¶

Los imprescindibles son mínimo privilegio por loop, un tope de tareas por ejecución, abortar si el entorno está sucio, un revisor automático distinto del agente que escribió el código y evidencia obligatoria en cada ticket. Sin estos frenos, un sistema autónomo mete código roto y quema tokens a gran velocidad.

¿Por qué no debe el agente verificar su propio trabajo? ¶

Porque el modelo que escribió el código tiende a aprobarlo con demasiada facilidad. Levantar un subagente distinto, en solo lectura y con instrucciones propias, detecta lo que el primero se autoconvenció de que estaba bien. La condición de parada solo es fiable si el que verifica no es el que produjo el resultado.

¿Cómo preparo mi código base para que los agentes trabajen solos? ¶

Haciéndolo legible, ejecutable y verificable. Legible: un AGENTS.md y reglas de lint que avisen cuando el agente se desvía. Ejecutable: un script que levante el entorno con un comando y soporte worktrees. Verificable: skills del proyecto y una skill de PR que obligue a pasar por un verificador antes de abrir la pull request.

¿Cómo sé si mi sistema de loops funciona bien? ¶

Midiendo cuántos tickets cierra a la primera, cuánta ida y vuelta de feedback necesita, cuánto cuesta cada PR que acaba entrando y qué proporción tienes que rehacer a mano. La métrica que importa no es cuánto produce el sistema, sino cuánto de lo que produce sobrevive sin tu intervención.

¿Es peligroso dejar loops en marcha sin supervisión? ¶

Lo es si no pones frenos ni forma de verlos. Los riesgos principales son el gasto descontrolado de tokens, generar código malo más rápido de lo que puedes revisar y la deuda de comprensión: cuanto más código genera el sistema que tú no lees, más se separa lo que existe de lo que entiendes. La supervisión humana sobre la verificación sigue siendo innegociable.

Fuentes ¶

• Peter Steinberger (@steipete), “recordatorio mensual” sobre diseñar loops
• Addy Osmani, “Loop Engineering”
• Claude Code Docs, “Run prompts on a schedule” (/loop, /goal)
• OpenAI Developers, “Subagents – Codex”
• Firecrawl, “Loop Engineering: Should You Stop Prompting Agents and Start Designing 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