MODULO 4.4

⚠ Anti-Patterns e Troubleshooting

Os erros mais comuns em loop engineering, como diagnosticar, e um checklist interativo de "ready to loop" para verificar antes de disparar qualquer sistema.

6
Topicos
25
Minutos
Ref.
Nivel
Guia
Tipo
1

♾ Anti-Pattern: Loop Infinito sem Exit Condition

O erro mais caro em loop engineering: disparar um loop sem definir quando ele deve parar. O agente continua rodando, gastando tokens, sem convergir para resultado algum. E o equivalente a um while(true) sem break.

🚨 Sintomas

  • Custo de tokens disparando sem output visivel
  • Agente repete as mesmas acoes em ciclos sucessivos
  • plan.md nao tem tarefas marcadas como concluidas
  • Nenhum /goal ou max iterations definido

✅ Fix

# 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."
2

💥 Anti-Pattern: Context Window Overflow

Looping na mesma sessao de agente acumula contexto a cada ciclo. Depois de varias iteracoes, o LLM fica sobrecarregado: respostas degradam, instrucoes sao ignoradas, e o agente comeca a alucinar.

"If you loop for a while, you're going to completely bloat your context for your LLM and overwhelm it. And so we need a system where we can distribute the work actually between different coding agent sessions."
-- Cole Medin

🚨 Sintomas

  • Qualidade das respostas degrada apos 5-10 iteracoes
  • Agente "esquece" instrucoes do inicio da sessao
  • Respostas ficam repetitivas ou contraditórias
  • Erros de alucinacao em nomes de arquivos e funcoes

✅ Fix

  • State externo: gravar progresso em banco (Postgres), nao no context window
  • Sessoes separadas: cada worker em sua propria sessao de agente
  • Context trimming: manter apenas o estado atual no prompt, nao o historico completo
  • Compact/resume: usar sessoes resumiveis com context compaction
3

🚨 Anti-Pattern: Port Conflicts em Sessoes Paralelas

Quando multiplos workers rodam dev servers ou testes que usam portas de rede, todos tentam usar a porta 3000 (ou 5173, 8080, etc). O primeiro funciona, os outros falham silenciosamente.

"A lot of different things like port conflicts that we want to solve for as well."
-- Cole Medin

✅ Fix

# 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."
4

👣 Anti-Pattern: Workers Pisando Uns nos Outros

Sem isolamento adequado, workers editam os mesmos arquivos, geram conflitos de merge, e sobrescrevem o trabalho uns dos outros. Esse problema tem duas dimensoes: codigo e dados.

✗ Sem Isolamento

  • Todos os workers no mesmo checkout
  • Mesmo banco de dados para todos
  • Conflitos de merge constantes
  • Migracoes quebrando outros workers

✓ Com Isolamento

  • Git worktree por worker
  • Neon branch por worker
  • Merge apenas apos validacao
  • Cada worker opera em scope definido
5

🔍 Debugando com Logs do Dashboard

Observabilidade e a chave para diagnosticar problemas em loops. Sem ela, voce esta no escuro. Cole Medin construiu um dashboard open source exatamente para isso: ver as decisoes do orchestrator, progresso dos workers e custo acumulado em tempo real.

"I have a lot of observability built into this dashboard. Just being able to see exactly the decisions that are going on here means that it's easier for me to look at this, even have my coding agent analyze the runs in the database, and then figure out how to improve the loop."
-- Cole Medin

📊 O que Monitorar

1

Decisoes do orchestrator

Que workers foram despachados, com quais prompts, em qual round

2

Tokens por round

Custo acumulado para identificar rounds ineficientes

3

Status dos workers

Quais completaram, quais falharam, tempo de execucao

4

Resultados de validacao

Testes passaram? Criterios da spec atendidos?

6

✅ Checklist: Ready to Loop

Antes de disparar qualquer loop, percorra este checklist. Cada item e um pre-requisito que evita os anti-patterns discutidos neste modulo. Clique nos items para marcar conforme verificar.

📋 Pre-Flight Checklist

Exit Conditions

State e Durabilidade

Isolamento

Budget e Custo

Observabilidade

Human-in-the-Loop

Marque todos os items aplicaveis antes de iniciar o loop.

🎯 Ponto de Reflexao

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." O checklist existe para garantir que o sistema esta correto antes de deixar o agente rodar.

📋 Resumo do Modulo

Loop infinito -- sempre definir exit conditions + max iterations
Context overflow -- usar state externo e sessoes separadas
Port conflicts -- alocar portas unicas por worker
Workers sem isolamento -- worktrees + database branches
Ready to Loop checklist -- 15 verificacoes antes de disparar

Conclusao da Trilha 4

Voce percorreu do loop simples (plan.md) ao orchestrator multi-agent e agora sabe o que da errado e como prevenir. A proxima etapa e sua: monte seu primeiro loop, comece simples, e evolua conforme a necessidade.