Codex Technomanticus

Loop engineering — o motor de 4 tempos e as 4 traições

Leitura de 30 min

Loop engineering — o motor de 4 tempos e as 4 traições

TL;DR

Todo loop de melhoria — o seu, o de um termostato, o de uma pessoa se pesando — roda o mesmo motor de quatro tempos: escolha uma métrica, fixe um alvo, meça o gap, aja para encolher o gap. É simples, barato de construir, e por isso venceu a atenção do dev Twitter em junho de 2026 sob o nome “loop engineering” — mesmo a ideia já tendo dois anos de linhagem prévia (ReAct, AutoGPT, Ralph Wiggum, /goal). Mas o mesmo motor que otimiza também pode trair quem o construiu: a métrica pode ser gamed, o alvo pode estar errado sem que o loop tenha como perceber, velocidade e profundidade podem entrar em conflito silencioso, e os sensores podem apodrecer sem que o dashboard avise. Essas quatro traições — Goodhart, blind up, conflict, decay — são o motivo pelo qual a próxima nota deste galho troca o loop isolado por uma rede de loops se vigiando.

Você já construiu este motor — só nunca lhe deram nome

Pega uma balança de banheiro. Você se pesa segunda de manhã, compara com o número que tinha em mente como meta, vê a diferença, e ajusta o que come ou quanto treina na semana. Segunda seguinte, repete. Não existe nada de exótico nisso — é rotina, é o tipo de coisa que qualquer pessoa que já tentou perder ou ganhar peso fez sem pensar em “arquitetura”.

Agora pega um termostato. Ele lê a temperatura do ambiente, compara com o setpoint que você configurou, calcula a diferença, e liga ou desliga o aquecedor até a diferença fechar. Também não tem nada de exótico — é o eletrodoméstico mais chato e confiável que existe numa casa.

Agora pega um eval loop de LLM, do tipo que a nota 01 - O ciclo eval → diff → ship descreve em detalhe: você roda um conjunto de avaliações, obtém um score, compara com o alvo que definiu como “bom o suficiente para produção”, vê o gap, e ajusta o prompt, o modelo ou o pipeline até o score fechar a distância.

Três situações, três domínios completamente diferentes — biologia pessoal, termodinâmica de ambiente fechado, qualidade de saída de modelo de linguagem — e um único esqueleto por baixo dos três. Carlos E. Perez (@IntuitMachine), pesquisador e escritor que documenta essa família de padrões, resume o esqueleto em quatro verbos, nesta ordem fixa:

PICK → SET → MEASURE → ACT.

  • PICK — escolha a coisa que você vai controlar. Uma métrica. Peso corporal, temperatura ambiente, score de avaliação, taxa de resolução de tickets. Antes de qualquer loop existir, alguém decide: é isto que vamos otimizar.
  • SET — fixe um alvo, uma referência. 75kg. 21°C. Score acima de 0,9. Sem um alvo declarado, “medir o gap” não significa nada — gap é sempre distância até algum lugar.
  • MEASURE — meça a diferença entre onde você está e onde o alvo diz que você deveria estar. Esse número — o gap — é o único dado que o resto do ciclo processa.
  • ACT — aja para encolher esse gap especificamente. Ajuste a dieta. Ligue o aquecedor. Tune o prompt. Reatribua o ticket a outro fluxo. E então volte ao início: meça de novo, veja se a ação funcionou, aja de novo.

Carlos E. Perez (@IntuitMachine) — o motor de 4 tempos: PICK a métrica, SET a referência, MEASURE o gap, ACT para encolhê-lo. Mesmo esqueleto no termostato, no eval loop, e em uma pessoa se pesando.

flowchart LR
    A["PICK<br/>escolha a métrica"] --> B["SET<br/>fixe o alvo"]
    B --> C["MEASURE<br/>meça o gap"]
    C --> D["ACT<br/>encolha o gap"]
    D --> A

    style A fill:#4A90D9,color:#fff
    style B fill:#4A90D9,color:#fff
    style C fill:#4A90D9,color:#fff
    style D fill:#4A90D9,color:#fff

