Por Jean Paul T Neumann | Vertex Instituto de Tecnologia e Inovação

Introdução

Nos últimos anos aprendemos coletivamente a conversar com modelos de linguagem. Surgiu daí uma disciplina informal, o Prompt Engineering, dedicada a formular boas instruções: dar contexto, delimitar escopo, oferecer exemplos, pedir o formato certo de saída. Essa habilidade continua valendo.

O que mudou é que os modelos deixaram de ser apenas geradores de texto e passaram a ser agentes: leem arquivos, executam comandos, consultam sistemas, testam o próprio trabalho e decidem se tentam de novo. Quando o modelo age em ciclos, o objeto de projeto deixa de ser a frase que enviamos e passa a ser o ciclo inteiro. É aí que entra o Loop Engineering.

A equipe do Claude Code, da Anthropic, oferece uma definição enxuta: um loop é um agente repetindo ciclos de trabalho até que uma condição de parada seja satisfeita. Loop Engineering, portanto, é a prática de projetar deliberadamente esses ciclos: o que os dispara, como o agente verifica o próprio trabalho, o que significa “pronto” e quando parar.

De onde vem o conceito

Vale registrar a linhagem, porque ela explica o conceito melhor que qualquer definição.

O ancestral direto é o Ralph loop, publicado por Geoffrey Huntley em julho de 2025: um script de shell que reinicia o agente com o mesmo prompt e contexto novo a cada iteração, até não restar tarefa em aberto. Deliberadamente rudimentar, funcionou bem o bastante para virar referência.

O nome atual apareceu em junho de 2026. Peter Steinberger sintetizou a ideia afirmando que não se deve mais promptar agentes de codificação, e sim desenhar os loops que promptam os agentes. Boris Cherny, responsável pelo Claude Code na Anthropic, declarou que não prompta mais o Claude, que tem loops rodando que promptam o Claude, e que seu trabalho agora é escrever loops. Addy Osmani, do Google, consolidou o conjunto em ensaio que deu nome e anatomia à prática. O post do blog do Claude que serviu de base para este artigo é a formalização do fornecedor, publicada ao fim daquele mês.

A literatura já organiza a evolução em quatro camadas, e a leitura correta é de empilhamento, não de substituição.

Uma comparação didática

Uma analogia ajuda. O Prompt Engineering se parece com escrever um bom pedido a um colaborador competente: quanto mais claro o pedido, melhor o resultado. Ainda assim, quem confere a entrega e decide se ela precisa de mais uma rodada é você, a cada rodada.

O Loop Engineering se parece com desenhar um processo: em vez de acompanhar cada tentativa, você define o objetivo, o critério de aceite, o método de verificação, a periodicidade e o limite de tentativas. O colaborador repete o ciclo sozinho até que o critério seja atendido, e você se envolve no desenho, não em cada iteração.

A diferença central cabe em uma frase: no Prompt Engineering, o critério de parada é você; no Loop Engineering, o critério de parada está no sistema.

Dimensão	Prompt Engineering	Loop Engineering
Objeto de projeto	A instrução	O ciclo de trabalho
Unidade de trabalho	Um turno	Uma condição de parada
Papel do humano	Revisor de cada iteração	Arquiteto do processo
Fim do trabalho	O modelo julga que terminou	O critério é medido e verificado
Verificação	Manual, feita por você	Codificada em skills, testes e métricas
Falha típica	Instrução ambígua	Critério de sucesso vago ou ausente
Melhor para	Explorar, decidir, tarefas curtas	Trabalho verificável, recorrente e em escala

 

Vale insistir: não são práticas concorrentes. Um loop mal instruído continua produzindo trabalho ruim, apenas mais rápido e mais vezes. O prompt bem escrito é o insumo do loop bem desenhado.

Vantagens do Loop Engineering

Elimina a parada prematura. Sem critério explícito, o agente decide sozinho o que é “bom o suficiente” e costuma encerrar cedo. Com o critério definido, um avaliador confere a condição e devolve o trabalho ao agente até que ela seja atendida. Critérios determinísticos, como número de testes aprovados ou uma pontuação mínima, são especialmente eficazes porque não dependem de julgamento subjetivo.

Transfere a verificação para o sistema. Documentar em uma skill o que significa “verificado” faz o agente conferir o próprio trabalho de ponta a ponta. Quanto mais quantitativa a checagem, melhor a autoverificação.

Remove o humano do caminho crítico. Em muitos processos o gargalo não é a capacidade do modelo, mas o tempo até alguém revisar e escrever o próximo prompt. O loop absorve essa espera, e torna barato o trabalho recorrente de ciclo estável e entradas variáveis: triagem de chamados, atualização de dependências, acompanhamento de um pull request.

Dá previsibilidade de custo. Limites de turnos, intervalos adequados, modelos menores para tarefas simples e scripts determinísticos no lugar de raciocínio repetido tornam o consumo controlável. Um loop sem fronteiras é caro; um loop com fronteiras é orçável.

