🔁 /loop — El intervalo de ejecución
O /loop es el bloque más básico de loop engineering. Funciona como un cron job para agentes de IA: defines un intervalo (cada 5 minutos, cada hora) y Claude Code se activa, verifica el estado del mundo, ejecuta lo que hace falta y vuelve a dormir. Sin interacción humana de por medio.
"Con slash loop, definimos un intervalo para ejecutar un prompt. Por ejemplo, cada cinco minutos revisaré si hay nuevos issues de GitHub en este repo y gestionaré los que aparezcan."
En portugués: "Con /loop, definimos un intervalo para ejecutar un prompt. Por ejemplo, cada cinco minutos voy a revisar si hay issues nuevas en GitHub en este repo y a encargarme de las que aparezcan."
📋 Anatomía de un /loop
Intervalo
Tiempo entre cada vez que el agente "despierta". Típicamente 5 minutos, 15 minutos, 1 hora.
Fuente externa de input
Issues de GitHub, un directorio de archivos, una API, una base de datos. El agente necesita «algo que mirar».
Prompt de acción
Qué hacer al despertar. "Revisa si hay issues nuevas. Si las hay, atiende la más antigua."
Terminal activo
El /loop depende de que el terminal de Claude Code esté en ejecución. Si lo cierras, el loop se detiene.
🎯 Punto de reflexión
El /loop es potente para tareas repetitivas y predecibles, pero tiene una limitación fundamental: todo se ejecuta en la misma sesión de Claude Code. Como señala Cole más adelante, "if you loop for a while, you're going to completely bloat your context for your LLM and overwhelm it." El /loop funciona bien para ciclos cortos. Para un trabajo prolongado, hace falta algo más.
🎯 /goal — El criterio de finalización
Mientras el /loop define "cuándo despertar", el /goal define «cuándo parar». Tú estableces criterios objetivos de finalización y el agente trabaja hasta alcanzarlos. No hay un intervalo fijo. El agente permanece activo hasta que se cumple la condición.
"Definimos algunos criterios, como cómo sabes que terminaste. Luego hacemos que el agente de programación trabaje hasta terminar, algo parecido a los Ralph loops que se hicieron virales hace unos meses."
En portugués: "Definimos criterios como 'así es como sabes que terminaste'. Y entonces obligamos al agente a trabajar hasta que esté listo, de forma parecida a los loops de Ralph que se hicieron virales."
Buenos criterios para /goal
- ✓"Todas las pruebas pasan"
- ✓"Cero issues abiertos en el repo"
- ✓"Todas las tareas de plan.md marcadas como done"
- ✓"La compilación termina sin errores"
Criterios riesgosos
- ✗"Que el código sea bueno" (demasiado subjetivo)
- ✗"Que todo funcione" (sin una métrica verificable)
- ✗"Que la app sea bonita" (imposible de evaluar)
- ✗Sin límite de iteraciones (loop infinito)
⚠️ El riesgo de /goal sin límites
Si el criterio de finalización está mal definido o es imposible de alcanzar, /goal se convierte en un loop infinito que consume tokens sin parar. Cole menciona que, para una app relativamente sencilla, gastó más de 1 millón de tokens. Define siempre un número máximo de iteraciones junto con /goal o usa timeouts como red de seguridad.
📅 /routines — Los trabajos programados
O /routines es el tercer bloque. A diferencia de /loop (intervalo corto, tarea repetitiva) y /goal (trabajar hasta terminar), /routines son jobs programados con un alcance amplio. Piensa en "cada hora, despierta, revisa el documento de especificaciones completo y atiende la siguiente tarea de la cola".
"Y por último, tenemos /routines. Son los jobs programados, como: cada hora, quiero que te despiertes, revises un documento de especificaciones más amplio y luego te encargues de la siguiente tarea."
En portugués: "Y por último tenemos /routines. Son los jobs programados. Por ejemplo: cada hora, quiero que te despiertes, revises un documento de especificaciones más amplio y te encargues de la siguiente tarea."
🔄 /routines vs. /loop: ¿cuál es la diferencia?
| Aspecto | /loop | /routines |
|---|---|---|
| Intervalo | Corto (minutos) | Largo (horas) |
| Alcance por ciclo | Tarea única y rápida | Tarea de una especificación más amplia |
| Entrada | Evento externo (issue, webhook) | Documento de Spec completo |
| Analogía | Cron job simple | Procesamiento batch programado |
🧩 Cómo se combinan los bloques
La fuerza de la ingeniería de loops no está en ningún bloque aislado. Está en la combinación de ellos para formar un sistema coherente. Boris Cherny, por ejemplo, usa /routines para programar ciclos de trabajo, /goal dentro de cada ciclo para definir cuándo terminó una etapa el agente y /loop para monitorear eventos externos entre ciclos.
"La ingeniería de loops consiste en combinar o crear un sistema en torno a todas estas cosas —routines, /loop— para poder darle a un asistente de programación con IA un alcance de trabajo mayor como entrada y hacer que lo complete de forma incremental."
En portugués: "La ingeniería de loops consiste en combinar o crear un sistema en torno a todas estas cosas —routines, /loop— para poder darle a un asistente de programación con IA un alcance de trabajo mayor como entrada y hacer que lo complete de forma incremental."
📋 Ejemplo de un sistema combinado
Cada 1 hora, activa el orquestador y le dice: «revisa el spec e identifica la siguiente tarea pendiente».
El orquestador configura un /goal para el worker: "implementa la feature X. Estás done cuando pasen todas las pruebas."
En paralelo, un /loop monitorea cada 5 minutos si aparecieron nuevas issues en GitHub. Si es así, las agrega al spec.
🎯 Punto de reflexión
La palabra clave en la cita de Cole es "incrementalmente". El punto central de Loop Engineering no es darle al agente un proyecto entero y decirle "hazlo". Es dividir el trabajo en ciclos pequeños, cada uno con un alcance limitado y su propia validación. Sin eso, el agente intenta resolver todo de una vez y, como advierte Cole, "it will get completely overwhelmed".
🔧 La skill Loop: montaje automático
Una de las cosas más interesantes que Cole demostró y que Claude Code tiene una capacidad interna llamada "loop skill". No necesitas configurar /loop manualmente. Solo dile a Claude Code que cargue la skill y armará el sistema de loop por sí solo, decidiendo el intervalo y la estrategia.
"Simplemente le dices que use la loop skill. La herramienta tiene una capacidad integrada que sabe cómo configurar estos sistemas de loop según lo que le pidamos."
En portugués: "Simplemente le dices que use la loop skill. La herramienta tiene una capacidad integrada que sabe cómo configurar estos sistemas de loop según lo que le pidamos."
🖥️ Lo que Cole demostró
Entrada: documento de especificación simple
Una lista de tareas numeradas en plan.md. Nada elaborado.
Claude Code identificó la estructura
"Dice que esta es una lista secuencial de tareas: va a hacer la primera tarea y luego programará una activación rápida."
El loop se autoconfiguró
"Escribió el prompt: /loop work through plan.md one task at a time." Cole no escribió ese prompt. Lo hizo Claude Code.
Ejecución incremental
En 2 minutos, ya había completado las 2 primeras tareas. Cada wake-up resuelve una tarea y programa el siguiente.
💡 Información importante
Que Claude Code configure el loop por sí solo es técnicamente impresionante, pero tiene un lado peligroso: pierdes visibilidad sobre cómo se configuró el loop. Cole usó un ejemplo sencillo a propósito, pero en sistemas de Boris Cherny con "decenas de miles de agentes", la autoconfiguración sin observabilidad es un riesgo concreto.
❓ Preguntas
Los tres bloques parecen simples. Y lo son. Pero esa simplicidad esconde trampas reales que deben señalarse antes de ponerse a implementar.
¿Todo se ejecuta en la misma sesión?
Cole plantea un problema estructural: "you're not really working between different coding agent sessions. Like when you're just using /loop in Claude Code, it's really just continuing in the same coding agent session." Esto significa que el context bloat es inevitable. Cada iteración del loop añade más contexto y el LLM se sobrecarga progresivamente. Es una limitación arquitectónica, no un bug.
¿Cuál es el costo real de mantener estos loops?
Cada activación de /loop consume tokens. Cada iteración de /goal también. Y /routines, que leen una especificación completa en cada ciclo, son especialmente costosas. Cole midió más de 1 millón de tokens para una aplicación sencilla. Para quienes pagan por token, la cuenta llega rápido.
¿Y si el loop decide mal?
Cuando Claude Code arma automáticamente el loop mediante una skill, también decide el prompt del siguiente ciclo. Si esa decisión es incorrecta, el error se propaga a todos los ciclos siguientes. Sin participación humana, solo descubres el problema cuando ya has gastado tokens y tiempo. Cole lo llama "el mayor problema de la ingeniería de loops en este momento".
⚠️ El límite de los bloques por sí solos
/loop, /goal y /routines son primitivas. Son los bloques de construcción, no la casa. Sin un sistema de orquestación que distribuya el trabajo entre distintas sesiones, gestione el estado externamente y permita la intervención humana, estos bloques producen resultados mediocres para cualquier cosa que vaya más allá de demos simples. El siguiente módulo (1.3) muestra cómo la arquitectura Orchestrator-Workers resuelve exactamente eso.
📋 Resumen del módulo
Módulo siguiente:
1.3 — Arquitectura Orchestrator-Workers