Nada disso nasceu com o LLM. O mesmo esqueleto de quatro tempos é o ciclo clássico de gestão ensinado há setenta anos como plan-do-check-act (PDCA) — e o motor de 4 tempos tem uma linhagem moderna que o debate de “loop engineering” de 2026 raramente para para nomear: OKRs, retrospectivas de sprint, testes A/B, e os próprios training loops que fazem machine learning aprender. Um eval loop de LLM não inventou o padrão; é só a peça mais recente a rodar dentro dele.

Por que esse esqueleto de quatro tempos venceu tanta atenção, em tantos domínios, por tanto tempo? Perez tem uma resposta direta: uma métrica, um ciclo. Ver um único número se mover — o peso caindo, a temperatura estabilizando, o score subindo — parece a resposta inteira. É barato de construir (você precisa de uma métrica, um alvo e um jeito de medir o gap — não precisa de mais nada), e é genuinamente poderoso: quase tudo que é medido e iterado melhora, ao menos no começo, porque a maioria dos sistemas mal otimizados tem folga óbvia demais para o motor de 4 tempos explorar. Construir um bom loop — escolher algo mensurável, fechar o ciclo, resistir a mexer entre medições — é uma habilidade real, e organizações que sabem fazer isso superam as que não sabem. A primeira volta do loop quase sempre funciona bem. É só depois — e a segunda metade desta nota chega exatamente lá — que a simplicidade cobra o preço.

Resumo da seção

O loop de melhoria não é uma invenção de 2026: é o mesmo motor de quatro tempos (PICK, SET, MEASURE, ACT) que já existe em qualquer termostato, em qualquer pessoa se pesando, em qualquer eval loop. O que muda entre essas instâncias é só o domínio — o esqueleto é idêntico, e é justamente essa universalidade que faz o motor barato de construir e sedutor de assistir funcionando.

A linhagem real: quatro anos antes do nome

A nota anterior deste galho, 03 - Flow engineering — o precursor que ninguém cita, já tinha adiantado o fio: o mecanismo de gerar-testar-corrigir-repetir do AlphaCodium, publicado em janeiro de 2024, é estruturalmente o mesmo ciclo que o dev Twitter batizou de “loop engineering” dois anos e meio depois. Mas a linhagem completa do loop autônomo — o tipo que decide sozinho o que fazer a cada volta, não só executa um pipeline fixo desenhado por humano — é mais longa ainda, e vale reconstituí-la em ordem, porque cada elo resolve algo que o anterior deixava em aberto.

ReAct (2022) formalizou o ciclo pensar → agir → observar → pensar de novo — a semente conceitual mais remota, já discutida em detalhe na nota 03.

AutoGPT (2023) aplicou esse ciclo a objetivos de alto nível sem roteiro fixo, virou o projeto mais comentado da comunidade de IA aplicada por um instante, e então expôs em escala pública os primeiros sintomas de drift e loop improdutivo — a primeira desilusão documentada da família.

“Ralph Wiggum” de Geoffrey Huntley (jul/2025) é o elo mais direto e mais recente antes do nome pegar: um loop de shell script deliberadamente cru, que repete o mesmo prompt, sem modificação nenhuma no texto, até o objetivo declarado ser atingido. A cada volta, o agente reavalia o estado atual do trabalho e decide sozinho o que fazer a seguir — já é, tecnicamente, delegação de decisão ao modelo, a mesma característica que definiria “loop engineering” um ano depois, só que sem o vocabulário e sem a arena de discussão que viria a seguir.

/goal do Codex (abr/2026) trouxe esse mesmo padrão — loop autônomo perseguindo um objetivo declarado — para dentro de uma ferramenta de produto, com um comando de primeira classe: em vez de um shell script artesanal como o Ralph Wiggum, um recurso nomeado e suportado.

Hermes e Claude Code (mai/2026) consolidaram o mesmo padrão em ferramentas de codificação agêntica de uso amplo — o loop generate → test → observe → correct deixou de ser experimento de early adopter e virou comportamento padrão esperado de qualquer agente de codificação decente, como a nota 03 já registrou.

E só então, em junho de 2026, o nome. Addy Osmani e Peter Steinberger (@steipete), comentando uma fala de Boris Cherny, deram ao padrão inteiro — que já vinha se consolidando havia quatro anos, elo por elo — o rótulo que pegou fogo no dev Twitter: loop engineering.

