Loops de agentes de IA: como um agente de código se autocorrige sozinho

A forma como a maioria das pessoas ainda usa um agente de código de IA parece um pingue-pongue. Você manda um prompt, ele responde, você percebe o que está errado, você manda outro prompt. Você é o motor de correção e fica dentro do loop a cada rodada.

Um loop inverte isso. Você descreve o que quer, o agente mete a mão na massa, escreve a própria checklist, encontra os próprios pontos fracos e roda de novo até o resultado se sustentar. Você deixa de ser quem pega os erros. O agente pega os dele.

Essa virada não é hype. As pessoas que construíram essas ferramentas se apoiam nela. Boris Cherny e Cat Wu, os criadores do Claude Code, falam em programar em agent loops. Geoffrey Huntley, que batizou o "Ralph loop", deixa agentes rodando num simples loop while durante a noite. O padrão agora tem nome, e vale a pena entendê-lo antes de copiar três prompts vistos no Instagram.

Do pingue-pongue de prompts ao loop

Um prompt isolado é um tiro único. Você pergunta, recebe uma resposta, a transação acaba. Para melhorá-la, você precisa notar a falha e mandar outro prompt. Leve isso à escala de uma feature de verdade e você acaba fazendo dezenas de microcorreções na mão.

Um loop de agente de IA fecha essa falha dentro do agente. Você define um objetivo, o agente planeja, age, olha o resultado e corrige, de novo e de novo, até o objetivo ser cumprido. Você não some, você revisa no final. Mas deixa de ser o gargalo a cada iteração.

O pingue-pongue de prompts coloca você dentro do loop a cada rodada. Um loop de verdade coloca o agente nele.

O que é de fato um loop de agente de IA

Todo loop agêntico roda nos mesmos quatro tempos: planejar, agir, observar, corrigir. O agente decide o próximo passo, executa (escreve código, roda um comando, lê um arquivo), lê o que aconteceu e ajusta. O Claude escreve código, roda os testes, vê uma falha, corrige, roda os testes de novo. Esse retorno é todo o truque. É o que torna o loop autocorretivo, e não só repetitivo.

A versão mais robusta do loop distribui esses tempos por três papéis: um que planeja, um que constrói, um que revisa. Mantê-los separados é o que impede o agente de corrigir a própria lição no mesmo fôlego em que a escreve.

O loop de três comandos que você pode copiar hoje

Aqui está o esquema que está circulando agora, refeito em três comandos de barra do Claude Code. Você cola cada um uma vez, o agente cria o comando, e então você os roda em ordem.

O planejador, /spec:

Me entreviste uma pergunta por vez até entender bem o que eu quero.
Depois escreva um plano preciso em specs/project.md: o objetivo, os
requisitos exatos, os casos limite, e o que está dentro ou fora do escopo.
Mantenha curto e afiado, não um romance.

O construtor, /build:

Leia specs/project.md e construa exatamente o que está descrito, nada mais.
Quando terminar, liste cada requisito do plano e marque quais você
cobriu.

O revisor, /review:

Compare o que foi construído com specs/project.md, requisito por requisito.
Para cada um, diga se está coberto. Escreva as correções necessárias e
devolva-as ao /build. Só aprove quando o plano inteiro estiver coberto.

Três comandos, um loop: spec escreve o plano, build o implementa, review o compara com o plano e devolve as correções ao build. Ele fica ciclando até cada requisito ser cumprido.

O plano é a fonte da verdade. A revisão mede a construção contra ele, não contra uma impressão.

Por baixo do capô isso é spec-driven coding: é o spec escrito, não o histórico de conversa, que serve de juiz para o agente. O Spec Kit open-source do GitHub formaliza a mesma ideia com /specify, /plan, /tasks e /implement, e roda tanto no Claude Code quanto no Copilot, Cursor, Codex CLI e Gemini CLI.

Por que um contexto novo faz o loop funcionar: o Ralph loop

Geoffrey Huntley batizou a versão mais crua de tudo isso em meados de 2025: o Ralph loop. A ideia é um simples loop de shell que serve ao agente o mesmo prompt contra um spec escrito, deixa ele escolher uma tarefa e entregá-la, depois inicia um agente totalmente novo com contexto limpo e serve o prompt idêntico de novo.

while ainda_tem_todos; do
  agent --prompt "Trabalhe na próxima tarefa do todo.md" --non-interactive
done

