De Agentes de Prompting à Engenharia de Loops

A claim has been circulating in AI coding circles: stop prompting your coding agents and start designing loops that prompt them for you. As with everything new, this stuff gets repeated often and explained rarely. This is the practical version: what an agent loop is, why it matters, and what one looks like in production.

Below you can read some of my thoughts (written with the help of Claude) from some of the experiments, research, and conversations I’ve been having with some of our students, technical founders, AI engineers, and startups.

You might also find our recent live session on "Autonomous Long-Running Coding Agents" as a good starting point for all of this.

De onde vem essa alegação

"Você não deveria mais dar prompts para agentes de codificação. Você deveria projetar loops que deem prompts aos seus agentes."Peter Steinberger (

@steipete ), 7 de junho de 2026. 2,2 milhões de visualizações.

Tweet original

Boris Cherny, o criador do Claude Code, faz o mesmo ponto do outro lado.

"Não dou mais prompts para o Claude. Tenho loops rodando. São eles que estão dando prompts ao Claude e descobrindo o que fazer. Meu trabalho é escrever loops."Boris Cherny (

@bcherny ).

Tweet original

O ponto não é que a engenharia de prompts está morta. Com a engenharia de loops, o trabalho sobe um nível, de escrever o código para escrever o sistema que escreve o código. Os desenvolvedores mais avançados nesse caminho relatam meses em que enviaram centenas de PRs sem abrir uma IDE, com cada linha escrita pelo agente.

O que um loop realmente é

Um loop é um pequeno programa que você escreve e que faz quatro coisas:

• dá o prompt ao agente de codificação para você,
• lê o que ele produziu,
• decide se está pronto,
• e, se não estiver, dá o prompt novamente com o erro ou o próximo passo.

Você para de ficar dentro do loop digitando prompts; você escreve o loop, e o modelo se torna uma sub-rotina que ele chama.

A forma é sempre a mesma: definir um objetivo, agir, verificar, realimentar o erro e repetir até que a verificação seja aprovada ou o loop pare sozinho.

"Loop" significa pelo menos cinco coisas

Grande parte do desacordo é as pessoas usarem uma palavra para cinco ideias diferentes. Aqui está a progressão, da mais antiga para a mais nova.

• ReAct (2022). O padrão de pesquisa original: raciocinar, agir, observar, repetir.
• AutoGPT (2023). Um loop de objetivos autoprompted, notório por não saber quando parar.
• ralph loop. Uma redefinição de contexto deliberada entre iterações para que o agente não se afogue em seu próprio histórico.
• /loop e /goal. Condições de cadência e conclusão são incorporadas ao agente, carregando o estado entre as rodadas.
• orquestração. Um autor distribui muitos agentes que leem seu GitHub, Slack e chat, e decidem o que construir em seguida.

As peças que você realmente monta

A progressão explica o que as pessoas querem dizer com loop; isto é do que um loop é construído. As mesmas seis peças aparecem sempre, e a maioria agora já vem embutida nas ferramentas de codificação, em vez de scripts personalizados que você mesmo mantém.

• Um gatilho. Algo que inicia o loop sem você apertar "ir": um agendamento, um webhook, uma alteração de arquivo, um label caindo em um PR. Isso é o que separa um loop real de uma execução única que você repete manualmente.
• Isolamento. Um checkout privado por agente, geralmente um git worktree, para que dois agentes rodando ao mesmo tempo não possam sobrescrever os arquivos um do outro. Assim que você roda mais de um, isso deixa de ser opcional.
• Contexto escrito. As convenções, etapas de build e regras específicas do projeto são mantidas onde o agente as lê em cada execução. Pule isso, e o loop redescobre seu projeto do zero a cada passagem e adivinha as lacunas.
• Alcance em suas ferramentas. Conectores para o rastreador de issues, CI, banco de dados e chat, para que o loop possa abrir o PR, vincular o ticket e publicar o resultado, em vez de imprimir uma correção e esperar que você a leve até o fim.
• Um segundo agente verifica. Um worker separado que avalia a saída é mantido separado daquele que a produziu, porque um modelo revisando seu próprio trabalho aprova quase tudo.
• Estado em disco. Um arquivo markdown, um quadro ou uma fila: qualquer coisa fora da conversa que registre o que está concluído e o que vem a seguir. O modelo esquece entre as execuções; o arquivo não.

