Engenharia de Loop: Por que o criador do Claude Code diz que não usa mais prompts

Eu não dou mais prompts para o Claude. Tenho loops rodando que dão prompts para o Claude e decidem o que fazer. Meu trabalho é escrever loops.

— Boris Cherny, criador e chefe do Claude Code na Anthropic.

Por cerca de dois anos, a habilidade que todos buscavam era a engenharia de prompts. Escrever um bom prompt, compartilhar contexto suficiente, ler a saída, escrever o próximo prompt. Você segurava o agente como uma ferramenta, um turno de cada vez.

Essa era está silenciosamente terminando.

Em meados de 2026, três vozes convergiram para a mesma ideia em questão de dias. Boris Cherny (Claude Code) disse que seu trabalho agora é escrever loops. Peter Steinberger (criador do OpenClaw) disse a milhões de desenvolvedores: "Você não deveria mais dar prompts para agentes de codificação. Você deveria projetar loops que dão prompts para seus agentes." E Addy Osmani (Google) deu nome ao padrão em uma postagem amplamente compartilhada: Loop Engineering. Este artigo detalha o que realmente é a engenharia de loops, os problemas que ela resolve, como os resolve, uma demonstração de código funcional que você pode executar hoje e as compensações honestas que ninguém coloca nos tópicos de hype.

O Que É Loop Engineering?

Loop engineering é substituir a si mesmo como a pessoa que dá o prompt ao agente. Você projeta um sistema que faz o prompting em seu lugar.

Um loop é um objetivo recursivo: você define um propósito e uma condição de parada verificável, e a IA itera, descobre trabalho, implementa, verifica, registra o progresso até que a condição seja verdadeira. Você não está mais dentro do loop. Você está acima dele.

Pense na hierarquia assim:

1. Engenharia de prompts: você escreve uma boa instrução.
2. Engenharia de contexto: você monta as informações certas ao redor da instrução.
3. Engenharia de harness do agente: você constrói o ambiente dentro do qual um agente é executado.
4. Loop engineering: você constrói o sistema que executa o harness em um temporizador, cria ajudantes, verifica seu trabalho.

O fluxo de trabalho antigo: escrever prompt → ler saída → escrever próximo prompt (você é o loop).

O novo fluxo de trabalho: projetar o loop uma vez → loop descobre trabalho → loop atribui agentes → loop verifica → loop registra estado → repete (você revisa e direciona).

Os Problemas Que o Loop Engineering Resolve

Problema 1: Você é o gargalo

No prompting manual, nada acontece a menos que você digite. Cada turno espera por um humano. Agentes em 2026 podem rodar por horas de forma autônoma; modelos da classe Claude Opus rodaram sem supervisão por quase cinco horas em tarefas difíceis, mas um chat conduzido por humanos os limita à sua velocidade de digitação e capacidade de atenção. O agente fica ocioso 95% do tempo, esperando por você.

Problema 2: Agentes esquecem tudo entre as sessões

Cada sessão começa do zero. O modelo redescobre as convenções do seu projeto, etapas de build e lições aprendidas a duras penas do zero — ou pior, preenche as lacunas com palpites confiantes. É o que Osmani chama de dívida de intenção: intenção não declarada que é paga (ou adivinhada) novamente a cada execução.

Problema 3: O agente corrige o próprio dever de casa

Um agente que escreveu o código é generoso demais ao revisá-lo. "Está pronto" é uma afirmação, não uma prova. Sem verificação independente, execuções autônomas acumulam erros em vez de corrigi-los.

Problema 4: Agentes paralelos colidem

No momento em que você executa mais de um agente em um repositório, eles começam a sobrescrever os arquivos uns dos outros — o mesmo desastre de dois engenheiros commitando nas mesmas linhas sem conversar.

Problema 5: Trabalho recorrente nunca é automatizado

Triagem de falhas de CI, atualizações de dependências, caça a testes instáveis, rotulagem de issues, varreduras diárias de bugs — esse trabalho é chato, interminável e perfeitamente adequado para agentes. Mas ninguém dá um prompt para um agente fazer isso toda manhã, porque você teria que aparecer toda manhã para fazer o prompting.

Como o Loop Engineering os Resolve: Os Seis Blocos de Construção

Um loop que realmente roda sem supervisão não é um prompt longo. É um pequeno sistema com cinco capacidades mais uma memória. Notavelmente, tanto o Claude Code quanto o Codex da OpenAI agora oferecem todos os seis nativamente — a forma do loop se tornou agnóstica em relação à ferramenta.

1. Automações: o batimento cardíaco