A parte contraintuitiva é o reset do contexto. Uma sessão longa apodrece: a janela enche de raciocínios velhos, becos sem saída e conteúdos de arquivo defasados, e o modelo começa silenciosamente a largar instruções. Cada iteração do Ralph é um agente novo que lê o repositório atual e a lista de tarefas a partir do disco, faz uma unidade de trabalho, faz commit e sai limpo. Huntley o batizou de propósito em homenagem ao personagem dos Simpsons: parece bobo demais para funcionar, e funciona. Se você já viu uma sessão longa começar a alucinar, já sabe por que uma janela nova ganha de uma janela saturada.

Os comandos /loop e /goal do Claude Code

O Claude Code já traz primitivas de loop embutidas. O /goal define um estado final persistente, como é "pronto", e o Claude avalia o progresso contra ele depois de cada passada, em vez de só rodar o próximo passo. O /loop repete uma tarefa numa cadência ou até uma condição se sustentar, com formas como /loop every 10m ou /loop until:. Usados juntos, criam um loop autodirigido e autoencerrável: o Claude trabalha a diferença entre o estado atual e o objetivo, e para quando o objetivo é satisfeito ou você aperta Ctrl+C.

O detalhe que importa: um loop mantém continuidade. Ele lembra o que tentou e por que falhou, então cada passada se apoia na anterior em vez de repetir o mesmo beco sem saída. É o trade-off oposto ao reset de contexto limpo do Ralph, e os dois são válidos. Continuidade para uma autocorreção firme, contexto novo quando a janela está apodrecendo. Saber qual usar é a habilidade de verdade.

O mesmo loop, em cada provedor

Loops não são uma feature do Claude, são a direção para onde o setor inteiro caminha. Os nomes mudam, o formato não.

O Codex CLI levou o loop mais longe em público. A equipe da OpenAI apresentou seu /goal como a versão deles do Ralph loop, e Andrew Chen, da a16z, deixou-o rodando a noite inteira num driver de dispositivo, 14 horas seguidas sem intervenção. Ele também notou que isso ia "multiplicar por 10.000 o consumo de tokens", que é o custo honesto de deixar um agente moendo por meio dia.

A pegadinha: um loop amplifica tudo

Um loop não amplifica só o bom resultado, ele amplifica também um plano ruim. Aponte um agente autocorretivo para um spec vago e ele vai construir a coisa errada com toda a confiança, revisá-la contra o mesmo spec vago e aprovar. O plano é a alavanca. Um spec afiado economiza dez prompts, um spec nebuloso desperdiça cem.

Dois modos de falha para ficar de olho. O custo dispara: cada iteração queima tokens, e um loop sem limite num objetivo confuso pode queimar muito. E o loop pode rodar para sempre, cantando vitória ou perseguindo um alvo que nunca vai conseguir satisfazer. Limite-o: uma condição until clara, um teto de tokens ou um ponto de controle humano antes do merge. Um loop sem parada não é autonomia, é um descontrole.

Rodar loops por uma frota inteira

Um único agente autocorretivo é fácil de monitorar. A alavancagem aparece quando você roda vários ao mesmo tempo, cada um fazendo loop na própria tarefa, e é exatamente aí que ficar olhando um terminal deixa de escalar.

É para isso que o AgentsRoom foi feito. É um cockpit multiagentes: cada agente tem um papel, um ponto de status ao vivo e a própria cor, e você supervisiona a frota inteira de uma só janela. Solte um ticket no backlog e um agente o pega, roda seu loop plan-build-review e te entrega um diff limpo. É o spec-driven AI coding na prática: o ticket é o spec, o agente roda o loop, você revisa o resultado.

Como loops longos apodrecem o contexto, o AgentsRoom fica de olho nisso. Cada agente escreve um status de uma linha no fim de cada rodada, e quando um agente para de atualizá-lo duas rodadas seguidas, aparece um aviso com reinício em um clique sobre um contexto limpo, o mesmo reset de janela nova em que o Ralph loop se apoia. Veja como isso funciona na página de detecção de drift de contexto.

E como o loop é agnóstico de provedor, você não fica preso a nenhum. Rode um ticket no Claude Code, o próximo no Codex, outro no Gemini CLI, tudo no mesmo dashboard, cada um fazendo loop no próprio git worktree para que agentes paralelos nunca se atropelem. Dispare-os antes de desligar e revise os diffs de manhã, esse é todo o sentido dos agentes de código em segundo plano e do turno da noite.

Defina o objetivo uma vez, deixe o loop fechá-lo, revise no final. Baixe o AgentsRoom, confira a matriz de compatibilidade de provedores e leia mais sobre a revisão por agente e o suporte multiprovedor.