Como é diferente um turn-based loop de conversar normalmente com Claude?

Turn-based loops deixam o agente rodar skills de self-check — testes, linters, audits — sem esperar por você. Em conversa normal, você faz uma pergunta, lê a resposta, digita de novo. Em loop, o agente pode revisar seu próprio trabalho em ciclos automáticos antes de entregar para você.

Quando devo usar goal-based vs time-based loops?

Goal-based é pra algo que você quer que termine com um resultado específico (coverage de 80%, bundle size menor que 50KB). Time-based é pra trabalho recorrente que roda em intervalos (a cada 6 horas, todo dia às 3 da manhã). Goal-based para quando atinge; time-based segue agendado.

Preciso de infraestrutura complicada pra rodar loops?

Turn-based e goal-based funcionam localmente no seu terminal. Time-based curto (/loop) também. Só /schedule (cron jobs) vai precisar de algo como Vercel, GitHub Actions ou um servidor cloud. Mas não é nada complexo — é só definir a recorrência.

Meu repositório tá bagunçado. Os loops vão funcionar?

Loops vão funcionar, mas não bem. Se o agente não consegue entender sua arquitetura ou testes estão quebrados, ele vai gastar tokens tentando aprender em vez de automatizar. Limpe o repositório primeiro: documente, faça testes passar, organize o README.

Qual tipo de loop eu devo começar com?

Comece com turn-based usando skills que você já tem. Teste o ciclo de feedback. Depois migre pra goal-based pra objetivos bem definidos. Time-based vem depois quando entender a recorrência que faz sentido no seu workflow.

4 Padrões de Loops no Claude Code: Automação Que Aprende

Na minha visão, loops no Claude Code são o turning point entre "scripts que rodam uma vez" e "automação que aprende com você". Um loop é basicamente um agente repeating cycles of work até atingir um stop condition — simples, mas muda tudo quando você entende qual tipo de loop usar em cada situação. A maioria dos devs eu conheço tá usando turn-based ou nada; enquanto isso, goal-based, time-based e proactive loops tão ali esperando resolver exatamente o tipo de trabalho chato que ninguém quer tocar manualmente.

Turn-based loops: o padrão que você já tá usando sem saber

Turn-based loops são acionados por um prompt seu. Você pede algo, o agente faz, você vê o resultado, pode pedir refinamento. É o modo de interação que você já faz no Claude todos os dias — mas agora o agente pode verificar seu próprio trabalho em tempo real. A magic tá em skills que deixam o agente rodar testes, linters, audits — tudo sem esperar por você. Você ganha ciclos de feedback muito mais rápidos, e o agente para quando tá satisfeito, não quando você tá satisfeito.

Goal-based loops: quando você sabe exatamente o que quer, mas não como chegar lá

Goal-based loops são diferentes — você define um objetivo ("aumentar coverage de testes em 15%", "reduzir bundle size em 20KB", "deletar todos os TODOs deprecated") e o agente segue iterando até atingir exatamente aquilo. Funciona quando você tem um critério verificável. A pegadilha: se o critério for vago ou impossível, o loop fica rodando infinitamente. Por isso que essa categoria de loops precisa de discipline — você escreve o success condition em código, não em English vago. Tipo um test suite que o agente roda a cada iteração pra saber se terminou ou não.

Time-based loops: automação que não precisa de você

Time-based loops são agendados — rode a cada 5 minutos, todo dia às 3 da manhã, toda segunda-feira. Ideal pra trabalho que é realmente recorrente: sincronizar dados, fazer backup, processar filas, validar deploys. A CLI te dá dois comandos pra isso: /loop (intervalo curto, em tempo real) e /schedule (cron jobs, cloud infrastructure). Isso funciona bem com sistemas externos — a Anthropic roda automações internas via time-based loops, sincronizando eventos de várias plataformas.

Proactive loops: quando o agente não espera por você

Proactive loops são acionados por eventos — um PR foi aberto, um bug foi reportado, um deployment falhou. O agente vê o trigger, age, e continua iterando sem você mexer em nada. Isso é mais próximo de um background job, mas com inteligência: você define o fluxo (triage bugs, rodar migrações, revisar código), o agente executa proativamente, e você só revisa o resultado depois. Muito mais eficiente que esperar por você digitar um comando.

Por que isso importa para devs (e que loop você tá perdendo)

Na prática, loops resolvem a automação que mora entre "manual tedioso" e "preciso de um job de backend". (1) Turn-based + skills de self-check significa que você conversa com o agente e ele melhora sozinho — perfeito pra pairing on code, reviews, refactoring. (2) Goal-based loops deixam você delegar objetivos bem definidos — test coverage, performance targets, debt reduction — e só olha quando terminar. (3) Time-based loops são seu sistema nervoso — sincronizações, validações, healthchecks rodando 24/7. (4) Proactive loops te libertem de triagem manual e planing repetitivo, porque o agente age quando algo acontece. A maioria dos devs eu trabalho tá apenas usando turn-based (conversando) ou nada. Ou seja, 75% da automação ali faltando.

A ponte: qualidade de código e documentação acessível

Aqui tá a parte que ninguém fala: loops funcionam bem quando seu repositório tá limpo. Esquemas contraditórios, READMEs desatualizados, testes faltando — tudo isso faz o agente gastar ciclos "entendendo" em vez de "fazendo". Se você quer loops de verdade, você precisa investir no básico: código documentado, testes passando, arquivos explicando como rodar tudo. Faz sentido — um agente que não consegue entender sua arquitetura não vai iterar bem.

Conclusão: loops são o chão onde a automação de verdade mora

Loops são a razão pela qual "agentes" deixam de ser conversa e viram infraestrutura. Se você tá rodando Claude Code ainda como "eu digito um prompt por vez", você tá ignorando 80% do que a ferramenta consegue fazer. O time do Claude Code documentou os 4 padrões em detalhes — vale explorar cada um e começar com o que faz sentido para seu workflow. Turn-based pra pairing, goal-based pra objetivos, time-based pra recorrência, proactive pra reação. Depois você monta o resto.