Esqueça os Prompts. Você Precisa de Loops.

O tweet do Peter Steinberger viralizou no mês passado — oito milhões de visualizações: "Você não deveria estar fazendo prompts para agentes de IA. Você deveria estar desenhando loops que façam prompts para seus agentes."

Por volta da mesma época, Boris Cherny — criador do Claude Code — disse algo parecido no Acquired Unplugged: "Eu não faço mais prompts para o Claude. Tenho loops rodando. Eles são quem fazem os prompts pro Claude."

E aí a internet fez o que a internet faz: todo mundo discutiu, ninguém entendeu nada, e o discurso virou uma bagunça de abstrações.

Eu venho rodando loops reais há vários meses. Não porque eu esteja na frente — eu só me irritei o suficiente com trabalho manual de triagem e automatizei. O que encontrei me surpreendeu: a mentalidade de loop não é uma técnica avançada para power users de IA. É uma evolução natural que acontece quando você para de tratar agentes de IA como copiadores sofisticados e começa a tratá-los como sistemas que podem monitorar, decidir e agir por você.

Os Três Tipos de "Loop" Que Ninguém Define

É por isso que essa conversa fica confusa: quando as pessoas dizem "loop", podem estar falando de três coisas diferentes, e as diferenças importam.

Primeiro, existe o loop de tarefa autônoma — basicamente "continue até terminar". Pense no script Ralph do Geoffrey Huntley (while :; do cat PROMPT.md | claude-code; done), ou no comando /goal que o Codex e o Claude Code já incluem nativamente. Esse é o modo "configure e esqueça".

Segundo, existe o loop programado ou orientado por eventos — trabalho que roda enquanto você não está na cadeira. O HEARTEBEAT.md do próprio Peter Steinberger no OpenClaw é o exemplo canônico: uma checklist que o agente reconsidera a cada 30 minutos. Descendentes desse padrão incluem as automações do Codex e as rotinas agendadas do Claude Code.

Terceiro, existe o fan-out de orquestração — workflows dinâmicos com múltiplos agentes rodando simultaneamente. As operações estilo map/reduce do Claude Code se encaixam aqui. Isso é mais próximo do modelo de ator do que de um loop simples.

Minha opinião? Steinberger e Cherny estão descrevendo o segundo tipo, conectado ao primeiro. Os loops que eu rodo são programados e orientados por eventos por fora, e vários deles executam loops internos estilo experimento quando disparados. É essa combinação que entrega o valor real.

O Babá de PR: Minha Porta de Entrada para Design de Loops

Eu já tinha revisão de código por IA em todo pull request. Claude revisava primeiro, depois o Codex, depois uma GitHub Action customizada onde eu controlava exatamente o que o modelo via — puxando contexto completo da conversa mais o diff do patch.

Meu fluxo real era absurdo: submetia um PR, esperava as revisões voltarem, e então copiava e colava os comentários de revisão no agente. Às vezes colava screenshots. Era manual, repetitivo, e destruidor de alma.

Um dia perguntei ao meu agente: "Você não pode só usar o cliente gh e verificar o status da revisão sozinho?" Ele podia. Aí naturalmente perguntei: "Você não pode ficar verificando e me avisar quando terminar?"

Essa única solicitação transformou meu fluxo. O agente agora monitora mudanças de status das revisões, puxa novo contexto, analisa o feedback, e faz o trabalho real de abordá-lo. O loop termina quando chega a uma decisão de triagem: aceitar o feedback, questionar, ou escalar para mim.

O padrão generaliza muito bem: monitore mudanças de estado em sistemas externos, acorde quando acontecerem, puxe contexto fresco, analise, aja, e triaje. Uma vez que você enxerga essa forma, começa a encontrar em todo lugar. A equipe do Codex shipped seu próprio skill babysit-pr, e os docs do Claude Code agora citam babysitting de PR como caso de uso destaque para o comando /loop.

Loops Internos: Fazendo o Agente Rodar Seus Próprios Experimentos

Existe outro padrão de loop que eu demorei mais para appreciating: o loop de experimento. O conceito de autoresearch do Andrej Karpathy me fez pensar nisso — rodar muitas iterações, medir resultados, manter o que funciona. Apontei isso para um caminho lento em Python e rodei 49 experimentos em uma hora, reduzindo a latência p95 de 339ms para 34ms por cerca de $24.

O mesmo padrão se aplica a problemas mais difíceis: debugar comportamento de agentes em produção. Quando algo dá errado — um trace estranho no Braintrust, feedback de usuário no Slack, ou algo que eu mesmo encontro — subo um worktree, colo o trace, e invoco o loop de teste.

É o que torna esse loop diferente: ele força uma disciplina que a intuição ingênua do modelo resiste. Deixado sozinho, um modelo vai hardcodar "nunca faça X, Y, Z" no system prompt e overfitar para o único trace que você mostrou. As referências do skill destilam a pesquisa sobre por que essa abordagem falha, e o contrato do loop exige uma hipótese e uma matriz de testes.

Preciso de três casos: o caso original que falha, um positivo adjacente que deveria seguir o mesmo caminho, e um contraexemplo que deveria seguir um caminho diferente. Três ou quatro probes rodam concurrently contra dev local, reconstituindo o contexto exato do usuário do trace. Cada run é pontuada em tool calls, latência, delta de input tokens, e correção. O modelo não pode trapacear memorizando — precisa realmente entender.

O Que Realmente Muda Quando Você Constrói Loops

A maior mudança não é técnica — é conceitual. Quando você faz prompts para um agente, você ainda está no comando. Você é o acelerador, o navegador, o verificador de qualidade. Loops invertem isso. Você se torna o arquiteto de sistemas que se auto-gerenciam.

Isso não significa que autonomia total é o objetivo. Eu ainda estou no gate de triagem em tudo importante. Os loops lidam com o tedioso, o monitoramento, a repetição. Eu lido com os julgamentos que realmente importam.

A segunda mudança é que loops te forçam a ser explícito sobre critérios de sucesso. Um bom loop tem condições de saída claras, pontos de decisão claros, caminhos de escalação claros. Você não consegue construir um loop sem definir o que "pronto" significa. Essa disciplina permeia tudo.

Terceiro, loops são composáveis. O babá de PR trabalha junto com o loop de experimento. Verificações agendadas disparam respostas de plantão. Você começa a construir uma biblioteca de comportamentos que funcionam juntos ao invés de uma pilha de prompts únicos.

O Ponto de Partida Prático

Se você quer experimentar com loops, comece com algo que você já automatizou de forma precária. Você provavelmente tem uma GitHub Action que faz algo em.schedule, ou uma sessão do Claude Code que você re-roda manualmente, ou um processo de revisão que envolve copiar e colar outputs entre ferramentas.

Escolha o mais irritante. Pergunte a si mesmo: que mudança de estado eu estou esperando? Que contexto o agente precisa quando essa mudança acontece? Que decisão ele precisa tomar?

Aí construa o loop. Não precisa ser elegante. Precisa funcionar, e precisa te devolver o controle do seu próprio tempo.

As configs completas, skills e workflow de CI por trás dos loops que eu rodo estão num repo snapshot público: camwest/agent-skills. Não é um produto polido — é um sistema funcional que evolui conforme eu aprendo. Esse é o ponto. Loops não são um destino; são uma prática.

O discurso sobre agentes de IA está afundando em abstração. Aqui está a versão concreta: pare de fazer prompts, comece a construir loops, e veja o que acontece quando você deixa a máquina cuidar do monitoramento enquanto você cuida do que importa.