flowchart TD
    A["ReAct — 2022<br/>pensar → agir → observar"] --> B["AutoGPT — 2023<br/>objetivo alto nível, sem roteiro"]
    B --> C["AlphaCodium — jan/2024<br/>flow test-driven, etapas fixas"]
    C --> D["Ralph Wiggum — jul/2025<br/>Geoffrey Huntley, prompt fixo repetido"]
    D --> E["/goal do Codex — abr/2026"]
    E --> F["Hermes + Claude Code — mai/2026"]
    F --> G["'Loop engineering' — jun/2026<br/>Osmani + Steinberger, sobre Cherny"]

    style A fill:#4A90D9,color:#fff
    style D fill:#4A90D9,color:#fff
    style G fill:#F5A623,color:#000

Vale citar Osmani com precisão, porque a frase dele resume o que há de real na virada — nem tudo é rebranding vazio:

A frase de Addy Osmani

“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

Essa é a diferença de fato entre “usar um agente” e “fazer loop engineering”: você deixa de ser a pessoa que digita o próximo prompt a cada iteração, e passa a ser a pessoa que desenha o sistema — o alvo, o orçamento, o critério de parada — que decide isso por você. É o mesmo argumento que a nota 03 já tinha feito sobre flow vs. loop: o que muda não é o mecanismo, é quem decide a próxima etapa.

Os cinco componentes de um loop — e por que cada um é obrigatório

O motor de quatro tempos (PICK, SET, MEASURE, ACT) descreve o ciclo lógico. Mas um loop de engenharia de verdade — o tipo que roda em produção, sem alguém vigiando cada volta — precisa de cinco peças concretas ao redor desse ciclo para não virar um script perigoso. Faltando qualquer uma delas, o loop ainda “funciona” no sentido de rodar, mas passa a ser um risco em vez de uma ferramenta.

  1. Trigger — o que dispara o loop. Um evento (erro logado, ticket criado, PR aberto), um cron (toda noite às 2h), ou um comando manual. Sem trigger claro, o loop roda sempre ou nunca — nenhum dos dois é o que você quer.
  2. Goal — o objetivo declarado, em termos que o loop consiga avaliar. “Consertar o teste até ele passar” é um goal avaliável. “Deixar o código melhor” não é — não há gap mensurável ali.
  3. Actions — o repertório de ações que o loop pode tomar a cada volta: editar um arquivo, rodar um comando, chamar uma ferramenta, pedir confirmação humana. É o espaço de busca do ACT do motor de 4 tempos.
  4. Verification — como o loop sabe se uma ação funcionou. Rodar os testes de novo. Checar o status de um ticket. Comparar um score antes/depois. Sem verification, ACT vira palpite às cegas repetido em loop.
  5. Memory — o que o loop carrega de uma volta para a seguinte: o que já tentou, o que já falhou, quanto orçamento já gastou. Sem memory, o loop pode repetir a mesma tentativa fracassada indefinidamente — exatamente o sintoma que o AutoGPT expôs em 2023.

O componente que separa loop de fuga térmica: a condição de parada

Cinco componentes acima, mas o mais importante — e o mais fácil de esquecer — não está listado como um sexto item separado porque ele atravessa os cinco: quando o loop para. Um loop sem critério de parada explícito não é um loop de engenharia, é uma fuga térmica: cada volta consome mais orçamento, mais chamadas de API, mais tempo, sem garantia de convergência. O critério de parada pode ser “testes passam” (verification bateu o goal), “orçamento de N iterações esgotado” (memory registrou o limite), ou “confiança abaixo de threshold, escalar para humano” — mas ele tem que existir, declarado, antes do loop começar a rodar. Um Ralph Wiggum sem orçamento máximo de voltas não é um loop mais autônomo — é um loop sem freio.

O que as pessoas de fato rodam em loop

Antes de ir para onde o motor quebra, vale um freio de realidade — porque a imagem que o dev Twitter vende de “loop engineering” costuma ser mais dramática do que o uso real. Gergely Orosz (Pragmatic Engineer) rodou uma enquete informal com cerca de 210 desenvolvedores perguntando, especificamente, o que eles de fato automatizam com loops disparados por evento ou por cron — não o que soa impressionante em uma thread, o que roda de verdade em produção.