Monte esses seis e você terá um bom ponto de partida para engenharia de loops. Antes, você construía tudo manualmente; agora, a maioria já vem como recursos integrados, e é por isso que o padrão passou de uma técnica de nicho para uso comum.

Um loop concreto, o babysitter de PRs

Um exemplo concreto que você pode construir hoje:

• Gatilho. A cada 15 minutos.
• Escopo. PRs abertos com o label agent-watch.
• Ação. Se o CI estiver vermelho por um motivo determinístico, tente uma correção. Se o main mudou, faça rebase uma vez.
• Orçamento. Uma tentativa de correção por PR, cinco minutos, dez arquivos alterados.
• Condição de parada. CI verde, ou orçamento esgotado, então pare e notifique um humano.

Você retorna a PRs mesclados em vez de um acúmulo de builds quebradas. A mesma forma cobre a maioria do trabalho de operações:

• Saúde do CI. A cada 30 minutos, puxe as execuções com falha e agrupe-as por assinatura, de modo que dez PRs vermelhos com uma causa raiz se tornem uma coisa para olhar.
• Verificação de deploy. Após um push, acesse seus endpoints, confirme os 200s e o conteúdo esperado e sinalize regressões antes que os usuários o façam.
• Agrupamento de feedback. A cada 30 minutos, puxe comentários de seus canais, agrupe-os em temas e mapeie cada cluster para o arquivo ou documento que o possui.

Um loop concreto do Claude Code com /goal

O babysitter é um loop que você mesmo configura; também ajuda ver um que já vem embutido no agente. No Claude Code, o menor loop completo é /goal: você entrega um estado final verificável, e ele continua agindo até que esse estado seja verdadeiro.

Aqui está um exemplo de /goal usado como um comando dentro da sessão no Claude Code. Você inicia a sessão e define o objetivo dentro dela:

1$ claude  # inicia o Claude Code
2$ /goal tests in test/auth pass   # define o objetivo dentro da sessão

É a mesma forma de agir, verificar, repetir de antes, com o verificador embutido.

Neste ponto, fica claro que um /goal forte se parece menos com um prompt e mais com um contrato. Os bons especificam quatro coisas: o estado final que você deseja, a evidência que prova que você o alcançou, as restrições que o agente não deve quebrar para chegar lá e o orçamento de trabalho que ele pode gastar. Se deixar qualquer um deles vago, o modelo preenche a lacuna com a leitura mais fácil: ele para cedo, toma um atalho ou redefine o sucesso para que o transcript pareça concluído enquanto o sistema real está quebrado.

• Defina a condição. Digite /goal mais um estado final verificável, por exemplo, /goal tests in test/auth pass. A primeira rodada começa imediatamente.
• O agente trabalha em uma rodada. Ele edita, executa os testes e apresenta os resultados na sessão.
• Um avaliador verifica. Um modelo rápido lê o transcript e decide se foi atendido ou não atendido, para que o agente não esteja avaliando seu próprio trabalho.
• Loop ou finalização. Não atendido significa outra rodada com orientação; atendido significa que o objetivo se limpa e a execução para.

O estado é transportado entre as rodadas, para que não pare cedo ou descarte uma restrição no meio do caminho. Alguns controles o mantêm confiável:

• Torne a verificação mensurável. Um resultado de teste, um código de saída, uma contagem de arquivos ou uma fila vazia. "npm test exits 0" é um objetivo; "melhorar" não é.
• Limite a execução. Acrescente algo como "ou pare após 20 rodadas" para que um loop travado pare em vez de queimar rodadas.
• Combine com o modo auto para que as rodadas sejam executadas sem supervisão e use /goal clear para abortá-lo precocemente.

