Loop Engineering: os 4 níveis de abstração que mudaram como eu construo com IA

Dois caras que ganham a vida vendendo tokens — um da Anthropic, outro da OpenAI — disseram quase a mesma frase essa semana: eles não promptam mais os próprios agentes, eles desenham loops que descobrem o trabalho sozinhos. Eu li isso e pensei o óbvio: ou é mais um termo de hype pra vender curso, ou é a próxima fronteira de verdade. Depois de abrir a caixa, minha aposta é a segunda — com um asterisco gigante que quase ninguém te conta: isso só funciona se você entender o problema antes de automatizar. Esse post é a minha leitura do que é loop engineering, o que de fato é útil e o que é só barulho.

O que mudou: de promptar agentes para desenhar loops

O ponto de partida é uma frase do Peter Steinberger, criador do OpenCode: você deveria estar desenhando loops que fazem prompt nos seus agentes. E o criador do Claude Code completa na mesma linha: não prompto mais o Claude, eu tenho loops que descobrem o que precisa ser feito; meu trabalho é criar loops. Traduzindo pro chão de fábrica: em vez de você escrever o prompt de cada tarefa, você constrói uma estrutura que gera os prompts, delega pra agentes e verifica o resultado — em ciclo, sozinha. A mudança não é cosmética. É de nível de abstração.

A escada das abstrações: prompt, contexto, harness e loop

Pra não se perder no hype, eu gosto de ver isso como uma escada. Prompt engineering melhora uma chamada. Context engineering melhora o contexto daquela chamada — e isso continua importando muito. Harness engineering melhora o ambiente inteiro do agente; eu já escrevi por aqui sobre o que é um harness e como ele transforma um modelo em agente de verdade. Loop engineering é o degrau seguinte: melhora o ciclo inteiro, da primeira chamada até a resposta final. Nenhum degrau substitui o anterior — você continua escrevendo prompt e cuidando de contexto. Só que a unidade de trabalho deixou de ser a chamada e passou a ser o loop.

Anatomia de um loop: planner, subagente e verificador

Quando eu desmonto um loop desses, sempre acho três peças. A primeira é um planner — de preferência um modelo mais forte, tipo um GPT-5.5 — que recebe a entrada, monta um plano e gera dinamicamente os prompts de cada subtarefa. No exemplo que eu montei com LangGraph, um único planner cuspia quatro prompts de uma vez, um pra cada subagente, e nada impede chegar a centenas; já mostrei isso quando recriei dynamic workflows com subagentes paralelos. A segunda peça são os subagentes, que executam o que o planner mandou. E a terceira — a que separa um loop sério de uma roleta — é o verificador: outra LLM, de outro modelo, que olha a saída do subagente e decide se passou ou não.

A rubrica é o que separa loop de macaquinho infinito

O detalhe que os tweets não contam é a rubrica. Junto com o prompt da subtarefa, o planner gera um critério de aprovação: essa tarefa só está cumprida se atender a, b e c. O verificador recebe exatamente essa rubrica, olha a saída e ou aprova, ou dispara um follow-up — algo como reescreva o relatório incluindo uma tabela markdown com tais colunas. No meu loop eu limitei a três tentativas; se não passar, ele simplesmente não aprova. E por que o verificador tem que ser um modelo diferente? Pra não carregar o mesmo viés de quem gerou a resposta. Quem gera não é bom juiz de si mesmo — isso vale pra LLM e vale pra gente.

O grafo é o novo nível de abstração

A minha defesa é simples: o grafo é o novo nível de abstração. Lembra de G = (V, E) lá da computação? Vértices e arestas. Pensa nos nós como computação — é onde a LLM trabalha, onde tem custo — e nas arestas como condições de fluxo. E aqui está o pulo do gato: você não quer que a LLM decida tudo. Existem decisões que são determinísticas, e você controla essas arestas na unha. Então você usa a LLM onde ela é boa (dentro do nó) e amarra o fluxo de forma determinística (nas arestas). Melhor dos dois mundos. Eu uso LangGraph, mas grafo não depende de framework nenhum — é uma ideia, dá pra desenhar no papel. Quando o cara diz que o trabalho dele é construir loops, ele está construindo nó de computação ou aresta de fluxo. É isso.

Onde isso brilha (e onde você ainda precisa de um engenheiro)

Agora o asterisco. Loop engineering é maravilhoso pra trabalho de conhecimento: pesquisa interna, entendimento de cliente, relatórios — colarinho branco em geral. Dá pra deixar um loop desses rodando toda meia-noite, lendo seu banco, percebendo que a venda caiu e montando a própria estrutura pra investigar. Mas eu não confio cegamente nisso pra gerar código de produção, e tem motivo: o Ralph Loop já tentou algo parecido e não vingou, justamente porque vira um monstrinho rodando solto. Três coisas pra você levar: (1) você não tem tokens infinitos — quem vende token tem, você não, então loop sem critério de parada é dinheiro queimado; (2) verificação não é opcional, é o coração do loop, porque gerar sem verificar é só esperança automatizada; (3) se você não entende o problema, não vai nem fazer vibe code direito, quanto mais desenhar o loop que resolve uma categoria inteira de problemas. A mudança real é essa: eu saí de escrever código que resolve um problema para escrever código que resolve uma categoria de problemas.

Conclusão

No fim, loop engineering não é uma ferramenta nova pra comprar — é um jeito de pensar. Você para de ser a pessoa que digita o prompt e vira a pessoa que projeta a máquina que gera os prompts, delega e verifica. E dá pra fazer isso hoje, sem depender de Anthropic, OpenAI ou de ninguém, desde que você tenha o conhecimento. O recado que fica, e com o qual eu concordo: adapte-se ou saia do jogo. Se quiser ver o raciocínio que disparou esse post, o vídeo do Ronald sobre engenharia de loop vale o play.