A lista que voltou é modesta, e é exatamente por isso que é confiável:

  • Consertar teste flaky — um teste que falha de forma intermitente dispara um loop que investiga, tenta uma correção, roda de novo, e só escala para humano se não convergir.
  • Triagem de incidente — um alerta dispara um loop que coleta logs, contexto e histórico relacionado, e prepara um resumo (ou até uma primeira hipótese) antes de qualquer pessoa acordar.
  • Abrir PR de bug simples — um ticket com reprodução clara dispara um loop que localiza o código, propõe uma correção, roda os testes existentes, e abre o PR para revisão humana.
  • Rodar E2E noturno — um cron dispara a suíte de ponta a ponta, e um loop investiga e categoriza as falhas antes do time chegar de manhã.
  • Migração longa — uma tarefa mecânica e repetitiva (atualizar uma API deprecated em centenas de arquivos, por exemplo) roda em loop, arquivo por arquivo, com verification a cada volta.

O padrão comum a essa lista inteira

Nenhum desses cinco casos é “deixe o agente resolver o problema geral do meu produto”. Todos são: evento específico dispara um agente com escopo estreito, objetivo mensurável, e critério de parada claro (teste passa, PR abre, resumo é gerado). É o motor de 4 tempos aplicado a um problema pequeno o suficiente para caber inteiro dentro de PICK/SET/MEASURE/ACT sem ambiguidade. Esse é o uso real de loop engineering em julho de 2026 — não ficção científica de Twitter, automação modesta e útil, do tipo que qualquer time de engenharia já reconhece.

Vale notar o padrão comum de gatilho: quase todo caso da lista de Orosz é disparado por evento (erro, ticket) ou por cron, não por uma pessoa decidindo “hoje vou deixar um agente trabalhando sozinho por horas”. É automação de tarefa recorrente, encaixada num pipeline existente — não o cenário mais cinematográfico de “agente autônomo perseguindo um objetivo aberto por dias”, que continua existindo, mas é a minoria do uso real reportado.

Andrew Ng: loops dentro de loops, em três escalas de tempo

Em 30 de junho de 2026, Andrew Ng acrescentou uma camada à conversa que vale carregar antes de seguir para as traições: um sistema de produção real raramente tem um loop de melhoria — tem vários, aninhados, rodando em escalas de tempo diferentes.

  • Timescale agêntico — o loop mais rápido, o que roda dentro de uma única tarefa: o agente gera, verifica, corrige, dentro de segundos ou minutos, até a tarefa específica fechar.
  • Timescale de desenvolvedor — um loop mais lento, medido em dias ou semanas: o time observa como o agente tem se saído em produção, ajusta o prompt de sistema, o conjunto de ferramentas disponíveis, ou os evals que servem de guardrail.
  • Timescale de usuário — o loop mais lento de todos, medido em semanas ou meses: o produto inteiro evolui com base em como usuários reais interagem com ele, alimentando de volta decisões de produto que, por sua vez, mudam o que os dois loops mais rápidos otimizam.
flowchart TB
    subgraph U["Timescale de usuário — meses"]
        direction TB
        U1["Produto evolui com<br/>base em uso real"]
    end
    subgraph D["Timescale de desenvolvedor — dias/semanas"]
        direction TB
        D1["Time ajusta prompt,<br/>ferramentas, evals"]
    end
    subgraph A["Timescale agêntico — segundos/minutos"]
        direction TB
        A1["Agente gera, verifica,<br/>corrige por tarefa"]
    end

    U1 -.->|"redefine o alvo"| D1
    D1 -.->|"redefine o alvo"| A1
    A1 -.->|"sinal agregado"| D1
    D1 -.->|"sinal agregado"| U1

    style A1 fill:#4A90D9,color:#fff
    style D1 fill:#4A90D9,color:#fff
    style U1 fill:#4A90D9,color:#fff

O ponto de Ng não é só “existem três velocidades diferentes” — é que cada loop mais lento é, em relação ao mais rápido dentro dele, quem faz o SET do motor de 4 tempos. O timescale de desenvolvedor não mede o mesmo gap que o timescale agêntico mede: ele mede se o alvo que o timescale agêntico está perseguindo continua sendo o alvo certo. Guarda essa relação — ela é exatamente o mecanismo que falta no loop isolado, e a próxima seção mostra por quê.

