Em junho de 2026, três pessoas chegaram independentemente à mesma ideia em uma única semana.
Peter Steinberger, o criador do OpenClaw, disse publicamente que você deveria parar de dar instruções para agentes de codificação e começar a projetar os loops que os instruem. Quase ao mesmo tempo, Boris Cherny, que lidera o Claude Code na Anthropic, disse que não dá mais instruções diretamente ao Claude; ele tem loops rodando que instruem o Claude e descobrem o que fazer, e seu trabalho real é escrever loops. Dias depois, Addy Osmani, um engenheiro do Google, escreveu o termo e deu a ele um nome: engenharia de loops.
Nenhum deles inventou a prática do zero. Eles nomearam algo que já estava acontecendo, porque as ferramentas subjacentes haviam silenciosamente cruzado um limite. Os agentes de codificação se tornaram confiáveis o suficiente para concluir uma tarefa real sem supervisão. O agendamento se tornou barato o suficiente para que executar uma tarefa repetidamente, em um cronômetro, não parecesse mais um desperdício. O custo de uma única execução de agente caiu tanto que tentar algo cinco vezes custava menos do que pensar cuidadosamente sobre isso uma vez.
Esse limite é a razão pela qual este roteiro existe. Dar instruções era a habilidade quando um humano precisava sentar ao teclado direcionando um agente linha por linha. A engenharia de loops é a habilidade agora que o agente pode receber um objetivo e ser deixado para executar. Este é o caminho completo de 20 passos de um para o outro, em ordem, porque a ordem importa mais do que qualquer passo individual.
Aqui está o porquê de a ordem especificamente importar, antes dos próprios passos. A engenharia de loops não é uma habilidade única que você tem ou não tem. É uma pilha, onde cada camada depende daquela abaixo dela ser realmente sólida. Construir um gatilho de agendamento, passo 14, antes de ter uma condição de parada real, passo 10, significa apenas que você automatizou um sistema que agora pode desperdiçar dinheiro sem supervisão, em vez de apenas enquanto você está assistindo. Construir persistência, passo 11, antes de ter verificação real, passos 6 e 7, significa que você está registrando cuidadosamente lições aprendidas de um Juiz que pode estar carimbando saídas ruins, o que torna a camada de persistência ativamente prejudicial em vez de meramente inútil. Pular adiante nesta lista não significa apenas perder um recurso. Significa construir as partes de aparência interessante sobre uma base que não pode realmente suportá-las, e descobrir isso apenas quando algo já deu errado em escala.
Fase Um: A Mudança Mental (Passos 1 a 4)
Passo 1: Aceite Que Você É O Gargalo, Não O Modelo
O primeiro passo real não é técnico. É admitir que o fator limitante no seu fluxo de trabalho atual não é a capacidade do modelo, é a sua própria presença no loop. Cada vez que você se senta e espera por uma resposta, a lê e então digita a próxima instrução, você é a parte mais lenta do sistema por uma margem ampla. O modelo pode agir, verificar e tentar novamente muito mais rápido do que você pode supervisioná-lo fazendo isso.
Este passo não tem nenhum prompt anexado a ele. É uma decisão. Até que você realmente acredite nisso, cada passo subsequente parecerá uma sobrecarga desnecessária em vez do que realmente é: remover o gargalo real.
Passo 2: Pare De Confundir Um Prompt Mais Longo Com Um Sistema Melhor
O instinto quando algo dá errado é adicionar outra instrução ao mesmo prompt. Ao longo de meses, isso produz um prompt que é uma parede densa e autocontraditória de regras que o modelo não consegue mais manter na memória de trabalho de uma só vez, então ele corresponde ao padrão do que parece mais recente e descarta silenciosamente o resto.
A engenharia de loops substitui esse instinto completamente. Em vez de adicionar outra regra a um prompt, você adiciona outro componente a um sistema. Uma etapa de verificação. Um arquivo de memória. Um gatilho agendado. O prompt em si deve ficar mais curto ao longo do tempo à medida que o sistema ao seu redor se torna mais capaz, e não o contrário.
Passo 3: Aprenda A Ver Cada Tarefa Como Cinco Movimentos
Qualquer turno único de um loop, independentemente do domínio específico, decompõe-se em cinco movimentos. Descoberta, descobrir o que realmente precisa acontecer. Transferência, passar a tarefa para quem vai executá-la. Verificação, verificar o resultado contra algo real. Persistência, registrar o que aconteceu para que não se perca. Agendamento, decidir quando isso é executado novamente.
A maioria dos fluxos de trabalho atuais das pessoas tem apenas dois desses movimentos explícitos, descoberta e transferência, feitos manualmente, em uma janela de chat. Os outros três ou não existem ou acontecem invisivelmente na própria cabeça da pessoa. A engenharia de loops é a prática de tornar todos os cinco movimentos explícitos e automáticos.
Passo 4: Identifique Sua Primeira Tarefa Candidata Real
Antes de construir qualquer coisa, escolha uma tarefa que você já faz repetidamente, com um padrão que você poderia escrever se lhe pedissem. Não o seu problema mais difícil. Não algo completamente novo. Uma tarefa com uma definição de pronto real e reconhecível, algo que um colega pudesse olhar e concordar imediatamente se foi ou não concluída corretamente. Essa restrição importa mais do que parece. Uma tarefa sem uma definição clara de pronto não pode ter o passo três, verificação, construído para ela, e um loop sem verificação real não é um loop, é apenas um palpite sem supervisão.
Fase Dois: Construindo O Primeiro Loop (Passos 5 a 9)
Passo 5: Escreva A Definição De Pronto Antes De Escrever Qualquer Prompt
Este é o passo que a maioria das pessoas pula e aquele que determina se tudo depois funciona. Antes de escrever uma única instrução para o agente, escreva, em linguagem simples, exatamente como um resultado correto se parece. Critérios específicos e verificáveis, não uma vaga sensação de qualidade.
DEFINIÇÃO DE PRONTO para [nome da tarefa]:
- [Critério específico e verificável 1]
- [Critério específico e verificável 2]
- [Critério específico e verificável 3] Esta tarefa NÃO está pronta se algum dos itens acima estiver faltando, mesmo que a saída pareça completa ou polida.
Se você não conseguir preencher isso para a tarefa escolhida, volte ao passo 4 e escolha uma diferente.
Passo 6: Separe O Construtor Do Juiz
A decisão arquitetural mais importante em qualquer loop. O papel que produz o trabalho e o papel que verifica o trabalho devem ser separados, porque um modelo revisando sua própria saída no mesmo fôlego que a produziu tende a defender essa saída em vez de examiná-la genuinamente.
O Construtor recebe latitude criativa e produz uma primeira tentativa. O Juiz recebe a saída do Construtor mais a definição de pronto do passo 5, e nada mais do que precisa ser convencido. Idealmente, o Juiz também tem acesso a algo que o Construtor não tem, um conjunto de testes, o documento de origem original, dados ao vivo, para que seu veredito venha de evidências reais, não apenas uma segunda opinião formada da mesma maneira que a primeira foi.
Passo 7: Dê Ao Juiz Verdade Terrena, Não Apenas Uma Opinião
Um Juiz que só vê a saída do Construtor pode lhe dizer se parece coerente. Não pode lhe dizer se está realmente correto. Para tarefas de codificação, a verdade terrena é o conjunto de testes e a saída de execução real. Para tarefas de conteúdo, é o material de origem original e o briefing, lado a lado com o rascunho. Para tarefas de pesquisa, são os documentos reais que deveriam ser usados.
Se você não consegue nomear a verdade terrena específica que seu Juiz verificará, seu loop ainda não tem verificação real, não importa o quão confiante a linguagem do Juiz soe.
Passo 8: Escreva O Formato De Transferência Antes De Escrever O Prompt De Transferência
A saída do Construtor e o veredito do Juiz precisam de uma estrutura definida, não de prosa de fluxo livre, ou o Gerente no próximo passo não terá nada confiável para rotear.
SAÍDA DO CONSTRUTOR: entregável + confiança + incertezas conhecidas
VEREDITO DO JUIZ: APROVADO / REPROVADO / PRECISA DE REVISÃO + problemas específicos encontrados +
qual verdade terrena foi verificada contra isso
Passo 9: Execute Manualmente Uma Vez, Completamente, Antes De Automatizar Qualquer Coisa
Antes de configurar o agendamento ou tentativas automáticas, execute a sequência completa Construtor-depois-Juiz você mesmo, manualmente, uma vez. Leia o veredito do Juiz criticamente. Você teria concordado com ele? Se o Juiz aprovou algo que você sabe que está errado, ou reprovou algo que estava realmente correto, corrija a verdade terrena ou os critérios antes de prosseguir. Automatizar uma etapa de verificação quebrada apenas produz resultados quebrados mais rapidamente.
Um Exemplo Prático Através Dos Passos 5 A 9
Para tornar os últimos cinco passos concretos, aqui está como eles se desenrolam em uma tarefa real e comum: transformar um documento de origem bruto em uma peça de conteúdo finalizada.
A definição de pronto, do passo 5: toda afirmação factual no rascunho remonta a algo realmente presente no documento de origem. O rascunho satisfaz todos os requisitos específicos no briefing, extensão, tom, estrutura exigida. O argumento central sobrevive claramente, sem ser diluído por preenchimento.
O Construtor, do passo 6, recebe a fonte e o briefing e produz um rascunho, junto com uma declaração explícita do que não tinha certeza ao escrever, um número que não tinha total certeza de estar na fonte, uma afirmação que inferiu em vez de encontrar declarada de forma direta.
O Juiz, do passo 7, recebe o rascunho e a fonte original lado a lado, nunca o rascunho sozinho, e verifica cada um dos três critérios da definição de pronto separadamente, retornando uma aprovação ou reprovação em cada um individualmente, em vez de uma pontuação geral combinada. Colapsar três verificações distintas em um único veredito esconde exatamente qual dimensão realmente falhou, que é a maneira mais comum de um loop funcional parar silenciosamente de dar feedback útil.
O formato de transferência, do passo 8, significa que o veredito do Juiz chega como um objeto estruturado, não um parágrafo de prosa hesitante, três resultados explícitos de aprovação ou reprovação com uma razão específica anexada a qualquer falha.
Executar isso manualmente uma vez, de acordo com o passo 9, antes de automatizar qualquer coisa, é o que pega o caso em que seu Juiz é muito indulgente, aprovando um rascunho com uma estatística fabricada porque o estilo de escrita era polido, ou muito rigoroso, reprovando um rascunho por uma preferência estilística que nunca esteve realmente no briefing. Ambos os modos de falha são comuns em uma primeira tentativa, e ambos são muito mais baratos de pegar manualmente uma vez do que descobrir depois que o loop já foi executado cinquenta vezes sem supervisão.
Fase Três: Adicionando As Peças Faltantes Do Loop (Passos 10 a 14)
Passo 10: Construa O Gerente E Sua Condição De Parada
O Gerente lê o veredito do Juiz e decide o que acontece em seguida. É aqui também que a condição de parada do loop vive, e deve ser escrita como lógica rígida, não uma instrução suave que o modelo pode argumentar contra.
CONDIÇÕES DE PARADA:
Revisões máximas: 3. No 3º veredito reprovado, encaminhe para um humano
com o histórico completo, não tente um 4º ciclo.
Limiar de qualidade: cada item na definição de pronto deve mostrar APROVADO.
Teto de orçamento: se esta tarefa exceder [X] custo ou [Y] tempo, pare
imediatamente, independentemente do estado atual.
Um loop sem uma condição de parada real não é um sistema. É um passivo esperando o dia em que a tarefa se revela genuinamente insolúvel. A razão específica pela qual uma instrução suave falha aqui vale a pena ser entendida, não apenas aceita. "Pare quando estiver bom o suficiente" dentro de um prompt é uma sugestão, e um modelo sob pressão suficiente, tendo falhado várias revisões, muitas vezes se convencerá de que a tentativa atual é boa o suficiente para passar, precisamente porque quer produzir uma resolução satisfatória para a tarefa. Um contador de iteração rígido verificado mecanicamente por código, ou por uma regra explícita que o Gerente não pode contornar, não tem esse modo de falha.
Passo 11: Adicione Persistência, Para Que O Loop Lembre Entre Execuções
Um loop que começa do zero toda vez que é executado não tem memória do que aprendeu da última vez. Adicione uma camada de persistência simples, um arquivo por lição genuinamente nova, com um resumo de uma linha no topo, registrando o que foi aprendido ou corrigido e por que importou. Criticamente, registre apenas o que ainda não está capturado em outro lugar, memória duplicada é ruído, não conhecimento.
A disciplina que faz este passo funcionar a longo prazo é a contenção no momento da escrita. O instinto é registrar tudo o que aconteceu em uma sessão, o que produz exatamente o problema de transcrição inchada contra o qual este roteiro advertiu no passo 2, apenas movido para uma pasta de memória em vez de um prompt. Uma lição que vale a pena escrever é algo que custaria tempo real para redescobrir se esquecido, não um registro de trabalho de rotina que teve sucesso exatamente como esperado.
Passo 12: Adicione Uma Passagem De Consolidação Em Um Cronograma
A persistência sozinha eventualmente produz o mesmo problema que um prompt inchado, dezenas de arquivos, muitos dizendo versões ligeiramente diferentes da mesma coisa. Em um cronograma recorrente, semanalmente é razoável, revise os arquivos de memória, mescle duplicatas em lições únicas e mais nítidas, e exclua qualquer coisa que desde então se provou errada. O objetivo é menos arquivos com mais densidade cada, não uma pilha sempre crescente.
Este passo é o que a maioria das pessoas pula completamente, porque não produz nenhuma nova capacidade visível por si só, apenas previne um problema futuro. Essa invisibilidade é exatamente por que ele precisa ser agendado explicitamente, em vez de deixado para acontecer quando alguém perceber que a pasta de memória ficou difícil de manejar, o que na prática significa que nunca acontece até que o desempenho do loop já tenha começado a degradar sob o peso de lições contraditórias e semi-relevantes competindo pela mesma janela de contexto.
Passo 13: Adicione A Etapa De Recuperação
No início de qualquer nova execução, faça o loop escanear os resumos de uma linha na memória, identificar quais lições são realmente relevantes para a tarefa atual, e carregar apenas essas. Instrua explicitamente a dizer quando nada na memória se aplica, em vez de forçar uma lição passada irrelevante em uma nova situação apenas porque a memória existe.
Passo 14: Adicione Um Gatilho De Agendamento
Decida quando este loop é executado sem você iniciá-lo manualmente. Um cron job. Um observador de arquivos. Um gatilho recorrente baseado em calendário. Este é o passo que transforma um sistema que você executa sob demanda em um que é executado enquanto você dorme, e é geralmente o único passo mais fácil em toda esta lista, e aquele que a maioria das pessoas nunca se preocupa em implementar mesmo depois de construir todo o resto.
Fase Quatro: Escalando E Fortalecendo (Passos 15 a 18)
Passo 15: Teste O Loop Sob Estresse Antes De Confiar Nele
Antes de confiar neste loop para qualquer coisa real, teste-o deliberadamente contra quatro modos de falha.
Dê a ele uma versão genuinamente insolúvel da tarefa e confirme que o Gerente realmente para em vez de entrar em loop infinito, já que um loop que só é testado em tarefas que pode concluir nunca demonstrou realmente como falhar graciosamente.
Alimente o Juiz com uma saída que você sabe que está sutilmente errada, algo que lê bem, mas contém um erro factual ou lógico específico que você plantou deliberadamente, e confirme que ele realmente pega a falha em vez de aprovar algo que parece plausível.
Se o Construtor e o Juiz compartilham o mesmo modelo subjacente, alimente o Juiz com um erro que esse modelo comete caracteristicamente e veja se ele deixa o erro passar, já que um Juiz compartilhando os pontos cegos do Construtor derrota todo o propósito da separação do passo 6.
Calcule o custo de pior caso do loop executando até seu limite máximo de revisão, usando suas chamadas de modelo mais caras e saída razoável mais longa, e decida honestamente se esse número, aparecendo em uma fatura real, te alarmaria.
Executar esses quatro testes antes de confiar um loop com qualquer coisa que importa pega a grande maioria das falhas que de outra forma apareceriam pela primeira vez na frente de um cliente, um chefe, ou seu próprio extrato bancário, em vez de em um teste controlado que você executou de propósito.
Passo 16: Roteie Tarefas Para O Modelo Certo, Não O Mesmo Toda Vez
Uma vez que um loop funciona, resista ao hábito de executar cada parte dele em seu único modelo favorito. O papel do Construtor geralmente se beneficia do seu modelo mais capaz, já que está fazendo o raciocínio duro real e um modelo mais fraco aqui produz um primeiro rascunho pior que custa mais ciclos de revisão para corrigir do que teria custado para gerar bem da primeira vez.
O papel do Juiz, verificando contra um padrão escrito específico, muitas vezes tem um desempenho igualmente confiável em um modelo menor, mais barato e mais rápido, já que não lhe é pedido que seja criativo, apenas consistente, e um modelo menor verificando contra uma lista de verificação extremamente bem especificada frequentemente iguala um maior a uma fração do custo e latência.
O Gerente, roteando com base em regras que você já escreveu, quase nunca precisa do seu modelo mais caro, já que seu trabalho é executar lógica que você já especificou, não raciocínio de ponta aberta, e ele é executado pelo menos uma vez por iteração, independentemente de como o Construtor e o Juiz se saem, o que torna seu custo por chamada mais importante do que sua capacidade bruta.
Esta abordagem em camadas, modelo caro para construir, modelo barato e consistente para julgar verificações de rotina, modelo barato para rotear, é geralmente de onde vêm as economias de custo reais em um loop. A maioria das pessoas assume que o controle de custos significa menos loops ou menos revisões. Na verdade, vem de igualar o custo do modelo à dificuldade real de cada papel específico dentro do loop que você já construiu.
Passo 17: Expanda Para Um Segundo Loop, Não Cinco De Uma Vez
A tentação, uma vez que o primeiro loop funciona, é construir vários mais imediatamente, atacando cinco tarefas diferentes em paralelo porque a arquitetura tecnicamente suporta agora. Resista a isso por mais tempo do que parece confortável. Faça um loop funcionar de forma confiável o suficiente para que você tenha genuinamente parado de verificar sua saída de perto, o que significa que ele passa consistentemente em suas próprias verificações pontuais manuais por um período real de tempo, não apenas uma única demonstração bem-sucedida que todos assistiram de perto. Só então comece o segundo loop, em uma tarefa diferente, idealmente uma que mapeie algo completamente diferente do primeiro, para que você esteja testando se o esqueleto subjacente generaliza, em vez de apenas ajustar a mesma tarefa ainda mais.
Passo 18: Dê A Si Mesmo Uma Visão Compartilhada Em Todos Os Loops Em Execução
Depois de ter mais de um loop em execução, acompanhe uma visão compartilhada de custo e gatilhos de condição de parada em todos eles, não por loop isoladamente. Um único loop com um orçamento por tarefa razoável parece completamente bom por si só. Dez loops, cada um individualmente dentro do orçamento, ainda podem somar um total alarmante que ninguém percebe até que a conta agregada chegue, precisamente porque o rastreamento de cada loop individual parecia bom isoladamente.
Registre cada gatilho de condição de parada especificamente, não apenas conclusões bem-sucedidas. Um loop atingindo seu teto de revisão constantemente, enquanto outros raramente o fazem, está lhe dizendo que o padrão de seu Juiz está mal calibrado, muito rigoroso para realmente passar, ou verificando contra a verdade terrena errada completamente, não que a tarefa subjacente seja simplesmente difícil. Esse padrão é invisível se você está apenas rastreando sucessos e tratando cada escalada como um evento isolado e não notável, em vez de um ponto de dados sobre o design daquele loop específico.
Fase Cinco: Tornando-Se Um Projetista De Sistemas (Passos 19 e 20)
Passo 19: Pare De Se Medir Por Prompts Escritos
O sinal mais claro de que a mudança realmente aconteceu é uma mudança no que você presta atenção no dia a dia. Um instrutor rastreia quantos bons prompts escreveu. Um projetista de sistemas rastreia quantos loops estão em execução, quão confiável cada um é, e quanto de seu próprio tempo foi devolvido a ele por sistemas que não precisam mais de supervisão. Se você ainda está medindo sua própria produtividade em prompts digitados, a mudança mental do passo um ainda não se concretizou completamente, independentemente de quantos loops você tecnicamente construiu.
Passo 20: Ensine Alguém Os Cinco Movimentos
O passo final não é mais realmente sobre seus próprios sistemas. É confirmar que você realmente internalizou a mudança ao explicá-la para outra pessoa sem recorrer a jargões. Descoberta, transferência, verificação, persistência, agendamento. Se você pode guiar outra pessoa através da construção de seu próprio primeiro loop usando apenas esses cinco movimentos e os passos acima, você fez a transição real que este roteiro descreve. Você não é mais a pessoa dentro do loop, digitando a próxima instrução. Você é a pessoa que o projetou, do lado de fora, observando-o executar.
Os Quatro Custos Que Se Acumulam Silenciosamente Se Você Pular Passos
Vale a pena encerrar com um aviso, já que pular passos neste roteiro não falha alto, falha silenciosamente, de maneiras que só aparecem muito mais tarde.
A dívida de verificação se acumula quando você pula os passos 6 e 7, construindo loops sem um Juiz real ou verdade terrena real. O loop parece estar funcionando porque a saída parece boa, até que um erro se compõe silenciosamente em dezenas de execuções antes de alguém notar.
A podridão de compreensão se instala quando você pula o passo 20, executando loops que você construiu uma vez, mas não poderia mais explicar ou depurar se eles quebrassem, porque você nunca teve que internalizar por que cada peça existia.
A rendição cognitiva acontece quando o passo 1 nunca realmente se concretiza, quando você continua verificando manualmente cada saída por hábito muito depois de o sistema de verificação já ter se provado, derrotando todo o propósito de construir o sistema em primeiro lugar.
A explosão de tokens é o que acontece quando você pula o passo 10, executando loops sem condição de parada real, descobrindo o custo real apenas quando a conta chega.
Cada um desses custos é evitável, e cada um é evitado pela mesma disciplina. Construa os passos em ordem. Não pule aqueles que parecem sem glamour. Os passos chatos, a definição de pronto, a condição de parada, a verdade terrena, são os que estão realmente fazendo o trabalho. As partes que parecem interessantes, o prompt inteligente, o diagrama de arquitetura elaborado, importam muito menos do que se o sistema que você construiu realmente sabe quando está certo, quando está errado, e quando parar.
Essa é toda a distinção entre um instrutor e um projetista de sistemas. Não inteligência. Disciplina sobre as partes que são chatas de construir e fáceis de pular.
Siga @cyrilXBT para os modelos de loop exatos e configurações Construtor-Juiz-Gerente por trás de cada passo neste roteiro.
