♾ Anti-pattern: bucle infinito sin condición de salida
El error más costoso en Loop Engineering: iniciar un loop sin definir cuándo debe detenerse. El agente sigue ejecutándose, gastando tokens, sin converger en ningún resultado. Es el equivalente a un while(true) sin break.
🚨 Síntomas
- ✗El costo de los tokens se dispara sin output visible
- ✗El agente repite las mismas acciones en ciclos sucesivos
- ✗plan.md no tiene tareas marcadas como completadas
- ✗Ningún /goal ni max iterations definido
✅ Solución
# SEMPRE combine /goal + max iterations
/goal All tasks in plan.md are checked off
/loop --max-iterations 15 work through plan.md one task at a time
# Para multi-agent: max rounds no orchestrator
"Maximum 5 rounds. If spec is not satisfied after 5 rounds, stop and report what's missing."💥 Antipatrón: desbordamiento de la ventana de contexto
Iterar en la misma sesión del agente acumula contexto en cada ciclo. Después de varias iteraciones, el LLM se sobrecarga: las respuestas se degradan, se ignoran las instrucciones y el agente empieza a alucinar.
"Si dejas el loop funcionando un rato, vas a inflar muchísimo el contexto de tu LLM y lo vas a saturar. Por eso necesitamos un sistema que distribuya el trabajo entre distintas sesiones de agentes de programación."
🚨 Síntomas
- ✗La calidad de las respuestas se degrada después de 5-10 iteraciones
- ✗El agente "olvida" las instrucciones del inicio de la sesión
- ✗Las respuestas se vuelven repetitivas o contradictorias
- ✗Errores de alucinación en nombres de archivos y funciones
✅ Solución
- ✓State externo: guardar el progreso en una base de datos (Postgres), no en la ventana de contexto
- ✓Sesiones separadas: cada worker en su propia sesión de agente
- ✓Recorte de contexto: mantener solo el estado actual en el prompt, no todo el historial
- ✓Compact/resume: usar sesiones reanudables con context compaction
🚨 Antipatrón: conflictos de puertos en sesiones paralelas
Cuando varios workers ejecutan servidores de desarrollo o pruebas que usan puertos de red, todos intentan usar el puerto 3000 (o 5173, 8080, etc.). El primero funciona; los demás fallan silenciosamente.
"Muchas cosas distintas, como los conflictos de puertos que también queremos resolver."
✅ Solución
# Alocar porta dinamica por worker
export PORT=$((3000 + WORKER_ID))
# Ou usar porta 0 (sistema aloca automaticamente)
node server.js --port 0
# No prompt do worker: instrua a usar porta unica
"Use port {{3000 + worker_index}} for any dev server. Do NOT use port 3000."👣 Antipatrón: workers que se pisan entre sí
Sin un aislamiento adecuado, los workers editan los mismos archivos, generan conflictos de merge y sobrescriben el trabajo de los demás. Este problema tiene dos dimensiones: código y datos.
✗ Sin aislamiento
- ✗Todos los workers en el mismo checkout
- ✗La misma base de datos para todos
- ✗Conflictos de merge constantes
- ✗Migraciones que afectan a otros workers
✓ Con aislamiento
- ✓Git worktree por worker
- ✓Branch de Neon por worker
- ✓Merge solo después de la validación
- ✓Cada worker opera dentro de un alcance definido
🔍 Depuración con los registros del panel de control
La observabilidad es clave para diagnosticar problemas en loops. Sin ella, estás a oscuras. Cole Medin creó un dashboard open source precisamente para eso: ver las decisiones del orchestrator, el progreso de los workers y el costo acumulado en tiempo real.
"Tengo mucha observabilidad integrada en este dashboard. Poder ver exactamente las decisiones que se toman aquí hace que me resulte más fácil revisar todo esto, incluso hacer que mi agente de programación analice las ejecuciones en la base de datos y luego descubrir cómo mejorar el loop."
📊 Qué monitorear
Decisiones del orchestrator
Qué workers se enviaron, con qué prompts y en qué ronda
Tokens por ronda
Costo acumulado para identificar rondas ineficientes
Estado de los workers
Cuáles se completaron, cuáles fallaron, tiempo de ejecución
Resultados de validación
¿Pasaron las pruebas? ¿Se cumplieron los criterios de la especificación?
✅ Lista de verificación: listo para el bucle
Antes de iniciar cualquier loop, recorre esta lista de verificación. Cada elemento es un requisito previo que evita los antipatterns analizados en este módulo. Haz clic en los elementos para marcarlos a medida que los verificas.
📋 Lista de verificación previa
Exit Conditions
State y durabilidad
Aislamiento
Presupuesto y costo
Observabilidad
Human-in-the-Loop
Marca todos los elementos aplicables antes de iniciar el loop.
🎯 Punto de reflexión
Cole Medin resume: "I really do want to incorporate loop engineering. 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. Otherwise, things are going to completely fall apart." El checklist existe para garantizar que el sistema esté bien antes de dejar que el agente se ejecute.
📋 Resumen del módulo
Conclusión de la Ruta 4
Recorriste desde el loop simple (plan.md) hasta el orchestrator multi-agent y ahora sabes qué puede salir mal y cómo prevenirlo. La siguiente etapa es tuya: arma tu primer loop, empieza con algo simple y evoluciona según lo necesites.