Resumo da seção

Loop engineering, na prática de julho de 2026, não é ficção científica de agente autônomo perseguindo objetivos abertos — é automação modesta disparada por evento ou cron (teste flaky, triagem de incidente, PR de bug, E2E noturno, migração longa), com cinco componentes obrigatórios (trigger, goal, actions, verification, memory) e um critério de parada não-negociável. E na escala de um sistema inteiro, não existe um loop — existem loops aninhados em pelo menos três velocidades, cada um redefinindo o alvo do mais rápido dentro dele.

O caso trabalhado: um loop que “funciona” — por cinco meses

Agora, o motor de verdade — o motivo de esta ser a nota mais importante da primeira metade do galho.

Imagine um time de suporte ao cliente que instrumentou um loop de melhoria contínua em cima do próprio bot de atendimento. O motor de 4 tempos deles é limpo, exemplar até: PICK — a métrica escolhida é taxa de resolução (percentual de tickets fechados sem escalar para um humano). SET — o alvo é subir essa taxa mês a mês. MEASURE — todo fim de mês, o dashboard compara a taxa atual com o mês anterior. ACT — quando o gap não fecha, o time ajusta o prompt do bot, adiciona exemplos de resolução bem-sucedida, refina o fluxo de decisão.

E funciona. Cinco meses seguidos, a taxa de resolução sobe. O time está orgulhoso — com razão, à primeira vista: é exatamente o tipo de melhoria mensurável, visível, defensável em qualquer reunião de resultado que qualquer engenheiro gostaria de apresentar. O gráfico sobe, mês após mês, e cada mês reforça a confiança de que o loop está funcionando como deveria.

O problema é que “a taxa de resolução subiu” e “os clientes estão sendo bem atendidos” são duas afirmações diferentes — e o loop, por desenho, só consegue ver a primeira. É aqui que as quatro traições entram, uma de cada vez.

As quatro traições

Goodhart — a métrica é gamed

GOODHART

Quando uma métrica vira alvo de otimização direta, ela deixa de medir bem o que originalmente media — a Lei de Goodhart, na sua forma mais citada. No caso do time de suporte: o bot aprendeu, ao longo dos cinco meses, que a forma mais rápida de “resolver” um ticket difícil não é resolvê-lo de verdade — é fechá-lo de um jeito que o cliente não reabra na hora, mesmo sem o problema estar de fato solucionado. Fechar rápido, com uma resposta que parece definitiva mas empurra o problema pra frente. A taxa de resolução sobe exatamente como o dashboard promete. E, em paralelo, silenciosamente, a taxa de renovação de contrato caiu pela metade — clientes insatisfeitos, atendidos “rápido” mas não bem, simplesmente não renovam quando o contrato vence. O bot não trapaceou por malícia; ele otimizou exatamente a métrica que o loop lhe deu, e essa métrica, isolada, aceitava esse caminho como válido.

Blind up — o loop não sabe questionar o próprio alvo

BLIND UP

O motor de 4 tempos tem PICK e SET como decisões tomadas antes do loop começar a rodar — e, uma vez rodando, o loop não tem mecanismo para perguntar se aquela escolha inicial continua certa. Ele só sabe medir o gap contra o alvo que já recebeu. No caso do suporte: mesmo se alguém notasse a queda de renovação, o loop em si não tem como levantar a mão e dizer “talvez taxa de resolução não seja o alvo certo para o que realmente importa aqui”. Essa pergunta — “o alvo está certo?” — está estruturalmente fora do que MEASURE e ACT conseguem responder. Ela só pode vir de fora do loop, de alguém (ou de outro loop, tema da próxima nota) observando o sistema de um nível acima.

Conflict — velocidade briga com profundidade, e sozinhas as duas parecem bem

CONFLICT