A etapa do avaliador esconde uma sutileza útil: o verificador não precisa ser o mesmo modelo que o codificador. Uma vez que o loop tem funções distintas (planejador, executor, avaliador, revisor de visão), cada uma pode rodar em um modelo diferente, e escolher qual modelo preenche qual função se torna uma decisão de arquitetura, em vez de uma aposta única em um agente de codificação "melhor". Alguns modelos planejam melhor, outros executam mais barato, outros julgam uma captura de tela com mais precisão, e um bom orquestrador permite que você os troque por função, em vez de esperar que um fornecedor vença em todas as categorias.

Funciona bem para migrações de API (mover cada ponto de chamada até compilar e os testes passarem), refatorações (dividir um arquivo até que cada módulo esteja dentro do orçamento), pendências de issues (trabalhar uma fila com label até que esteja vazia) e loops de avaliação (ajustar um prompt até que a pontuação ultrapasse um limite). /loop é a contraparte para trabalhos sem uma única linha de chegada: em vez de uma condição de conclusão, ele dá um novo prompt em um cronograma, que é como um loop como o babysitter de PRs continua rodando.

Executando muitos loops sem supervisão

Um único loop /goal é um agente trabalhando em direção a uma única linha de chegada. Executar muitos processos não supervisionados aumenta a aposta, porque um loop é tão confiável quanto sua capacidade de verificar seu próprio trabalho. A configuração de Cherny para executar o Opus de forma autônoma por horas se resume a cinco etapas:

1. Aprovar permissões automaticamente para que o agente não pare para perguntar em cada chamada de ferramenta.
2. Usar fluxos de trabalho dinâmicos (inserir o Ultracode no prompt) para distribuir por muitos agentes em vez de uma única thread serial.
3. Usar /goal ou /loop para mantê-lo em execução. /goal define uma condição de conclusão, /loop dá um novo prompt em um cronograma, e ambos carregam o estado, para que não parem cedo.
4. Executá-lo na nuvem (aplicativo de desktop ou celular) para que a sessão sobreviva quando você fechar o laptop.
5. Dar a ele uma maneira de se autoverificar de ponta a ponta. Claude no Chrome para web, um MCP de simulador para celular e um servidor ao vivo para backend. Esta é a etapa que torna as outras quatro seguras.

A sequência completa:

1claude --permission-mode auto                          # 1 · sem prompts de aprovação
2ultracode  orchestrate sub-agents to ship the feature  # 2 · distribuir
3/goal all tests pass and the demo loads clean          # 3 · continuar
4→ cloud / desktop app                                  # 4 · fechar o laptop
5→ chrome ext · sim MCP · live server                   # 5 · autoverificar, então parar

crabfleet: orquestração como produto

A orquestração é mais fácil de visualizar com uma ferramenta concreta. O crabfleet de Peter Steinberger, um projeto OpenClaw descrito como "controle de missão para execuções de agentes", é um loop empacotado como produto, e sua forma se mapeia em tudo acima.

• Trabalho como cards em um quadro. As tarefas são inseridas como cards construídos a partir de um prompt, uma issue do GitHub ou um PR, e então se movem através de "a fazer", "rodando", "revisão humana" e "concluído". Esse quadro é a fila do loop e sua etapa de parar e relatar, tornada visível.
• Execuções duráveis, não "dispare e esqueça". Cada execução é uma tentativa rastreada com heartbeats, para que continue quando você desviar o olhar e sobreviva a um laptop fechado. Você assume o controle apenas quando o runtime anuncia que suporta handoff.
• Agentes que geram agentes. Uma execução pode iniciar sessões filhas, enviar mensagens, ler transcripts e atualizar seu próprio resumo de dentro de um sandbox: memória em disco e distribuição em um só lugar, um autor e muitos agentes.

Ele roda em sandboxes de nuvem descartáveis com terminais baseados em navegador, que é o que torna seguro se afastar de uma execução não supervisionada. O ponto não é a ferramenta específica, mas que o loop se solidificou em infraestrutura: uma fila, execução durável, distribuição e um portão de revisão humana são agora coisas que você configura em vez de escrever scripts manualmente toda vez.

Para onde o custo vai agora

Por dois anos, a questão de custo na codificação de IA era simples: qual modelo e quantos tokens. Dentro de um loop, esse instinto aponta para a camada errada. O gasto não é mais uma única chamada, mas quantas vezes o loop dá a volta, então um loop que tenta seis vezes antes de convergir custa seis vezes mais do que um que acerta na primeira passagem, no mesmo modelo.

