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.

Abaixo você pode ler alguns dos meus pensamentos (escritos com a ajuda do Claude) a partir de alguns experimentos, pesquisas e conversas que tive com alguns de nossos alunos, fundadores técnicos, engenheiros de IA e startups.

Você também pode achar nossa sessão ao vivo recente sobre "Agentes de Codificação Autônomos de Longa Duração" um bom ponto de partida para tudo isso.*

De onde vem a afirmação

"Você não deveria mais estar dando prompts para agentes de codificação. Você deveria estar projetando loops que dão prompts para seus agentes."Peter Steinberger (

@steipete ), 7 de Junho de 2026. 2.2M visualizações.

Tweet original

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

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

@bcherny ).

Tweet original

O ponto não é que a engenharia de prompt está morta. Com a engenharia de loop, 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 de fato

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

• dá o prompt para o agente de codificação por 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: defina um objetivo, aja, verifique, alimente o erro de volta e repita até que a verificação passe ou o loop pare sozinho.

"Loop" significa pelo menos cinco coisas

Grande parte da discordância é pessoas usando 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 objetivo autopromptado, notório por não saber quando parar.
• loop ralph. Um reset deliberado de contexto entre iterações para que o agente não se afogue em seu próprio histórico.
• /loop e /goal. A cadência e as condições de 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 partes 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 partes aparecem todas as vezes, e a maioria agora vem integrada nas ferramentas de codificação em vez de scripts personalizados que você mantém.

• Um gatilho. Algo que inicia o loop sem você apertar o play: 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 sobrescrevam 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 toda execução. Pule isso, e o loop redescobre seu projeto do zero a cada passada 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 postar o resultado em vez de imprimir uma correção e esperar que você a leve até o fim.
• Um segundo agente verifica. Um trabalhador 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 essas seis, e você tem um bom ponto de partida para a engenharia de loop. Antes você construía tudo manualmente; agora a maioria 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 PR babysitter

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 está vermelho por um motivo determinístico, tente uma correção. Se a main avançou, 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 para PRs mesclados em vez de um backlog de builds quebradas. A mesma forma cobre a maioria dos trabalhos de operações:

• Saúde do CI. A cada 30 minutos, puxe execuções com falha e agrupe-as por assinatura, para 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 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 grupo para o arquivo ou documento ao qual pertence.

Um loop concreto do Claude Code com /goal

O babysitter é um loop que você mesmo conecta; também ajuda ver um que já vem dentro do agente. No Claude Code, o menor loop completo é /goal: você entrega a ele um estado final verificável, e ele continua dando turnos 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 então 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 soa menos como um prompt e mais como 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. Deixe qualquer um deles vago, e 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. O primeiro turno começa imediatamente.
• O agente trabalha um turno. Ele edita, executa os testes e exibe os resultados na sessão.
• Um avaliador verifica. Um modelo rápido lê o transcript e decide se foi atendido ou não, para que o agente não esteja avaliando seu próprio trabalho.
• Loop ou finalizar. Não atendido significa outro turno com orientação; atendido significa que o objetivo se limpa e a execução para.

O estado é transportado entre os turnos, para que ele não desista cedo ou abandone 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 turnos" para que um loop travado pare em vez de queimar turnos.
• Combine com o modo auto para que os turnos sejam executados sem supervisão, e use /goal clear para abandoná-lo mais cedo.

A etapa do avaliador esconde uma sutileza útil: o verificador não precisa ser o mesmo modelo que o codificador. Assim que o loop tem papéis distintos (planejador, executor, avaliador, revisor de visão), cada um pode rodar em um modelo diferente, e escolher qual modelo preenche qual papel 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 de forma mais barata, alguns 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 único fornecedor ganhe 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), backlogs de issues (trabalhar uma fila etiquetada até ficar vazia) e loops de avaliação (ajustar um prompt até que a pontuação ultrapasse um limite). /loop é a contraparte para o trabalho sem uma única linha de chegada: em vez de uma condição de conclusão, ele re-prompt em um agendamento, que é como um loop como o babysitter de PR 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 os riscos, porque um loop é tão confiável quanto sua capacidade de verificar seu próprio trabalho. A configuração de Cherny para rodar Opus autonomamente por horas se resume a cinco passos:

1. Auto-aprovar permissões para que o agente não pare para perguntar em cada chamada de ferramenta.
2. Use fluxos de trabalho dinâmicos (adicione Ultracode ao prompt) para distribuir entre muitos agentes em vez de uma única thread serial.
3. Use /goal ou /loop para mantê-lo em andamento. /goal define uma condição de conclusão, /loop re-prompt em um agendamento, e ambos carregam o estado, então não desistem cedo.
4. Execute na nuvem (aplicativo de desktop ou celular) para que a sessão sobreviva quando você fechar o laptop.
5. Dê a ele uma maneira de se auto-verificar de ponta a ponta. Claude no Chrome para web, um MCP simulador para celular e um servidor ao vivo para backend. Este é o passo que torna os outros quatro seguros.

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 · auto-verificar, 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 anunciado como "controle de missão para execuções de agentes", é um loop empacotado como um 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, um issue do GitHub ou um PR, e depois passam por a fazer, em execução, 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 do tipo "disparar e esquecer". Cada execução é uma tentativa rastreada com heartbeats, então continua quando você desvia o olhar e sobrevive 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 é executado 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 roteirizar manualmente toda vez.

Para onde o custo vai agora

Por dois anos, a questão de custo na codificação com 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 gira, então um loop que tenta seis vezes antes de convergir custa seis vezes mais do que um que acerta na primeira passada, no mesmo modelo.

Isso muda o que vale a pena otimizar:

• As iterações são a linha de orçamento, não os tokens. Um modelo mais barato que faz loop com o dobro da frequência não é mais barato, então 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" é frouxa, o loop para cedo em trabalho quebrado ou insiste 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 custo. Um loop sem limite de 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 código.

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 giro em falso. Pule nestes casos:

• Edições únicas. Se você pode terminar em uma única passada, um loop é pura sobrecarga.
• Trabalho não escopado ou exploratório. "Descobrir por que os usuários estão desistindo" 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, você não removeu o trabalho, apenas o adiou.
• Lacunas de compreensão aumentam. 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 toda iteração, então o loop parece produtivo enquanto cava um buraco.

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

Como construir o seu próprio

1. Escolha uma tarefa repetível. Monitorar PRs, consertar CI, verificar deploys: comece com trabalho rotineiro.
2. Escopo restrito. "Corrigir a validação do webhook de cobrança, tocar apenas em app/api/billing e lib/billing" é melhor que "corrigir o bug." Um loop solto vagueia.
3. Dê a ele um orçamento e uma condição de parada. Máximo de tentativas, máximo de tempo de execução, máximo de arquivos, máximo de gastos, máximo de falhas consecutivas. Um loop sendo executado 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ê encontrar 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 autonomamente