Loop Engineering: A Evolução Final da Engenharia de Agentes de IA

A engenharia de prompts morreu. Longa vida ao loop

Em janeiro de 2023, a comunidade de inteligência artificial vivia o auge do prompt engineering. Engenheiros dedicavam horas a refinar instruções textuais, testando variações de palavras-chave na esperança de extrair respostas mais precisas dos grandes modelos de linguagem. Um ano depois, a atenção migrava para o context engineering — a arte de alimentar o modelo com o conjunto certo de documentos antes de formular a pergunta. No fim de 2025, o harness engineering assumiu o protagonismo, com frameworks como Claude Code e OpenClaw permitindo que desenvolvedores orquestrassem fluxos de trabalho complexos em torno de agentes de IA.

Em meados de 2026, o ciclo evolutivo completou mais uma volta. O termo que circula em discussões no X, fóruns de engenharia e mesas de produto de empresas de tecnologia é loop engineering — a disciplina de projetar sistemas autônomos recursivos nos quais a inteligência artificial executa, avalia, corrige e repete até atingir um objetivo definido, sem intervenção humana.

Onde tudo começou

A ideia não surgiu do nada. Em janeiro de 2026, o engenheiro de software australiano Geoffrey Huntley publicou o que chamou de ralph loop: um experimento em que um agente recebia um objetivo e era deixado para rodar por horas, encontrando, planejando e resolvendo tarefas por conta própria. Ninguém estava no controle. Quando o contexto do modelo se esgotava, um script em bash inicializava uma nova instância que retomava exatamente onde a anterior parou, usando o histórico do Git e notas deixadas em disco como memória persistente.

Alguns meses antes, a Anthropic havia publicado uma descrição quase idêntica partindo da pesquisa: agentes trabalhando em turnos, cada um sem lembrança do anterior, dependendo de registros em disco para manter a continuidade. O princípio era o mesmo — a persistência do progresso não dependia da memória interna do modelo, mas da infraestrutura ao redor dele.

Peter Steinberger, criador do OpenClaw, acendeu o debate público. Boris, líder da equipe do Claude Code na Anthropic, resumiu a mudança de paradigma com uma frase que se tornou referência: “Movi-me além do prompting manual. Agora projeto ciclos autônomos que direcionam o Claude e navegam o caminho de execução por mim. Meu trabalho real é engenhar os loops.”

Prompt versus Loop: a diferença fundamental

As três gerações anteriores — prompt, context e harness engineering — compartilhavam uma premissa: o humano permanecia no controle, guiando o agente a cada decisão. Um prompt é uma instrução isolada; o modelo gera uma resposta e para, aguardando o próximo input. Um loop é um objetivo recursivo: definido o propósito, o sistema navega o circuito inteiro de forma independente, persistindo até que a meta seja alcançada.

A analogia mais precisa vem da manufatura. Prompt engineering é como operar uma máquina manualmente — cada peça exige decisão e ação humana. Loop engineering é como configurar uma linha de produção automatizada com sensores de qualidade; uma vez calibrada, ela fabrica sem supervisão, e o operador intervém apenas quando os indicadores sinalizam anomalia.

Os seis blocos de construção de um loop

A arquitetura de um loop funcional foi sistematizada por Addy Osmani, engenheiro do Chrome na Google, em uma estrutura de seis blocos interdependentes. Embora a nomenclatura varie entre plataformas, a funcionalidade subjacente é consistente.

1. Automações (Automations)

Jobs agendados que vasculham fontes de trabalho — issues no GitHub, feedback de usuários, tickets no Linear — e fazem a triagem antes que qualquer humano olhe para a tela. É o gatilho que dá início ao ciclo.

2. Árvores de trabalho (Worktrees)

Checkouts paralelos do mesmo repositório, cada um isolado em sua própria branch. Quando múltiplos agentes operam simultaneamente, os worktrees impedem que um sobrescreva os arquivos do outro, eliminando conflitos de merge antes que existam.

3. Habilidades (Skills)

Documentação viva do projeto: convenções de código, passos de build, armadilhas conhecidas, padrões arquiteturais. Escrito uma vez, consumido por todo agente em cada passagem. Sem skills, cada execução obriga o modelo a rededuzir o contexto do zero, desperdiçando tokens e tempo.

4. Plugins e conectores

Construídos sobre o protocolo MCP (Model Context Protocol), permitem que o loop ultrapasse o sistema de arquivos e alcance ferramentas externas — rastreadores de issues, bancos de dados, ambientes de staging, canais do Slack. São as pontes que conectam o agente ao ecossistema real da organização.

5. Subagentes