Gera qualidade cumulativa. Aqui está o ganho mais subestimado. Quando um resultado não atende ao padrão, a correção não deve parar no caso individual: ela deve ser codificada no sistema, na skill, no critério, na revisão, de modo que as iterações futuras já nasçam melhores. O erro deixa de ser retrabalho e vira ativo.

A anatomia de um loop

Osmani descreve cinco peças, mais uma sexta que costuma ser esquecida.

1. Automações. O gatilho por agenda ou evento, que faz descoberta e triagem sozinho. É o que transforma uma execução única em loop de verdade.
2. Worktrees. Diretórios de trabalho isolados, para que agentes em paralelo não colidam nos mesmos arquivos. Sem isolamento, paralelismo vira desordem.
3. Skills. O conhecimento do projeto por escrito, no formato SKILL.md, para que o agente não redescubra suas convenções a cada execução.
4. Plugins e conectores. Via MCP, é o que liga o agente ao rastreador de chamados, ao banco, ao canal de mensagens. É a diferença entre um agente que diz “aqui está a correção” e um loop que abre o pull request, vincula o ticket e avisa o time.
5. Sub-agentes. Um propõe, outro confere. O modelo que escreveu o código é indulgente demais ao corrigir a própria prova.
6. Memória. Um arquivo markdown, um board, qualquer coisa que viva fora da conversa e registre o que foi feito e o que vem a seguir. O modelo esquece tudo entre execuções, então o estado precisa estar em disco, não no contexto. O agente esquece; o repositório não.

Um detalhe relevante para quem decide arquitetura: esses primitivos não são exclusivos de um fornecedor. As mesmas seis peças existem no Claude Code e no Codex, inclusive o comando /goal nos dois. Uma vez percebida a forma comum, a escolha da ferramenta importa menos que o desenho do loop.

Os tipos de loop

A classificação proposta pela equipe do Claude Code organiza os loops por gatilho, critério de parada e tipo de tarefa adequada.

Turn based. O loop que já usamos todos os dias sem perceber. Cada prompt inicia um ciclo em que o agente reúne contexto, age, confere e responde, terminando quando o modelo julga ter concluído. Serve para tarefas curtas e exploratórias. Você delega a verificação.

Goal based. Um único turno raramente basta em tarefas complexas, e agentes se saem melhor quando podem iterar. Ao definir o que significa “pronto”, o ciclo continua até a meta ser atingida ou o limite de tentativas se esgotar. Você delega a condição de parada.

Time based. Alguns trabalhos são recorrentes ou dependem de sistemas externos, e a forma mais simples de conversar com um sistema externo é consultá-lo em intervalos e reagir ao que mudou. Termina quando você cancela ou quando o trabalho se esgota. Você delega o gatilho.

Proativo. A composição dos anteriores, disparada por evento ou agenda, sem humano em tempo real. Serve para fluxos recorrentes e bem definidos. Você delega o próprio prompt. A recomendação prática é rotear a rotina para modelos menores e rápidos, reservando o modelo mais capaz para as decisões de julgamento.

Loop	Você delega	Use quando	Recurso
Turn based	A verificação	Está explorando ou decidindo	Skills de verificação
Goal based	A condição de parada	Sabe como é o “pronto”	/goal
Time based	O gatilho	O trabalho chega por agenda	/loop, /schedule
Proativo	O prompt	O trabalho é recorrente e definido	Todos os anteriores

Nem toda tarefa exige um loop complexo. Comece pela solução mais simples e adote esses padrões de forma seletiva.

Um exemplo prático no Claude

O melhor caminho para entender a diferença é ver a mesma tarefa subindo de degrau. Suponha a manutenção do portal institucional.

Nível 1, turn based.
O ponto de partida é um prompt comum:

Otimize o carregamento da página inicial do portal e rode os testes.

O agente lê o código, altera, executa os testes e devolve algo que acredita funcionar. Você confere manualmente.

Nível 2, verificação codificada.
Em vez de repetir a conferência a cada rodada, ela vira um SKILL.md:

—

name: verificar-mudanca-frontend

description: Verifica qualquer alteração de interface de ponta a ponta antes de declará-la concluída.

—

# Verificando alterações de frontend

Nunca reporte uma alteração como concluída apenas porque a edição foi bem sucedida.

Verifique como um revisor humano faria:

1. Suba o servidor e abra a página alterada no navegador.
2. Interaja com a alteração e registre capturas de tela antes e depois.
3. Confira o console: zero novos erros ou avisos.
4. Rode um trace de performance e audite os Core Web Vitals.

Se qualquer etapa falhar, corrija e recomece do passo 1.

Não devolva trabalho parcialmente verificado.

Nível 3, goal based.
Com a verificação codificada, o critério pode ser explicitado e o agente itera sozinho:

/goal elevar o Lighthouse da página inicial para 90 ou mais, parar após 5 tentativas.