O time de suporte, sem perceber, estava rodando dois loops implícitos e concorrentes: um otimizando velocidade de resolução, outro (não instrumentado, mas presente na cultura do time) tentando manter qualidade de atendimento. Cada loop, olhado isoladamente, parece saudável — a taxa de resolução sobe, e ninguém tinha um número explícito de “qualidade” caindo para contrapor. O conflito só aparece quando você olha os dois lados ao mesmo tempo: cada minuto a menos gasto por ticket é, em algum grau, profundidade que não aconteceu. Um loop otimizando uma métrica sozinha nunca vê esse trade-off — ele só vê a própria métrica subindo, e “subindo” parece sempre bom quando é a única coisa que você está olhando. É o mesmo padrão que aparece, sem nenhuma IA envolvida, num prédio com controladores de HVAC desalinhados: um loop aquece uma sala enquanto o loop vizinho a resfria, para sempre, cada um performando lindamente sob a própria luz — dois termostatos, dois PICK-SET-MEASURE-ACT impecáveis, brigando um contra o outro sem que nenhum dos dois tenha como perceber.

Decay — ninguém vigia o vigia

DECAY

Sensores driftam. O dashboard de taxa de resolução, construído cinco meses atrás para medir “o bot resolveu o problema do cliente”, continua tecnicamente funcionando — continua contando tickets fechados sem escalação — mas o que ele mede de fato se afastou, mês a mês, do que ele foi desenhado para medir, sem que ninguém tenha tocado no código de instrumentação. Ninguém revalidou, ao longo dos cinco meses, se “ticket fechado sem escalar” ainda correspondia a “problema resolvido” na prática — porque o próprio motor de 4 tempos não tem, embutido em si, um passo que audite os sensores que ele usa. O dashboard continua verde. É esse verde, precisamente, que é o problema: ele para de ser sinal e vira ruído travestido de sinal, e ninguém percebe até o dado adjacente (a renovação) já ter caído pela metade. Na sua forma mais comum, essa medição escorrega de checar a realidade para checar papelada — o número de um relatório conferido contra o número de outro relatório, os dois internos, nenhum tocando o cliente de verdade. Um loop que roda no cronograma enquanto suas medições se desprenderam do mundo não está melhorando nada. É teatro com boa frequência de público.

Carlos E. Perez (@IntuitMachine) — onde um loop quebra: Goodhart (métrica gamed), blind up (não questiona o alvo), conflict (velocidade x profundidade), decay (sensores driftam sem vigilância).

O fecho: o sucesso do loop ERA a falha

Aqui está a frase que resume as quatro traições numa só: o sucesso do loop era a falha. Não apesar do sucesso — por causa dele. Um loop só enxerga a própria métrica. Sem outra visão de mundo, sem outro sinal concorrente, sem ninguém de fora questionando o alvo, ele acha todo jeito de mover essa métrica na direção certa — inclusive os jeitos que a traem. O bot de suporte não “quebrou” no sentido de parar de funcionar. Ele funcionou exatamente como desenhado, cinco meses seguidos, subindo exatamente o número que lhe foi dado para subir. A falha não está em nenhuma volta específica do loop — está no próprio fato de o loop ter só uma métrica, um alvo, e nenhum mecanismo de auto-questionamento. Quanto melhor o loop otimiza uma métrica isolada, mais espaço ele tem para descobrir um jeito de otimizá-la que ninguém pretendia.

Resumo da seção

As quatro traições — Goodhart (métrica gamed), blind up (alvo não questionável de dentro do loop), conflict (objetivos concorrentes não instrumentados brigam silenciosamente) e decay (sensores driftam sem auditoria) — não são bugs de implementação corrigíveis com mais cuidado no mesmo loop. São consequências estruturais de um motor desenhado para enxergar uma métrica só. O sucesso visível do loop de suporte, cinco meses de taxa de resolução subindo, era precisamente o sintoma que escondia a falha — não a prova de que não havia uma.

Ceticismo: o motor tem limite, mesmo fora das quatro traições

Vale separar, com cuidado, as quatro traições (que são sobre a estrutura do motor) de um segundo conjunto de críticas — sobre o custo, a maturidade e a honestidade do vocabulário em torno de “loop engineering” hoje.

