🧠 El origen del término
La ingeniería de bucles surgió como una forma de describir algo que los profesionales más destacados ya estaban haciendo: programar loops automatizados que hacen prompting a los agentes de IA, en lugar de que la persona escriba cada instrucción manualmente. El término ganó popularidad cuando figuras como Boris Cherny (director de Claude Code en Anthropic) y Peter Steinberger (creador de OpenClaw) empezaron a hablar públicamente de sus workflows.
💬 Las voces que iniciaron el movimiento
Dos declaraciones se hicieron virales y dieron forma al término:
"Ya no escribo prompts para Claude. Escribo loops y los loops hacen el trabajo. Mi trabajo es escribir loops."
Peter Steinberger, de OpenClaw, expresó la misma idea: no les da instrucciones directamente a los agentes, sino que diseña los loops que lo hacen por él. Cole Medin, al analizar estas declaraciones, observó que "loop engineering is kind of a buzzword, but also there are some really good takeaways when you dive into this".
🎯 Punto de reflexión
Cole Medin cuestiona abiertamente: "I don't even know if it deserves its own term." Loop Engineering no es una tecnología nueva. Es una reorganización de conceptos existentes (cron jobs, automatización, orquestación) aplicados a agentes de IA. El mérito real está en la conversación sobre cómo y cuándo dejar que los agentes trabajen de forma autónoma.
⚙️ Definición práctica
En la práctica, Loop Engineering es diseñar un sistema donde loops automatizados hacen prompting a los agentes de IA, para que la persona no tenga que estar frente a la terminal escribiendo cada instrucción. La persona define la estrategia y los criterios; el loop ejecuta, valida e itera.
✓ Ingeniería de bucles
- ✓El humano define el plan y los criterios una sola vez
- ✓El loop despierta al agente periódicamente
- ✓El agente trabaja, valida e informa
- ✓Escalable para múltiples tareas
✗ Indicaciones manuales
- ✗El humano permanece en la terminal para cada instrucción
- ✗No escala a múltiples tareas
- ✗Interrupción constante del flujo de trabajo
- ✗Depende de la disponibilidad de una persona
🔗 La analogía con los cron jobs
Si ya trabajaste con servidores, el concepto de loop engineering te resultará familiar. Piensa en un cron job: un programador que activa un script en cada intervalo definido. Loop Engineering es exactamente eso, pero en lugar de ejecutar un script bash, activas un agente de IA con un prompt y este decide qué hacer según el estado actual del mundo.
📋 La receta básica de un loop
Definir el input externo
Un repositorio de GitHub, una carpeta de documentos, una API, una base de datos.
Definir el intervalo
Cada 5 minutos, cada hora o «trabaja hasta terminar» (/goal).
Definir el criterio de finalización
"Todas las tareas marcadas como done", "0 issues abiertos", "todas las pruebas pasan".
Dejar que el loop se ejecute
El agente se activa, verifica el estado, ejecuta la siguiente tarea, la valida y se duerme.
"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."
La palabra clave aquí es gradualmente. El punto central de un loop es que el agente nunca intenta resolverlo todo de una vez. Toma una tarea por ciclo, la ejecuta, la valida y el loop avanza. Como dice Cole: "we never want to have a coding agent try to handle too much at once, or it will get completely overwhelmed."
👤 Las personas: Boris, Peter y Cole
Para entender Loop Engineering, conviene saber quién está detrás de la conversación. Cada persona aporta una perspectiva diferente, y las diferencias importan.
Gestiona decenas de miles de agentes al día, según él mismo. Usa /loop, /goal y /routines en Claude Code como bloques fundamentales. Es quien más promueve el concepto de «ya no escribo prompts, escribo loops». Es importante tener en cuenta que trabaja en Anthropic y tiene acceso a recursos computacionales que la mayoría no tiene.
Otro defensor vocal de los loops autónomos. Ejecuta loops que le dan instrucciones a Claude por él, delegando casi por completo el ciclo de desarrollo. Cole Medin observa que opera con "pretty much an infinite budget", lo que hace que su configuración sea difícil de replicar para la mayoría de los desarrolladores.
Una postura más escéptica y práctica. Reconoce el valor de los loops, pero cuestiona: «I am not sold on this idea right now.» Construyó su propio enfoque con workflows deterministas en Archon, donde la persona controla el proceso en lugar de delegarlo por completo al agente. Su enfoque está en el costo, la confiabilidad y la observabilidad.
🤔 Punto de reflexión
Cole Medin plantea una pregunta directa sobre Boris: "Boris Cherny says that there are days he manages tens of thousands of AI agents at once. Like really, is that actually practical? Is that going to scale?" Y después provoca: "I mean, maybe that does explain some of the bugs we have in Claude Code." Es una perspectiva honesta: quienes promueven el loop engineering son personas con acceso a recursos que la mayoría no tiene.
📊 El flujo básico de un loop
En el nivel más simple, Cole Medin demostró loop engineering con un ejemplo directo en Claude Code. Le pasó un documento de especificaciones (plan.md) con tareas numeradas y le pidió a Claude Code que usara el skill de loop.
"Sé que este es un ejemplo muy, muy básico, pero quiero mantenerlo simple a propósito. El sistema escribió el prompt: /loop work through plan.md one task at a time."
🔧 Qué ocurrió en la demo
Cole pasó el prompt para pedir que cargara el "loop skill". Claude Code cargó la capability y supo cómo montar el sistema de loop por su cuenta.
El agente identificó que era una lista secuencial de tareas y configuró /loop automáticamente. "It says this is sequential task list, it's going to do the first task, and then it's going to schedule a quick wake up."
En cada ciclo, el agente hacía la tarea, la validaba y programaba la siguiente activación. «Se está reanudando con una activación de slash loop. Y mira eso. Ni siquiera escribí este prompt yo mismo».
En dos minutos, ya había completado dos tareas. El loop continuaría hasta completarlas todas.
📌 El punto central
Claude Code funciona aquí como orquestador y worker al mismo tiempo. Arma el loop, escribe su prompt y ejecuta las tareas. Para casos simples, funciona. Para sistemas más complejos, como veremos en el módulo 1.3, la separación entre orchestrator y workers se vuelve esencial.
❓ Preguntas
Antes de sumergirte en los bloques técnicos, vale la pena hacer una pausa y plantear las preguntas legítimas que el propio Cole Medin propone sobre el concepto.
¿La ingeniería de bucles merece ser un término propio?
Cole Medin es directo: "I don't even know if it deserves its own term." La idea de automatizar tareas con loops y programadores existe desde hace décadas. Lo que cambia es el componente LLM en el centro. Pero la mecánica —cron, wake up, execute, sleep— es la misma de siempre. Llamar a esto "engineering" es, como mínimo, generoso.
¿Quién se beneficia realmente?
Los mayores defensores de loop engineering son personas con acceso a presupuestos enormes e infraestructura de punta. Boris cuenta con los recursos de Anthropic. Peter opera con un presupuesto prácticamente ilimitado. La pregunta real es: ¿esto escala para un desarrollador que trabaja solo o una startup con un presupuesto ajustado?
Autonomía vs. calidad: ¿es un trade-off?
Cole resume: "no hay forma de que me convenzas de que la ingeniería de loops es la manera de obtener los mejores resultados posibles con la asistencia de programación con IA." Más autonomía significa menos control. Menos control significa más riesgo de obtener malos resultados. El módulo 2.2 analizará esto en detalle.
⚠️ La provocación de Cole
Al final del análisis, Cole sintetiza: "I would just fold loop engineering into harness engineering. It doesn't quite deserve its own buzzword. But there are some good ideas here." La idea no se descarta, sino que se replantea. Loop Engineering es un ingrediente, no una comida completa.
📋 Resumen del módulo
Módulo siguiente:
1.2 — Los bloques fundamentales (/loop, /goal, /routines)