Execuções agendadas que fazem descoberta e triagem por conta própria. Isso resolve o Problema 5.

• Claude Code: /loop reexecuta um prompt em uma cadência (de intervalos de um minuto a janelas de vários dias), tarefas agendadas por cron, Rotinas para automações agendadas em nuvem, hooks de ciclo de vida ou GitHub Actions para execuções que sobrevivem ao fechamento do seu laptop.
• Codex: a aba Automações — escolha um projeto, um prompt, uma cadência; descobertas vão para uma caixa de entrada de Triagem; execuções vazias se arquivam sozinhas.

O primitivo matador dentro da sessão é /goal: continue trabalhando entre turnos até que uma condição que você escreveu seja verificavelmente verdadeira — "todos os testes em test/auth passam e o lint está limpo" — e vá embora.

1. Worktrees: isolamento para paralelismo

Git worktrees dão a cada agente seu próprio diretório de trabalho em seu próprio branch, compartilhando o histórico do repositório. Edições literalmente não podem colidir. Isso resolve o Problema 4.

• Claude Code: git worktree, a flag --worktree, ou isolation: worktree em um subagente para que cada ajudante receba um checkout novo e autolimpante.
• Codex: worktree embutido por thread.

Usuários avançados relatam executar de 10 a 15 agentes paralelos dessa forma.

1. Skills: conhecimento do projeto codificado

Uma skill é uma pasta com um SKILL.md — suas convenções, etapas de build e "não fazemos assim por causa daquele incidente" escritos uma vez, lidos pelo agente a cada execução. Isso resolve o Problema 2. Sem skills, o loop redescobre seu projeto do zero a cada ciclo. Com elas, ele se acumula.

1. Plugins e Conectores (MCP): mãos em ferramentas reais

Um loop que só vê o sistema de arquivos é um loop minúsculo. Conectores MCP permitem que ele leia seu rastreador de issues, consulte um banco de dados, abra o PR, atualize o ticket do Linear e avise no Slack quando o CI ficar verde. Essa é a diferença entre um agente que diz "aqui está a correção" e um loop que entrega a correção.

1. Subagentes: separe o criador do verificador

A ideia estrutural mais importante em todo o padrão. Um agente (ou modelo) escreve; um agente diferente com instruções diferentes verifica. Isso resolve o Problema 3. O /goal do Claude Code incorpora isso: um modelo separado avalia se a condição de parada foi atendida, para que o trabalhador nunca corrija o próprio dever de casa.

• Claude Code: subagentes em .claude/agents/, equipes de agentes.
• Codex: subagentes como TOML em .codex/agents/ — por exemplo, um modelo forte com alto esforço de raciocínio como seu revisor de segurança, um modelo rápido e somente leitura como seu explorador.

1. Estado: a espinha dorsal da memória

Um arquivo markdown, um registro de progresso ou um quadro do Linear — qualquer coisa que viva fora da conversa e registre o que foi feito e o que vem a seguir. Parece bobo demais para importar. É o único truque do qual todo agente de longa duração depende: o modelo esquece entre execuções; o repositório não. Isso também resolve o Problema 2 no nível da tarefa, e é o que permite que a execução de amanhã continue exatamente de onde a de hoje parou. Junto com as automações, isso dissolve o Problema 1 — o loop funciona enquanto você dorme.

A Aparência de Um Loop Real

Aqui está a forma de referência (adaptada do próprio loop diário de Osmani):

1. Uma automação é acionada no repositório. Seu prompt chama uma skill de triagem que lê as falhas de CI de ontem, issues abertas e commits recentes, e escreve as descobertas em STATE.md.
2. Para cada descoberta que vale a pena, o loop abre um worktree isolado e despacha um subagente criador para rascunhar a correção.
3. Um subagente verificador revisa o rascunho contra as skills do projeto e os testes existentes.
4. Conectores abrem o PR, vinculam o ticket e postam no Slack.
5. Qualquer coisa que o loop não possa tratar vai para uma caixa de entrada de triagem — para você.
6. STATE.md registra o que foi tentado, o que passou e o que ainda está aberto. A execução de amanhã retoma de lá.

Fontes e leitura adicional: Addy Osmani, "Loop Engineering" (addyosmani.com); Cobertura do The New Stack sobre engenharia de loops; Bate-papo de Boris Cherny na conferência Scale do Meta e entrevista à CNBC; Documentação do Claude Code sobre Rotinas (code.claude.com/docs/en/routines); Documentação de Automações do OpenAI Codex.

Se você construir um loop a partir deste artigo, adoraria ver!! Responda com o que você automatizou primeiro.