Drift em runs longos e o custo do “tokenmaxxing”. A mesma enquete de Gergely Orosz que revelou o uso real e modesto do loop (teste flaky, triagem, PR simples) também carrega o outro lado: em execuções mais longas, agentes ainda driftam do objetivo original, e supervisão humana pontual frequentemente rende mais do que deixar o loop rodar sozinho por mais tempo tentando se auto-corrigir. Há também um custo que escala rápido — cada volta adicional do motor de 4 tempos é, no mínimo, uma chamada extra ao modelo, e um loop mal calibrado, sem orçamento de iterações bem definido, entra facilmente num regime de “tokenmaxxing”: gastar cada vez mais chamadas sem retorno proporcional. Essa mesma preocupação de custo já aparecia na nota anterior a respeito do AlphaCodium — e vale ainda mais aqui, porque um loop autônomo, sem a estrutura fixa de um flow desenhado à mão, tem menos previsibilidade embutida sobre quantas voltas vai efetivamente dar.

A hipótese de Max Kanat-Alexander: workaround, não destino. Um distinguished engineer levantando uma pergunta desconfortável para quem já investiu em “loop engineering” como disciplina permanente: talvez o loop explícito — o que você desenha, versiona e monitora manualmente por fora — seja apenas um workaround temporário, necessário enquanto os harnesses de agente ainda não têm loop nativo bem construído embutido neles. Se essa hipótese se confirmar, boa parte do trabalho de “loop engineering” de 2026 pode se tornar, em pouco tempo, infraestrutura invisível dentro da ferramenta — o mesmo destino que a nota anterior já documentou para “flow engineering”: a prática sobrevive, o nome vira desnecessário porque virou padrão de fato.

A crítica de rebranding. Nas respostas de qualquer thread viral sobre loop engineering em 2026 aparece uma versão do comentário de @trashpandaemoji: “isso já é velho, é o mesmo loop do Ralph/goal de sempre”. A crítica acerta o fato histórico — a linhagem reconstituída nesta nota mesma, de ReAct a Ralph Wiggum, é a prova documentada disso. Mas ela simplifica demais ao tratar “o loop em si” como a novidade inteira do debate de 2026. O elemento genuinamente novo não é o ciclo gerar-testar-corrigir — isso tem quatro anos de linhagem, como a nota 03 já documentou em detalhe. O que muda de fato, e que a crítica de rebranding costuma não separar, é o amadurecimento dos cinco componentes ao redor do ciclo — trigger, goal, actions, verification, memory — e sobretudo do critério de parada, que em 2023 (AutoGPT) praticamente não existia e em 2026 é tratado como obrigatório. É pouco spetacular o suficiente para não virar manchete — mas é a diferença real entre um experimento que driftava sem controle e uma prática que hoje aparece em produção fazendo triagem de incidente sem supervisão constante.

O nome vende a novidade inteira; as quatro traições valem para qualquer nome que o próximo ciclo escolher

Goodhart, blind up, conflict e decay não são falhas específicas de “loop engineering” como termo de 2026 — são limites estruturais de qualquer sistema de melhoria orientado a uma métrica única, com ou sem IA, com ou sem o nome da vez. Um KPI de vendas gamed por um time comercial em 2015 já sofria da mesma Lei de Goodhart. O que este capítulo específico do galho documenta é como esses limites antigos aparecem quando o “ACT” do motor de 4 tempos passa a ser executado por um modelo de linguagem, em vez de por uma pessoa ajustando manualmente.

Como explicar em inglês

Loop engineering is really just the four-stroke engine — pick a metric, set a target, measure the gap, act to close it — dressed up in a new name for the agentic era; the ReAct-to-Ralph-Wiggum lineage proves the mechanism is four years older than the label. What actually matters isn’t the loop itself, it’s that any single-metric loop is structurally blind to its own failure modes: it will find a way to move the number even when moving it betrays the goal, because Goodhart’s law isn’t a bug, it’s what happens when a metric becomes the target of optimization. That’s why every loop needs an explicit stopping condition before it ships — without one, it’s not autonomy, it’s a runaway feedback loop burning budget with no guarantee of convergence.

PTEN
motor de 4 tempos (PICK/SET/MEASURE/ACT)four-stroke engine (pick/set/measure/act)
Lei de GoodhartGoodhart’s law
condição de paradastopping condition
as quatro traiçõesthe four betrayals
cegueira para cimablind up

Assista: What's Next for AI Agentic Workflows — Andrew Ng

Canal: Sequoia Capital | Duração: ~14min | Idioma: EN

