💸 Costo: más de 1 millón de tokens
El problema más tangible del loop engineering es el costo. Cada ronda del orchestrator consume tokens de razonamiento para planificar, cada worker consume tokens para ejecutar y el paso de contexto entre componentes multiplica todo. Cole Medin lo demostró con cifras reales en su dashboard.
"En una sola ejecución, aquí se ven todos los loops por los que pasó el orquestador; gasté más de un millón de tokens solo para crear una aplicación relativamente sencilla."
📊 Por qué es tan caro
Razonamiento del orchestrator
El orchestrator necesita leer la spec completa, planificar la ronda, crear prompts para cada worker y luego evaluar los resultados. Cada una de estas operaciones consume tokens de entrada y salida.
Transferencia de contexto distribuida
Los resultados de los workers deben volver al orchestrator. El state store debe leerse en cada round. La información fluye en todas las direcciones y cada flujo cuesta tokens.
Un único modelo para todo
Cuando solo se usa /loop en Claude Code, se usa el mismo modelo caro (Opus/Sonnet) para todo: clasificación, planificación, ejecución y validación. Sin combinar modelos, el costo por token es el más alto posible en cada etapa.
"Otro de los grandes problemas que veo al usar slash goal, rutinas o loops en Claude Code es que usas un solo modelo para prácticamente todo. Eso es parte del motivo por el que resulta tan caro."
📉 Calidad: "Ejecuta durante un día, vuelve y encuentra un desastre"
El segundo gran problema y la degradación de la calidad en loops largos sin supervisión humana. Cole Medin lo experimentó personalmente y describe la situación directamente: configuras el loop, te vas y, al volver, descubres que el resultado es inutilizable.
"Muchas veces la gente configura estos sistemas para que sigan, sigan, sigan y sigan. Luego los deja funcionando durante un día. Y cuando vuelve, solo encuentra basura. A mí también me ha pasado mientras probaba muchas cosas en Claude Code, como rutinas y /loop."
🕵 Por qué se degrada la calidad
- ✗Sin validación humana: el agente se valida a sí mismo, pero los LLM pueden aceptar resultados mediocres como «correctos»
- ✗Acumulación de malas decisiones: cada ronda se basa en la anterior; si la ronda 3 acepta un bug, las rondas 4-10 trabajan sobre ese bug
- ✗Fatiga de contexto: incluso con estado externo, el agente puede perder de vista el panorama general de lo que debería construir
- ✗Optimización local: cada ronda optimiza su tarea, pero puede perjudicar la coherencia del sistema en su conjunto
🛡 La defensa: human-in-the-loop
Cole enfatiza que la solución no es abandonar los loops, sino insertar checkpoints en los que el humano valide antes del siguiente round: "We can always have it pause for us to validate something before it continues, which is one of the biggest problems with loop engineering right now in general." La regla es clara: el agente hace el trabajo pesado y el humano garantiza la calidad.
💥 Saturación del contexto: la sesión sobrecargada
El tercer problema que Cole identifica es específico del uso básico de /loop en Claude Code: saturación de contexto. Cuando el loop se ejecuta en la misma sesión del agente, cada iteración agrega más historial a la ventana de contexto. Después de muchas iteraciones, el LLM queda literalmente sobrecargado.
"Al menos en muchas configuraciones, no trabajas entre distintas sesiones de agentes de programación. Por ejemplo, cuando usas /loop en Claude Code, en realidad solo continúa en la misma sesión del agente. Así que, si dejas el loop funcionando un rato, vas a inflar muchísimo el contexto de tu LLM y lo vas a saturar."
🧠 Qué sucede con la ventana de contexto
Iteración 1-5
SaludableLa ventana de contexto tiene espacio de sobra. El agente tiene acceso a las instrucciones originales, la especificación y el historial reciente. Alta calidad.
Iteración 10-20
PresionadoLa ventana de contexto empieza a llenarse. Las instrucciones iniciales quedan fuera de la ventana de atención. El agente empieza a «olvidar» detalles.
Iteración 30+
SobrecargadoVentana de contexto desbordada. El agente genera código repetido, ignora restricciones y pierde coherencia. Resultado: basura cara. Aquí es donde ocurre «ejecutarlo durante un día y volver a encontrar un desastre».
🔧 La solución: distribuir entre sesiones
Cole propone la solución: "Necesitamos un sistema que nos permita distribuir el trabajo entre distintas sesiones de agentes de programación y hacer que puedan comunicarse entre sí." En vez de una sesión larga, usar varias sesiones cortas y enfocadas, coordinadas por un estado externo. Cada sesión tiene el contexto actualizado y se enfoca en la tarea del momento.
🏗 Complejidad: ingeniería pesada
Armar un sistema robusto de loop engineering no es trivial. Exige una labor de ingeniería significativa: almacén de estado, gestión de worktrees, seguimiento de costos, observabilidad, human-in-the-loop, lógica de reintentos, limpieza de workers huérfanos, resolución de conflictos de puertos, branching de bases de datos. Es mucha infraestructura para respaldar lo que Cole describe como algo que «no merece su propio buzzword».
🧰 Lo que necesitas construir
Almacén de state
Postgres/Neon para persistir el estado entre rounds. Schema para runs, events, tasks, cost.
Observabilidad
Dashboard para ver las decisiones del orchestrator, el progreso de los workers y el costo acumulado en tiempo real.
Aislamiento de workers
Gestión de worktrees, ramas de base de datos y resolución de conflictos de puertos para workers paralelos.
Plano de control
Mecanismos de pausa, reanudación y cancelación. Puntos de control con intervención humana. Límites de presupuesto automáticos.
"Aquí hay mucho trabajo de ingeniería entre bastidores."
🌀 Alucinación compuesta entre rounds
Quizás el riesgo más insidioso de la ingeniería en bucle sea la alucinación compuesta: cuando un error del LLM en una ronda no se detecta y se propaga a las rondas siguientes, cada iteración amplifica el problema. Es diferente de un error puntual porque construye capas de código incorrecto que parecen correctas en la superficie.
⚠ El efecto snowball
Ronda 1: El worker implementa una función con un bug sutil en el manejo de un caso límite. El orquestador valida y acepta (el LLM no detecta el bug).
Ronda 3: Otro worker construye una función que depende de la función defectuosa. El código "funciona" en los happy paths, pero hereda el bug.
Ronda 7: Todo el codebase se construye suponiendo que la función del round 1 es correcta. Corregirla ahora exige refactorizarlo todo. El costo de la corrección supera el costo de haberlo hecho manualmente.
🛡 Defensas contra alucinaciones compuestas
- ✓Pruebas automatizadas como puerta de validación entre rondas: si las pruebas fallan, se vuelve a ejecutar la ronda
- ✓Human-in-the-loop en puntos críticos: revisión humana antes de los rounds que se basan en trabajo anterior
- ✓Rollback de ronda: capacidad de deshacer una ronda completa cuando falla la validación
- ✓Validación cruzada: usar un modelo diferente para validar el output del worker principal
❓ Preguntas
Las desventajas no son motivo para descartar la ingeniería de loops, pero sí para mantener un escepticismo saludable. Cole Medin plantea las preguntas más directas.
¿La ingeniería de loops es realmente el mejor enfoque?
Cole es directo: "There is no way you're gonna convince me that loop engineering is the way to get the best results possible with AI coding assistance." La afirmación es contundente e intencional. Los loops optimizan el rendimiento, no la calidad. Para obtener un resultado óptimo, el humano en el loop es insustituible.
Boris gestiona decenas de miles de agentes al día. ¿Tiene sentido?
Cole cuestiona directamente la practicidad: "Boris Cherny dice que hay días en que gestiona decenas de miles de agentes de IA al mismo tiempo. A ver, ¿eso es realmente práctico? ¿Va a escalar?" Y luego provoca con humor: "Quiero decir, quizá eso explique algunos de los errores que tenemos en Claude Code."
¿El privilegio de budget distorsiona la perspectiva?
Los mayores defensores de los loops operan con recursos que la mayoría no tiene. Boris cuenta con Anthropic. Peter tiene "un presupuesto prácticamente ilimitado". Cuando quien promueve una práctica no siente el costo, es fácil entusiasmarse. La pregunta es si esto funciona para quienes cuentan cada dólar gastado en tokens.
🤔 Punto de reflexión
Cole cierra su análisis de las desventajas con una propuesta constructiva: no descartar los loops, sino integrarlos en un harness que resuelva los problemas. "I like the concept of it, and I want to drive how autonomous my coding agents can be, but you got to have the right system." El siguiente módulo (2.3) explicará exactamente cuándo usar loops y cuándo no.
📋 Resumen del módulo
Módulo siguiente:
2.3 — Cuándo usarlo y cuándo no