💸 Custo: Mais de 1 Milhao de Tokens
O problema mais tangivel do loop engineering e o custo. Cada round do orchestrator consome tokens de reasoning para planejar, cada worker consome tokens para executar, e o context passing entre componentes multiplica tudo. Cole Medin demonstrou isso com numeros reais no seu dashboard.
"For a single run, like here are all the loops that the orchestrator went through, it costed me over a million tokens just to build a relatively simple application."
📊 Por Que E Tao Caro
Orchestrator reasoning
O orchestrator precisa ler a spec inteira, planejar o round, criar prompts para cada worker, e depois avaliar os resultados. Cada uma dessas operacoes consome tokens de input e output.
Context passing distribuido
Os resultados dos workers precisam voltar ao orchestrator. O state store precisa ser lido a cada round. Informacao flui em todas as direcoes, e cada fluxo custa tokens.
Modelo unico para tudo
Quando se usa apenas /loop no Claude Code, o mesmo modelo caro (Opus/Sonnet) e usado para tudo: triagem, planejamento, execucao, validacao. Sem mix de modelos, o custo por token e o mais alto possivel em cada etapa.
"One of the other big issues I see with using slash goal or routines or loops in Claude Code is you're just using one model for pretty much everything. That's part of the problem of why it's so expensive."
📉 Qualidade: "Run for a Day, Come Back to Crap"
O segundo grande problema e a degradacao de qualidade em loops longos sem supervisao humana. Cole Medin experimentou isso pessoalmente e descreve a situacao de forma direta: voce configura o loop, vai embora, e ao voltar descobre que o output e inutilizavel.
"A lot of times people set up these systems to just go, go, go, go. And then you have a run for a day. And by the time it comes back, you just have crap. Like I've had that myself as I've tested a lot of things within Claude Code, like routines and slash loop."
🕵 Por Que a Qualidade Degrada
- ✗Sem validacao humana: o agente valida a si mesmo, mas LLMs podem aceitar resultados mediocres como "corretos"
- ✗Acumulo de decisoes ruins: cada round constroi sobre o anterior; se o round 3 aceita um bug, os rounds 4-10 trabalham em cima desse bug
- ✗Fadiga de contexto: mesmo com state externo, o agente pode perder o panorama geral do que deveria construir
- ✗Otimizacao local: cada round otimiza para sua tarefa, mas pode prejudicar a coerencia do sistema como um todo
🛡 A Defesa: Human-in-the-Loop
Cole enfatiza que a solucao nao e abandonar loops, mas sim inserir checkpoints onde o humano valida antes do proximo 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." A regra e clara: o agente faz o trabalho pesado, o humano garante a qualidade.
💥 Context Bloat: A Sessao Sobrecarregada
O terceiro problema que Cole identifica e especifico do uso basico de /loop no Claude Code: context bloat. Quando o loop roda na mesma sessao de agente, cada iteracao adiciona mais historico ao context window. Apos muitas iteracoes, o LLM fica literalmente sobrecarregado.
"At least for a lot of setups, you're not really working between different coding agent sessions. Like when you're just using slash loop in Claude Code, it's really just continuing in the same coding agent session. So if you loop for a while, you're going to completely bloat your context for your LLM and overwhelm it."
🧠 O que Acontece com o Context Window
Iteracao 1-5
SaudavelContext window tem espaco de sobra. O agente tem acesso a instrucoes originais, spec, e historico recente. Qualidade alta.
Iteracao 10-20
PressionadoContext window comeca a ficar cheio. Instrucoes iniciais sao empurradas para fora da janela de atencao. O agente comeca a "esquecer" detalhes.
Iteracao 30+
SobrecarregadoContext window estourado. O agente gera codigo repetido, ignora constraints, e perde coerencia. Resultado: lixo caro. E aqui que "run for a day, come back to crap" acontece.
🔧 A Solucao: Distribuir entre Sessoes
Cole propoe a solucao: "We need a system where we can distribute the work actually between different coding agent sessions and make it so they can all communicate to each other." Em vez de uma sessao longa, usar multiplas sessoes curtas e focadas, coordenadas por state externo. Cada sessao tem contexto fresco e foco na tarefa do momento.
🏗 Complexidade: Engenharia Pesada
Montar um sistema de loop engineering robusto nao e trivial. Exige engenharia significativa: state store, worktree management, cost tracking, observabilidade, human-in-the-loop, retry logic, cleanup de workers orfaos, resolucao de conflitos de porta, database branching. E muita infraestrutura para suportar o que Cole chama de algo que "nao merece seu proprio buzzword."
🧰 O Que Voce Precisa Construir
State Store
Postgres/Neon para persistir estado entre rounds. Schema para runs, events, tasks, cost.
Observabilidade
Dashboard para ver decisoes do orchestrator, progresso dos workers, custo acumulado em tempo real.
Worker Isolation
Gerenciamento de worktrees, database branches, resolucao de conflitos de porta para workers paralelos.
Control Plane
Mecanismos de pause, resume, cancel. Human-in-the-loop checkpoints. Budget limits automaticos.
"There's a lot of engineering that goes on behind the scenes here."
🌀 Alucinacao Composta Entre Rounds
Talvez o risco mais insidioso do loop engineering seja a alucinacao composta: quando um erro do LLM num round nao e detectado e se propaga para os rounds seguintes, cada iteracao amplificando o problema. E diferente de um erro pontual porque constroi camadas de codigo incorreto que parecem corretas na superficie.
⚠ O Efeito Snowball
Round 1: Worker implementa uma funcao com um bug sutil no tratamento de edge case. O orchestrator valida e aceita (o LLM nao detecta o bug).
Round 3: Outro worker constroi feature que depende da funcao bugada. O codigo "funciona" nos happy paths, mas herda o bug.
Round 7: O codebase inteiro e construido assumindo que a funcao do round 1 esta correta. Corrigir agora exige refatorar tudo. O custo de correcao excede o custo de ter feito manualmente.
🛡 Defesas contra Alucinacao Composta
- ✓Testes automatizados como validation gate entre rounds: se os testes falham, o round e re-executado
- ✓Human-in-the-loop em pontos criticos: review humano antes de rounds que constroem em cima de work anterior
- ✓Rollback de round: capacidade de desfazer um round inteiro quando a validacao falha
- ✓Validacao cruzada: usar um modelo diferente para validar o output do worker principal
❓ Questionamentos
As desvantagens nao sao razao para descartar loop engineering, mas sao razao para ceticismo saudavel. Cole Medin levanta as questoes mais diretas.
Loop engineering e realmente a melhor abordagem?
Cole e direto: "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." A afirmacao e forte e intencional. Loops otimizam para throughput, nao para qualidade. Para resultado otimo, o humano no loop e insubstituivel.
Boris gerencia dezenas de milhares de agentes por dia. Faz sentido?
Cole questiona diretamente a praticidade: "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?" E depois provoca com humor: "I mean, maybe that does explain some of the bugs we have in Claude Code."
O privilegio de budget distorce a perspectiva?
Os maiores defensores de loops operam com recursos que a maioria nao tem. Boris tem a Anthropic. Peter tem "pretty much an infinite budget." Quando quem promove uma pratica nao sente o custo, e facil ser entusiasta. A questao e se isso funciona para quem conta cada dolar de token.
🤔 Ponto de Reflexao
Cole encerra sua analise de desvantagens com uma proposta construtiva: nao descartar loops, mas embrulha-los num harness que resolve os 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." O proximo modulo (2.3) vai cobrir exatamente quando usar e quando nao usar loops.
📋 Resumo do Modulo
Proximo Modulo:
2.3 — Quando Usar e Quando Nao Usar