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 comandos para agentes de codificação e começar a projetar os loops que dão esses comandos. Quase ao mesmo tempo, Boris Cherny, que lidera o Claude Code na Anthropic, disse que não dá mais comandos diretamente para o Claude; ele tem loops rodando que comandam o Claude e descobrem o que fazer, e que seu trabalho real é escrever loops. Dias depois, Addy Osmani, um engenheiro do Google, escreveu sobre o conceito 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 limiar. 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 limiar é a razão pela qual este roteiro existe. Dar comandos era a habilidade necessária quando um humano precisava sentar ao teclado direcionando um agente linha por linha. 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 motivo pelo qual a ordem importa especificamente, antes dos passos em si. Engenharia de loops não é uma habilidade única que você tem ou não tem. É uma pilha, onde cada camada depende da camada 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á observando. Construir persistência, passo 11, antes de ter verificação real, passos 6 e 7, significa que você está registrando cuidadosamente lições aprendidas a partir de um Juiz que pode estar carimbando resultados ruins, o que torna a camada de persistência ativamente prejudicial em vez de meramente inútil. Pular passos nesta lista não significa apenas perder um recurso. Significa construir as partes empolgantes sobre uma base que não pode realmente sustentá-las, e descobrir isso só 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ê 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 enorme. 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 comando associado 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 Comando Mais Longo Com Um Sistema Melhor
O instinto quando algo dá errado é adicionar outra instrução ao mesmo comando. Ao longo de meses, isso produz um comando que é um muro denso e autocontraditório de regras que o modelo não consegue mais manter na memória de trabalho de uma só vez, então ele faz correspondência de padrões com o que parece mais recente e silenciosamente descarta o resto.
A engenharia de loops substitui esse instinto completamente. Em vez de adicionar outra regra a um comando, você adiciona outro componente a um sistema. Uma etapa de verificação. Um arquivo de memória. Um gatilho programado. O próprio comando deve ficar mais curto com o 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 volta única de um loop, independentemente do domínio específico, se decompõe 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 será 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 de forma invisível na própria cabeça da pessoa. 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 totalmente 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 Comando
Este é o passo que a maioria das pessoas pula e aquele que determina se tudo depois funcionará. Antes de escrever uma única instrução para o agente, anote, em linguagem simples, exatamente como é um resultado correto. 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á concluída 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 em 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 que precise ser dissuadido. 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 de uma segunda opinião formada da mesma forma que a primeira foi.
Passo 7: Dê Ao Juiz Verdade Fundamental, Não Apenas Uma Opinião
Um Juiz que só vê a saída do Construtor pode dizer se parece coerente. Não pode dizer se está realmente correto. Para tarefas de codificação, a verdade fundamental é 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 fundamental específica que seu Juiz verificará, seu loop ainda não tem verificação real, não importa quão confiante soe a linguagem do Juiz.
Passo 8: Escreva O Formato De Transferência Antes De Escrever O Comando De Transferência
A saída do Construtor e o veredito do Juiz precisam ambos 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 fundamental foi verificada
Passo 9: Execute Manualmente Uma Vez, Do Início Ao Fim, Antes De Automatizar Qualquer Coisa
Antes de configurar agendamento ou repetições automáticas, execute a sequência completa de 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 fundamental ou os critérios antes de avançar. Automatizar uma etapa de verificação quebrada apenas produz resultados quebrados mais rápido.
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, comprimento, 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 certeza se estava na fonte, uma afirmação que inferiu em vez de encontrar explicitamente.
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 um aprovado ou reprovado em cada item 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 funcionando silenciosamente parar de fornecer 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 cheia de ressalvas, três resultados explícitos de aprovado ou reprovado com um motivo específico anexado a qualquer reprovação.
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 brando, 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 ela deve ser escrita como lógica rígida, não uma instrução suave da qual o modelo possa se dissuadir.
CONDIÇÕES DE PARADA:
Revisões máximas: 3. No 3º veredito reprovado, escalonar para um humano
com o histórico completo, não tentar 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, parar
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. O motivo específico pelo qual uma instrução suave falha aqui vale a pena ser entendido, não apenas aceito. "Pare quando estiver bom o suficiente" dentro de um comando é 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 com raciocínio, 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 isso importava. 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 realmente funcionar a longo prazo é a moderação na hora de escrever. 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 alertou no passo 2, apenas movido para uma pasta de memória em vez de um comando. Uma lição que vale a pena anotar é algo que custaria tempo real para redescobrir se esquecido, não um registro de trabalho de rotina que foi bem-sucedido 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 comando inchado: dezenas de arquivos, muitos dizendo versões ligeiramente diferentes da mesma coisa. Em um cronograma recorrente, semanal é 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 a razão pela qual precisa ser agendado explicitamente, em vez de deixado para acontecer quando alguém notar que a pasta de memória ficou complicada, o que na prática significa que nunca acontece até que o desempenho do loop já tenha começado a se 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-o explicitamente a dizer quando nada na memória se aplica, em vez de forçar o encaixe de 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 será executado sem você iniciá-lo manualmente. Um cron job. Um observador de arquivos. Um gatilho baseado em calendário recorrente. Este é o passo que transforma um sistema que você executa sob demanda em um que funciona enquanto você dorme, e geralmente é o 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 algo 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 que sabe como falhar graciosamente.
Alimente o Juiz com uma saída que você sabe que está sutilmente errada, algo que leia bem, mas contenha 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 soa plausível.
Se o Construtor e o Juiz compartilham o mesmo modelo subjacente, alimente o Juiz com um erro que aquele 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 do pior cenário do loop rodando 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 estes quatro testes antes de confiar um loop a algo 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ê realizou 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 no seu único modelo favorito. O papel de Construtor geralmente se beneficia do seu modelo mais capaz, já que está fazendo o raciocínio difícil 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 de 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 é solicitado a ser 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 a lógica que você já especificou, não raciocínio de final aberto, 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.
Essa 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 reais economias de custo em um loop. A maioria das pessoas assume que o controle de custos significa menos loops ou menos revisões. Na verdade, vem de combinar o custo do modelo com a 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 outros imediatamente, abordando cinco tarefas diferentes em paralelo porque a arquitetura tecnicamente suporta isso 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 suas próprias verificações pontuais manuais ao longo de 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 da primeira, 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 De 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 razoável por tarefa parece completamente bem 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 acompanhamento de cada loop individual parecia bem 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 do Juiz está mal calibrado, muito rigoroso para realmente passar, ou verificando contra a verdade fundamental 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 escalação 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 Pela Quantidade De Comandos 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 comandista acompanha quantos comandos bons escreveu. Um projetista de sistemas acompanha quantos loops estão rodando, quão confiável cada um é e quanto do seu próprio tempo foi devolvido a você por sistemas que não precisam mais de supervisão. Se você ainda está medindo sua própria produtividade em comandos digitados, a mudança mental do passo um ainda não se consolidou totalmente, independentemente de quantos loops você construiu tecnicamente.
Passo 20: Ensine A 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 explicando-a para outra pessoa sem recorrer a jargões. Descoberta, transferência, verificação, persistência, agendamento. Se você puder 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 funcionar.
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 ruidosamente, ele 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 fundamental 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 que alguém note.
A podridão de compreensão se instala quando você pula o passo 20, executando loops que construiu uma vez, mas não seria mais capaz de 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 consolida, 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 deles é evitado pela mesma disciplina. Construa os passos em ordem. Não pule aqueles que parecem pouco glamorosos. Os passos chatos, a definição de pronto, a condição de parada, a verdade fundamental, são os que realmente estão fazendo o trabalho. As partes que soam interessantes, o comando engenhoso, 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 comandista 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 obter os modelos exatos de loop e configurações de Construtor-Juiz-Gerente por trás de cada passo neste roteiro.