O modelo que escreve o código não é o mesmo que o avalia. Essa separação resolve o viés central da IA generativa: um agente é um avaliador frouxo do próprio trabalho. Ao delegar a revisão a um subagente independente — no caso do exemplo que veremos adiante, o CodeRabbit —, o loop adquire um mecanismo de controle de qualidade que o modelo original não conseguiria reproduzir sozinho.

6. Estado (State)

O bloco mais subestimado da arquitetura. Memória persistente em disco — um arquivo markdown ou um quadro no Linear registrando o que foi entregue, o que falhou e o que permanece aberto. O modelo reseta entre execuções, mesmo quando o repositório não. Sem estado, cada rodada começa do zero.

Um loop real: do feedback ao deploy sem mãos humanas

Em fevereiro de 2026, Hendrik Krack, engenheiro do CodeRabbit, publicou um relato detalhado de um loop que montou para um projeto pessoal. O sistema funcionava assim: o loop começava puxando feedback real de usuários — requisições, bugs reportados, sugestões. Uma etapa de triagem decidia quais valiam a pena. Para cada item aprovado, um agente de planejamento convertia a requisição em um plano de implementação. O Claude então escrevia o código. O CodeRabbit revisava o diff em loop até que o resultado voltasse limpo — sem achados críticos. Se o CodeRabbit apontasse problemas, o Claude corrigia e o ciclo de revisão recomeçava.

Com o diff aprovado, o Claude executava os testes. Se passassem, o loop aguardava o pipeline de CI. Tudo verde, o merge acontecia automaticamente, seguido de uma verificação pós-deploy. O humano só intervinha em duas pontas: definindo o que era prioritário e validando o resultado final. O loop inteiro rodava sobre um único job agendado e um arquivo de estado — um log simples em markdown.

O componente que tornava o sistema confiável era o quality gate: nada era mergeado sem que os testes passassem e a revisão do CodeRabbit estivesse limpa. O “pronto” era um sinal verificável, não a opinião do Claude sobre o próprio trabalho. Krack manteve o loop restrito a mudanças pequenas e checáveis — do tipo que um júnior cuidadoso conseguiria entregar a partir de um ticket. Decisões que exigiam julgamento real ficavam para ele. O loop não tomava essas decisões; apenas executava, repetidamente, aquilo que ele já havia codificado.

Quando construir um loop — e quando não

Nem todo problema merece um loop. A heurística é simples: loops recompensam alvos estáveis. Um refactoring de codebase tem uma meta bem definida — o código compila, os testes passam, o comportamento se mantém. Um verificador único cobre todas as iterações, escrito uma vez e reutilizado do início ao fim.

Quando as condições mudam a cada execução, a matemática se inverte. Se cada rodada precisa de uma nova definição de “pronto”, o tempo gasto reescrevendo o verificador consome o que o loop supostamente pouparia. O resultado é um sistema mais complexo e mais frágil do que a abordagem manual.

Meta estável, construa o loop. Alvo em movimento, mantenha o prompt manual.

Implicações para o mercado de trabalho e para DevSecOps

O loop engineering acelera uma realidade que já se desenhava: o engenheiro de software do futuro passa menos tempo escrevendo código e mais tempo projetando sistemas, definindo guardrails e calibrando quality gates. A programação direta não desaparece — ela se torna um instrumento dentro de um fluxo maior, em vez de ser o próprio fluxo.

Para profissionais de DevOps, SRE e, particularmente, DevSecOps, a implicação é direta. Os mesmos princípios de observabilidade, automação e orquestração que governam infraestrutura aplicam-se à coordenação de agentes de IA. Worktrees são containers para código. Estado é telemetry. Quality gates são alertas. O vocabulário muda; a mentalidade permanece. Ainda assim, uma questão de segurança permanece aberta: quem audita o loop quando ninguém está dentro dele? A integridade do quality gate é o ponto mais sensível — se o verificador for comprometido, o loop inteiro entrega código sem supervisão efetiva.

O que vem depois

Loop engineering não é um destino — é uma estação. A próxima fronteira já se desenha em discussões sobre multi-loop orchestration, onde múltiplos loops operam em paralelo, cada um com seu domínio de responsabilidade, coordenados por um orquestrador superior. As perguntas que a comunidade começa a formular são de natureza sistêmica: como loops interagem quando seus objetivos entram em conflito? Como escalar sem perder a qualidade que o quality gate garante? Quem audita o loop quando ninguém está dentro dele?

Por enquanto, o loop engineering oferece algo concreto e imediatamente aplicável: uma forma de tirar o humano do meio sem abrir mão do controle. Não é automação cega — é automação com verificação embutida. E essa, para a engenharia de software de 2026, pode ser a evolução mais prática do ano.

Para uma visão complementar sobre a aplicação de loop engineering em ambientes cloud e orquestração multi-loop, consulte a análise detalhada publicada no CloudAI.pt.