Isso muda o que vale a pena otimizar:

• Iterações são a linha de orçamento, não tokens. Um modelo mais barato que faz o loop com o dobro da frequência não é mais barato, portanto, acompanhe o custo por tarefa concluída, não o custo por chamada.
• Um verificador fraco é o bug mais caro que você pode enviar. Se a verificação que decide "concluído" for frouxa, o loop para cedo em trabalho quebrado ou continua em trabalho que já estava bom, e ambos desperdiçam iterações inteiras. Aperte isso antes de qualquer outra coisa.
• Falhar rápido é um controle de custos. Um loop sem limite para falhas consecutivas não eventualmente tem sucesso; ele eventualmente drena a conta, então a condição de parada protege a conta tanto quanto o codebase.

Antes, você ajustava o prompt; agora, você ajusta o loop, porque é aí que o custo se acumula.

Quando não usar loop

Loops compensam quando uma tarefa se repete e uma máquina pode dizer quando está concluída. Fora disso, um loop apenas automatiza o atrito. Pule nestes casos:

• Edições únicas. Se você pode terminar em uma única passagem, um loop é pura sobrecarga.
• Trabalho não escopo ou exploratório. "Descobrir por que os usuários estão cancelando" não tem condição de aprovação, então o loop nunca converge.
• Qualquer coisa sem uma verificação automatizada barata. Se o único verificador são seus próprios olhos, você ainda está dentro do loop. Construa a verificação primeiro ou faça a tarefa manualmente.

O que pode dar errado

Um loop que roda enquanto você dorme também comete erros enquanto você dorme, e os modos de falha são previsíveis.

• O fardo da verificação permanece humano. O loop escreve mais rápido do que você pode revisar, então, se você parar de ler os diffs, não removeu o trabalho, apenas o adiou.
• Lacunas de compreensão se alargam. Enviar código que você não escreveu, mais rápido do que você pode absorver, corrói o modelo do seu próprio sistema, e essa dívida vence durante o próximo incidente.
• Deriva silenciosa em uma verificação frouxa. Um verificador fraco deixa passar trabalho errado, mas "aprovado", em cada iteração, então o loop parece produtivo enquanto cava um buraco.

Nada disso é um argumento contra loops; é por que o engenheiro que projeta o loop importa mais, e não menos.

Como construir o seu próprio

1. Escolha uma tarefa repetível. Fazer babysitting de PRs, corrigir CI, verificar deploys: comece com trabalho de rotina.
2. Defina um escopo restrito. "Corrigir a validação do webhook de cobrança, tocar apenas em app/api/billing e lib/billing" é melhor do que "corrigir o bug". Um loop frouxo vagueia.
3. Dê a ele um orçamento e uma condição de parada. Máximo de tentativas, tempo de execução máximo, máximo de arquivos, máximo de gastos, máximo de falhas consecutivas. Um loop rodando sem supervisão é também um loop cometendo erros sem supervisão.
4. Adicione um verificador independente. Um subagente separado avalia o trabalho, porque o agente que escreveu o código é o pior juiz para saber se está pronto.
5. Execute-o em uma cadência. /loop para um intervalo, cron para um agendamento, hooks em pontos do ciclo de vida ou GitHub Actions para que sobreviva a um laptop fechado.
6. Mantenha a memória em disco. O modelo esquece entre as execuções, então o estado vive em markdown ou um quadro, não na janela de contexto.

A conclusão: o loop, não o modelo, é agora a parte cara e propensa a falhas. Construa-o como alguém que pretende continuar sendo o engenheiro responsável pela saída, não apenas a pessoa que inicia a execução.

Se você vir algum erro ou algo que precise de mais esclarecimento, não hesite em entrar em contato.

Outras Referências Úteis

• Addy Osmani (@addyosmani), sobre loops de codificação assistidos por IA
• Matt Van Horn (@mvanhorn), "WTF Is a Loop?"
• Peter Steinberger (@steipete), sobre projetar loops
• Boris Cherny (@bcherny), sobre executar agentes de forma autônoma