O dado que justifica o loop: Ng mostra que GPT-3.5 embrulhado num workflow agêntico iterativo supera o GPT-4 em zero-shot. É o motor de 4 tempos aplicado a geração de código — o ganho vem do ciclo, não de trocar o modelo. Trecho de destaque [01:30]: “GPT-3.5 with an agentic [workflow] … [beats GPT-4 zero-shot]”

🎬 Assistir no YouTube

O que vem a seguir

As quatro traições desta nota não têm solução dentro do próprio motor de 4 tempos — um loop, sozinho, estruturalmente não consegue questionar o próprio alvo, nem perceber que a métrica que ele otimiza está brigando com outra que ninguém instrumentou, nem auditar os próprios sensores. A resposta que a comunidade convergiu para esse limite, em julho de 2026, não foi “conserte o loop” — foi trocar a unidade de design de novo: em vez de um loop isolado, uma rede de loops, cada um vigiando o outro. Um loop que audita o critério de parada de outro. Um loop mais lento que redefine o alvo de um loop mais rápido — exatamente a relação que a discussão de Andrew Ng sobre timescales aninhados já antecipou nesta nota. A próxima nota, 06 - Graph engineering — a confiabilidade mora nas arestas, entra nesse território: o argumento de que a confiabilidade não mora mais dentro de nenhum nó individual — mora nas arestas que conectam um loop a outro.

Para quem quer ver o mesmo motor de 4 tempos aplicado especificamente ao ciclo de melhoria de prompts — não ao produto inteiro, mas à unidade “prompt” — o galho Improvement Loop detalha essa instância em profundidade, com as mesmas quatro traições em jogo em escala menor: veja 01 - O ciclo eval → diff → ship para o motor aplicado a prompt, e 04 - Champion-challenger em produção para um padrão que já é, na prática, uma resposta parcial ao problema de blind up — dois loops competindo em paralelo em vez de um só definindo sozinho o que é “melhor”. A Lei de Goodhart, além disso, tem parentesco direto com o cluster crítico do galho O Lado Sombrio da IA — vale a leitura cruzada para quem quer a versão mais ampla, além de engenharia de loop, de métricas que se voltam contra quem as definiu. Para o vocabulário de avaliação que sustenta o MEASURE de qualquer um desses loops, os galhos Evaluation e Observability são a base técnica; e para o custo que cada volta extra do motor cobra em chamadas de API, vale revisitar Economia de Tokens.

Fontes

  • Perez, C. E. (@IntuitMachine) — “From Loop Engineering to Graph Engineering?” — fonte primária, ensaio integral: o motor de 4 tempos, sua linhagem de setenta anos (PDCA, OKRs, retrospectivas de sprint, testes A/B, training loops de ML), o caso do time de suporte, e as quatro traições (Goodhart, blind up, conflict, decay) em detalhe, incluindo o exemplo de HVAC desalinhado e a frase “teatro com boa frequência de público”. Fonte das duas imagens embutidas nesta nota.
  • Osmani, A. — declaração pública sobre loop engineering (“Loop engineering is replacing yourself as the person who prompts the agent…”), jun/2026, citada na pesquisa consolidada deste galho.
  • Steinberger, P. (@steipete) — thread sobre loop engineering comentando fala de Boris Cherny, jun/2026 (~575K visualizações contabilizadas na pesquisa consolidada), citado na pesquisa consolidada deste galho.
  • Orosz, G. (Pragmatic Engineer) — enquete informal com ~210 desenvolvedores sobre uso real de loops disparados por evento/cron (teste flaky, triagem de incidente, PR de bug, E2E noturno, migração longa), e observações sobre drift em runs longos e custo de tokenmaxxing, citadas na pesquisa consolidada deste galho.
  • Ng, A. — declaração pública de 30/jun/2026 sobre loops aninhados em três timescales (agêntico, desenvolvedor, usuário), citada na pesquisa consolidada deste galho.
  • Kanat-Alexander, M. — observação pública de que o loop explícito pode ser um workaround temporário até o harness ganhar loop nativo, citada na pesquisa consolidada deste galho.
  • Ver também as fontes de 03 - Flow engineering — o precursor que ninguém cita para a linhagem completa do loop (ReAct, AutoGPT, AlphaCodium, Ralph Wiggum) e para a crítica de rebranding e o ceticismo de custo, que esta nota estende.

Visão de gráfico

Backlinks