Repare nos dois elementos que tornam isso viável: uma métrica objetiva e um teto de tentativas.

Nível 4, time based e proativo.
Para o trabalho que depende de sistemas externos, o gatilho vira tempo, e a composição de tudo vira rotina:

/loop 10m verifique meu pull request, responda aos comentários de revisão e corrija o CI que estiver falhando.

 

/schedule a cada hora: verifique o canal de feedback do portal em busca de relatos de erro.

/goal: não pare até que todo relato encontrado nesta execução seja triado, tratado e respondido.

Ao corrigir um erro, use um workflow para explorar soluções em paralelo e submetê-las a um revisor adversarial.

Do nível 1 ao nível 4, o texto que escrevemos não ficou muito maior. O que mudou foi a natureza do que ele descreve: saímos de uma instrução e chegamos a um sistema.

O contraponto: o que o loop não resolve

Um artigo honesto sobre o tema precisa registrar que o entusiasmo não é unânime, e que o próprio Osmani se declara cético. Três riscos ficam mais agudos justamente quando o loop melhora.

Custo. Loops consomem muito mais tokens que uma interação manual bem feita, porque cada iteração reenvia histórico, logs e contexto. Não é hipótese: reportagens de junho de 2026 indicam que a Uber passou a limitar seus engenheiros a 1.500 dólares por pessoa por mês por ferramenta depois de consumir o orçamento anual de IA em quatro meses. Intervalos maiores, tetos de iteração e detecção de ausência de progresso deixam de ser refinamento e viram requisito.

Dívida de compreensão. Quanto mais rápido o loop entrega código que ninguém escreveu, maior a distância entre o que existe e o que a equipe entende. Um loop eficiente apenas faz essa dívida crescer mais depressa.

Rendição cognitiva. Quando o loop roda sozinho, é tentador parar de ter opinião e aceitar o que voltar. Duas pessoas podem construir o mesmo loop e obter resultados opostos: uma o usa para avançar mais rápido em trabalho que domina, a outra para não precisar dominar o trabalho. O loop não sabe a diferença.

Há ainda um contraponto estrutural que merece atenção. Gergely Orosz reuniu vozes questionando se o loop não seria um recurso temporário, útil enquanto os harnesses ainda não faziam o mesmo a partir de um único prompt, e sugerindo que, fora de quem constrói infraestrutura de IA, dominar context engineering talvez renda mais. É uma hipótese razoável. Ainda assim, mesmo que a mecânica seja absorvida pelas ferramentas, a habilidade que sobra é a mesma: saber declarar o que é “pronto” e como se verifica.

Do lado prático, quatro cuidados sustentam a qualidade: manter a base de código limpa, porque o agente segue os padrões que encontra; dar ao agente um meio de verificar o próprio trabalho; deixar a documentação acessível; e usar um segundo agente para revisão, já que um revisor com contexto novo é menos enviesado que o agente que produziu a solução.

Conclusão

Prompt Engineering e Loop Engineering não são gerações sucessivas de uma mesma técnica, em que a segunda aposenta a primeira. São camadas. A instrução clara continua sendo o insumo; o ciclo bem desenhado é o que transforma esse insumo em capacidade instalada.

A mudança de mentalidade que isso exige é significativa, sobretudo para quem lidera equipes e processos. Deixamos de perguntar “como escrevo o melhor prompt para esta tarefa?” e passamos a perguntar “em qual parte deste trabalho eu ainda sou o gargalo, e o que exatamente eu poderia delegar: a verificação, a condição de parada, o gatilho ou o próprio pedido?”.

Para começar, a recomendação é modesta. Olhe para o trabalho que sua equipe já faz, escolha uma tarefa em que você seja o gargalo e pergunte se é possível escrever a verificação, se o objetivo está claro o suficiente para virar critério e se o trabalho chega em intervalos previsíveis. Rode o loop, observe onde ele trava ou se excede, e itere sobre o desenho. Não é necessário, nem desejável, começar pela rotina autônoma mais sofisticada.

E é por isso que a vantagem competitiva não ficará com quem escreve o prompt mais engenhoso, habilidade cada vez mais difundida e cada vez menos escassa. Ficará com quem souber codificar o próprio padrão de qualidade em sistemas que o repetem sem supervisão. Prompt é conhecimento tácito; loop é conhecimento institucionalizado. Construa o loop, mas construa como quem pretende continuar sendo o engenheiro, e não apenas a pessoa que aperta o botão.

 

Referências

• Anthropic. Getting started with loops. Claude Blog, 30 de junho de 2026. https://claude.com/blog/getting-started-with-loops
• OSMANI, Addy. Loop Engineering. 7 de junho de 2026. https://addyosmani.com/blog/loop-engineering/
• HUNTLEY, Geoffrey. Ralph Wiggum as a software engineer. Julho de 2025.
• OROSZ, Gergely. What is “loop engineering”?. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/what-is-loop-engineering