A frase que abriu o ciclo veio de Boris Cherny, criador do Claude Code na Anthropic, em uma thread no X: “Eu não faço mais prompt no Claude. Eu tenho loops rodando que fazem prompt no Claude e decidem o que fazer. Meu trabalho é escrever loops.” Em maio, o mesmo Cherny já tinha declarado publicamente que o termo “vibe coding”, eleito palavra do ano pelo dicionário Collins em novembro de 2025, estava esgotado como descrição do que ele faz no dia a dia. O sucessor que está ganhando tração em junho de 2026 tem nome: loop engineering.
A expressão apareceu em maio e explodiu no início de junho, quando o engenheiro do Google Addy Osmani publicou o artigo “Loop Engineering” no blog dele. O tuíte de anúncio somou 2,3 milhões de visualizações e 338 respostas em poucas horas. Duas semanas depois, a LangChain publicou “The Art of Loop Engineering”, assinado pela engenheira Sydney Runkle, com uma taxonomia própria em quatro camadas. Acelerou o suficiente para o Hacker News registrar pelo menos cinco posts sobre o tema em menos de um mês.
A pergunta razoável é: trata-se de um conceito novo de verdade ou só de uma palavra nova rotulada em práticas que já existiam? A resposta curta: as duas coisas, e a diferença importa.
🚨 Vagas abertas para o nosso grupo de ofertas que vai te fazer economizar MUITO!
Do prompt ao loop: o que mudou
Até 2024, devs que usavam IA tratavam o modelo como uma ferramenta pontual: um autocomplete mais esperto no melhor caso, um chatbot no pior. A conversa era transacional. O humano escrevia um prompt, recebia uma resposta, aceitava, rejeitava ou refinava. Esse modelo continua existindo, mas deixou de ser o mais avançado.
O que Cherny, Osmani e Runkle descrevem é diferente. O humano escreve um pequeno programa, um loop, que orquestra agentes de IA em ciclos contínuos. O loop dispara o agente, avalia o resultado com um verificador (determinístico ou um segundo LLM funcionando como juiz), devolve o feedback para o agente, e itera até que o resultado satisfaça um critério. O humano só entra quando o loop precisa de manutenção, de um novo critério de qualidade, ou quando o resultado está bom o bastante para virar código de produção.
“Você não deveria estar fazendo prompt em coding agents. Você deveria estar desenhando loops que fazem prompt nos seus agents”, resumiu Peter Steinberger, ex-PSPDFKit, no tuíte que Osmani usou para abrir o artigo. A frase é uma declaração de princípios: o ativo de engenharia deixou de ser o prompt e passou a ser o loop.
O que tem dentro de um loop
A contribuição mais didática do texto de Osmani é a decomposição em cinco blocos, mais um opcional:
- Automações e gatilhos. O loop não espera alguém clicar “rodar”. Ele acorda por cron, webhook, mensagem no Slack, evento de CI, commit no GitHub. Pense no “docs agent” da própria LangChain: ele dispara toda vez que alguém posta em #docs-plz.
- Worktrees isolados. Cada execução roda numa cópia separada do repositório, para que múltiplos loops possam trabalhar em paralelo sem pisar um no pé do outro. Claude Code e OpenAI Codex já embutem isso.
- Skills e plugins. Pacotes reutilizáveis (um SKILL.md, em geral) que carregam contexto, ferramentas e instruções específicas para um domínio. É a primitiva que substitui o “system prompt artesanal” de cada projeto.
- Sub-agentes. Um agente que delega para outros agentes, em geral com custo de execução menor. O loop principal é o gerente; os sub-agentes são os times.
- Memória persistente. O loop lembra de tentativas anteriores, falhas e sucessos, em arquivos locais ou em vector stores. Sem memória, todo ciclo começa do zero.
- Verificadores (opcional, mas quase sempre presente). Um grader que checa o output antes de aceitar. Pode ser um teste automatizado, um lint, um LLM-as-judge avaliando qualidade subjetiva.
A taxonomia da LangChain é complementar. Runkle organiza os loops em quatro camadas sobrepostas:
- Loop 0 (agente): o LLM chama ferramentas até completar uma tarefa. É a base.
- Loop 1 (verificação): entra o grader. O output precisa passar num teste para ser aceito.
- Loop 2 (dirigido por eventos): o loop dispara sozinho, sem humano clicando. É onde a automação deixa de ser demo e vira rotina.
- Loop 3 (hill climbing): traces de produção alimentam um agente de análise que reescreve os próprios prompts, ferramentas e graders. O sistema melhora a si mesmo.
Existe ainda um nível além, descrito em literatura adjacente: o Loop 4 (meta-otimização), em que os resultados de eval alimentam o fine-tuning de modelos open-weight. Não faz parte da taxonomia oficial da Runkle, mas completa o quadro mental de quem está pensando o sistema inteiro.
Quem está construindo isso (e o que já dá para usar)
A diferença entre “loop engineering” como buzz e como prática está no fato de as primitivas já existirem, embarcadas nos produtos comerciais dos dois principais laboratórios do Vale do Silício.
O OpenAI Codex (93 mil estrelas no GitHub, escrito em Rust) ganhou uma aba “Automations” com prompt, cadência e ambiente, mais um inbox de triagem, e os comandos /loop (executa repetidamente) e /goal (roda até concluir). O Claude Code (134 mil estrelas no GitHub) tem /loop, /goal, scheduled tasks, hooks, integração com GitHub Actions e a pasta .claude/agents/ para sub-agentes. Os dois compartilham o suporte a skills, plugins e ao Model Context Protocol (MCP), o padrão aberto de conexão com ferramentas externas.
Para quem prefere começar sem pagar assinatura, três projetos open source se anunciam explicitamente como ferramentas de loop engineering:
- LoopFlow (junho de 2026): workflows em YAML para Claude Code, com verificação independente, teto de custo de tokens, memória e worktree isolado.
- Neuralyzer: utilitário para o agente limpar o próprio contexto de sessão e reexecutar a primeira mensagem, evitando loops que travam em lixo acumulado.
- Securing the Ralph Wiggum Loop: camada de DevSecOps para loops de coding agents, baseada no plugin “ralph-wiggum” que Geoffrey Huntley popularizou em 2025 e que Cherny já cita como peça do próprio stack desde janeiro.
Fonte primária do termo — “Loop Engineering”, por Addy Osmani (engenheiro do Google). O post de maio de 2026 que disparou o tuíte de 2,3 milhões de visualizações e consolidou a nomenclatura.
Taxonomia em 4 loops — “The Art of Loop Engineering”, por Sydney Runkle (LangChain, junho de 2026). Onde aparece a decomposição em Loop 0 (agente) → Loop 3 (hill climbing) citada nesta matéria.
Dentro da OpenAI, Osmani relata, os loops rodam para “triagem diária de issues, sumarização de falhas de CI, briefings de commit, caça a bugs recentes”. É uso interno, não roadmap. A Anthropic não publicou números equivalentes, mas o volume de código que Cherny e o time do Claude Code afirmam produzir (259 PRs em 30 dias, segundo tuíte dele de dezembro de 2025) sugere que a automação está ativa, não só no discurso.
O que sobra para o humano
Aqui mora a discussão que separa matéria ingênua de matéria útil.
O próprio Osmani abre o artigo com um aviso: “Você precisa tomar cuidado com custo de tokens. Os padrões de uso variam brutalmente se você é rico em tokens ou pobre em tokens”. Sub-agentes rodando em paralelo podem multiplicar o consumo por 5x a 10x em relação a uma sessão simples. Um loop mal desenhado não é só caro: é um loop que gasta dinheiro até alguém perceber.
Há também o que Jeena, em relato recente, chamou de “comprehension debt”: código que passa em todos os testes e reviews automatizados, mas que ninguém no time entende de verdade. O humano virou um supervisor de linha de produção, não um autor. A curto prazo o sistema parece mais produtivo. A médio prazo, a base de código vira território inabitável. É o mesmo dilema que o debate sobre o futuro da engenharia de software já mapeou, agora com um nome técnico.
Karpathy, criador do termo “vibe coding” em fevereiro de 2025, já tinha alertado sobre o risco oposto, o do “cognitive surrender”: acostumar-se a aceitar output sem questionar. Quando o loop é bem desenhado, esse risco se multiplica. O verificador é só mais um LLM. Dois LLMs concordando não são o mesmo que dois humanos revisando.
Por fim, vale notar o que não apareceu. Não há até o momento um paper revisado por pares sobre loop engineering. A literatura mais próxima é a de agentic AI e a de reinforcement learning com feedback loops, mas o termo em si é uma construção recente do ecossistema dev, não da academia. A nomenclatura chegou primeiro que a ciência.
O que isso significa para quem está no Brasil
Para o dev brasileiro que já usa Claude Code, Codex ou Cursor no dia a dia, a mudança prática é reorganizar o que já tem. Não é preciso comprar ferramenta nova. Os comandos /loop e /goal já estão lá. A aba de automations do Codex também. O ganho vem de usar essas primitivas com critério, não de instalar mais um plugin.
O cenário que a LangChain descreve internamente é útil como gabarito: automações para o trabalho repetitivo (CI quebrando, issues velhas, documentação), loops com verificador explícito para tarefas que pedem qualidade medida (geração de testes, refatoração), hill climbing para os casos em que a definição de “bom” muda com o tempo (recomendações, priorização de backlog).
Há também uma janela para times brasileiros construírem opinião sobre o tema. O vocabulário está sendo cunhado agora, e o debate sobre quem regula, quem audita, quem responde quando um loop autônomo faz besteira está em aberto. Quem define essas práticas primeiro define o padrão.
O hype do loop engineering é real, e merece ser tratado como hype. Mas por baixo dele tem uma mudança concreta: o trabalho de engenharia de software está deixando de ser sobre o que o dev digita para ser sobre o sistema que o dev desenha. Isso não é pouca coisa, mesmo que a palavra nova canse em seis meses.
