Engenharia de prompt morreu. O termo mais quente do Vale do Silício em 2026 é engenharia de loop — não é você fazendo prompt para a IA, mas projetando um sistema em que a IA faz prompt para si mesma. E não, isso não é mais uma bolha conceitual.
Na segunda semana de junho, uma única ideia reorganizou como uma geração inteira de desenvolvedores fala sobre IA. Começou com um post no X que ultrapassou 6,5 milhões de visualizações em seis dias. Addy Osmani, do Google, deu nome a ela. E Boris Cherny, da Anthropic, comprimiu seu peso em uma frase: “Eu não faço mais prompt para o Claude.” Questionado na conferência @Scale dois meses antes sobre se os loops eram apenas mais um ciclo de hype, Cherny não hesitou: “É real. Há dois anos, escrevíamos código à mão. Depois passamos a ter agentes escrevendo código. Agora estamos transitando para agentes fazendo prompt para agentes, que então escrevem código. O passo do loop é tão grande quanto o passo do código-fonte para os agentes.”
Isso não é um exagero. É uma reestruturação silenciosa de carreiras.
De Segurar a Ferramenta a Ficar Fora do Loop
A evolução de 2023 a 2026 cabe em uma tabela, e cada linha é um nível de abstração que desvaloriza a habilidade anterior. Em 2023, você escrevia o código — era o executor. Em 2024, você fazia prompt para a IA escrever — o operador. Em 2025, você escrevia loops que faziam a IA gerar prompt para a IA — o gerente. Em 2026, você constrói sistemas em que os loops rodam sozinhos — o projetista de sistemas. Cada promoção aposentou a habilidade central da etapa anterior, transformando-a de vantagem competitiva em padrão de infraestrutura. Escrever um bom prompt era escasso em 2024; orquestrar agentes em paralelo era escasso em 2025; em 2026, ambos são apenas o bilhete de entrada.
A frase de Cherny não é retoque retórico. Ele repetiu a substância em vários palcos: desde 2026, ele não escreve uma linha de código à mão; faz merge de dezenas de pull requests diariamente pelo celular; e 100 por cento do próprio codebase do Claude Code é escrito pelo Claude. A Anthropic agora faz merge internamente de mais de 80 por cento de código gerado por IA; o número contemporâneo do Google é cerca de 75 por cento. Sua rotina diária: acordar, abrir o Claude Code no celular, digitar um objetivo curto — “otimizar o tratamento de erros do módulo de pagamentos” — e o modelo lê o codebase, decompõe tarefas, escreve, testa e abre o PR. Ele revisa. Às vezes, outro loop faz a revisão. Ao ler esses números, faça a pergunta seguinte: quem escreve os 20 por cento restantes de código humano? Pessoas como Cherny — as que construíram o Claude Code. E elas também pararam.
Loops Não São Novos — Conhecimento Antigo, Reinventado
Remova a embalagem e um loop de agente é quatro movimentos em repetição: descobrir, planejar, executar, verificar — repetir até uma condição ser satisfeita. Você costumava ser o loop. Você ficava entre cada etapa do agente, lia a saída, identificava o erro, decidia a próxima ação e mandava tentar de novo. O movimento central da engenharia de loop é se extrair desse ciclo interno e recuar um nível para projetar a pista em que o agente corre. Qualquer graduando em ciência da computação reconhece o padrão — recursão mais uma condição de terminação. O que é genuinamente novo é que a lógica de julgamento do loop se tornou não determinística: a condição de parada não é mais um i < 100 hardcoded, mas o julgamento próprio de um subagente sobre “isso está pronto?”
A engenharia de loop também não surgiu do nada. É a quarta camada de uma pilha construída ao longo de quatro anos. Engenharia de prompt (2022-2024) otimizava cada palavra que você escrevia — papéis, passos, exemplos — com um teto rígido: nenhum prompt conjura fatos que o modelo nunca recebeu. Engenharia de contexto (2025) deslocou a atenção de como você diz para o que você mostra — histórico da conversa, documentos recuperados, saídas de ferramentas, estado do agente; Karpathy a chamou de “a arte delicada de preencher a janela de contexto”, e os prompts viraram um subconjunto do contexto. Engenharia de harness (início de 2026) chegou quando os agentes começaram a executar trabalho produtivo autônomo em múltiplas etapas e precisavam de um ambiente — conjuntos de ferramentas, restrições, canais de feedback, controles de permissão. Engenharia de loop (meados de 2026) isola a parte do harness que realmente gera autonomia: o próprio ciclo de iteração. Enquanto o harness pergunta “que ambiente o agente precisa”, o loop pergunta “que ciclo o leva ao objetivo, e quando ele para”. Não são quatro ondas que se substituem; são preocupações aninhadas. Você ainda escreve prompts, ainda gerencia contexto, ainda constrói harnesses. A engenharia de loop acopla um motor a todos eles.
O Loop de Verificação É a Verdadeira Escassez
Todo loop tem duas metades: um gerador que produz trabalho e um verificador que julga se o trabalho é aceitável. Por dois anos, a indústria obcecou-se por geradores — ajustando prompts, trocando modelos, discutindo temperatura. Mas dentro de um loop, o gerador roda repetidamente a custo marginal quase zero. O que determina se todo esse movimento cria valor é o verificador. Um loop com um verificador fraco não falha escandalosamente. Falha produtivamente — eficiente, confiante, produzindo lixo centenas de vezes enquanto você assiste. Daí a frase que quase todo tutorial de engenharia de loop omite: o gargalo não é o modelo. É o verificador.
Em junho de 2026, o padrão de loop mais popular era uma estrutura simples chamada Ralph Loop (batizada em homenagem a Ralph Wiggum, de Os Simpsons). A lógica: após cada iteração, resumir o trabalho concluído e perguntar “o objetivo foi alcançado?” — até a resposta ser sim. Suas variantes se dividem, pela abertura, em duas famílias. Loops fechados fixam os critérios de sucesso antes de o loop começar — “deixar a suíte de testes verde” — com cada passo verificável e convergência garantida; seguros, previsíveis, baratos e incapazes de surpreendê-lo além da tarefa atribuída. Loops abertos entregam um objetivo e restrições frouxas — “otimize este app” — em que a saída pode ser genuinamente impressionante ou degradar silenciosamente em uma máquina de nonsense muito cara. Loops bem projetados misturam ambos: verificações rígidas como piso, uma instrução aberta como teto — “e se tudo passar, me surpreenda”.
Como um sistema de loops real se parece em produção vale a pena dissecar. AI Jason, um practitioner que roda loops em toda a empresa, precisa apenas do primitivo mais simples: um loop de suporte. A cada trinta minutos, um cron acorda o agente, puxa todos os tickets de suporte, responde o que consegue e registra pontos de atrito e ideias de produto em uma pasta compartilhada chamada signals. Depois, os loops se empilham: o mesmo loop, ao descobrir um bug, gera um agente de código para corrigi-lo, monitora se a correção funcionou e tenta de novo se os usuários enfrentarem o mesmo problema — um sintoma, não uma cura. Ele roda cinco ou seis loops ao mesmo tempo: suporte a cada trinta minutos produzindo signals e tarefas de engenharia; SEO diariamente às 9h produzindo páginas e signals de lacunas de conversão; crescimento de produto em cronograma diário produzindo listas de tarefas; operações no Reddit em horários fixos produzindo rascunhos de comentários. O detalhe crítico de design: eles compartilham um único sistema de arquivos. O signal do loop de SEO — “essa palavra-chave converte, mas não tem conteúdo” — alimenta diretamente o loop de conteúdo; os signals de bugs repetidos do loop de suporte são captados pelo loop de produto. O cérebro compartilhado se acumula — a saída de Jason roda vinte a quarenta páginas de qualidade por dia sem supervisão.
Verificação É um Problema Organizacional, Não Técnico
Em um mundo em que os loops rodam durante a noite, os sinais que um agente usa para se verificar não são impressões — são suítes de teste, checagens de tipo, regras de lint e erros de runtime. Esses sinais precisam ser bons o suficiente para substituir você sentado lá observando. O que força uma conclusão brutal: a qualidade do seu codebase agora determina a qualidade da saída do seu agente. Cobertura de testes baixa, arquitetura emaranhada e documentação ausente fazem os agentes perderem o rumo mais rápido, porque eles nem conseguem encontrar a definição de “correto”. Por outro lado, um projeto com bons testes, limites de módulos limpos e regras de lint precisas — agent-ready, na gíria dos practitioners — permite que os loops produzam de forma estável sem nenhum humano na cadeira. Isso não é sobre o quão forte é o seu agente. É sobre se a sua organização merece um.
O que produz a conclusão mais contraintuitiva de toda essa discussão: a engenharia de loop não torna os engenheiros menos importantes. Ela torna o bom gosto uma hard skill. Quando o modelo domina “escrever”, as saídas mais escassas do engenheiro se tornam: escrever boas condições de verificação — definir o que “correto” significa, já que um verificador com 90 por cento de precisão limita a qualidade da saída a 90 por cento; projetar sistemas verificáveis — limites de módulos limpos o suficiente para que um agente possa modificar um com segurança sem detonar o resto; julgar quando intervir — quais tarefas um loop pode rodar sem supervisão e quais exigem olhos humanos; e iterar o verificador — porque quando um loop termina e o resultado decepciona, o problema geralmente não é o agente, é a definição do seu verificador. Isso converge com o que a gestão costumava classificar como soft skills: julgamento. Na era do loop, julgamento é o único trabalho que um loop não consegue fazer.
Uma ressalva honesta: a sombra do loop é denominada em dinheiro. Deixar agentes iterar queima tokens rápido; cinco loops rodando em paralelo, alimentando uns aos outros com signals, otimizando o codebase — queima mais rápido ainda. A cobertura do TechCrunch disse sem rodeios: se isso soa caro, é porque é. A observação de Noam Brown de que a capacidade de resolver problemas escala com compute em tempo de teste descreve um modelo de “suprimento ilimitado” cuja premissa é que você pode pagar. Amazon, Google e Anthropic não se preocupam com custos de token — elas vendem tokens. Uma empresa de cinquenta pessoas rodando loops durante a noite acumula faturas de API de quatro dígitos. O futuro próximo, portanto, se bifurca: grandes empresas rodam loops como otimização contínua totalmente automatizada; empresas menores os rodam em tarefas precisas e delimitadas — até que os preços dos tokens caiam mais.
Você Não Está Sozinho no Loop
A engenharia de loop é um ponto de virada — não porque a técnica seja nova (loops na ciência da computação são mais velhos que a maioria dos seus leitores), mas porque sua popularização marca uma travessia de fronteira: você não conversa mais com a IA, não é mais a interface dela, não é mais o intermediário entre ela e o código. Você saiu para fora, projetando sistemas de além do loop. Para os practitioners em 2026, isso significa quatro coisas. Engenheiros: pare de se preocupar se a IA vai substituí-los; comecem a se preocupar se o seu bom gosto já conquistou o direito de projetar loops. Escrever condições de verificação é mais difícil do que escrever código — e esse é o seu novo valor central. Gestores de engenharia: parem de perguntar quantas pessoas a IA pode substituir; perguntem se o codebase de vocês merece ter loops rodando sobre ele. Cobertura de testes, completude da documentação, clareza arquitetural — isso costumava se chamar dívida técnica; agora é o imposto da automação. Se você está decidindo se vale investir: comece com um pequeno e preciso loop fechado — “rodar a suíte de testes às 3h, corrigir falhas, abrir um PR” — não um super-loop que faz tudo. Loops são um problema de engenharia, não de tamanho de modelo; suas habilidades de arquitetura definem até onde o seu roda. Se você está preocupado com suas habilidades: a habilidade mais escassa hoje não é escrever prompts, ajustar modelos ou curar dados. É julgamento — quando fazer loop, quando um humano entra em cena, e o quão bom é “bom o suficiente”. Seu loop de verificação é seu fosso competitivo.
Fontes: Addy Osmani, “Loop Engineering” (2026); entrevistas de Boris Cherny na @Scale, Sequoia AI Ascent e The Pragmatic Engineer; AI Builder Club, “Loop Engineering Guide” (2026); TechCrunch, “The AI world is getting loopy” (22 de junho de 2026); Tosea.ai, “What Is Loop Engineering? A Complete Guide” (2026).
