Loop Engineering – Como Projetar Agentes de IA Que Entregam Código Sozinhos
Os Agentes de IA são úteis porque nos ajudam a automatizar tarefas e executar ações no mundo real. Eles podem ler um repositório, abrir uma issue, rodar testes, chamar uma API, consultar um banco, resumir falhas de CI, criar um pull request e voltar com um relatório claro. Mas fazer com que agentes realizem trabalhos valiosos de forma confiável exige mais do que um bom modelo. Exige uma estrutura bem desenhada, com contexto, ferramentas, memória, verificação e limites.
O algoritmo mais simples de um agente parece quase ingênuo: entregue contexto a um modelo de linguagem, permita que ele chame ferramentas e deixe que ele continue em um loop até concluir a tarefa. Esse é o loop fundamental. Só que, na prática, os agentes modernos não vivem de um único loop. Eles vivem de vários loops coordenados: loops de descoberta, loops de execução, loops de revisão, loops de correção, loops de agendamento e loops de parada.
É aqui que entra o Loop Engineering. Em vez de você ficar digitando prompts a cada etapa, você projeta o sistema que vai provocar, orientar e limitar o agente. A discussão ganhou força em 2026 com desenvolvedores como Peter Steinberger e Boris Cherny defendendo que o trabalho está saindo do “enviar prompt ao agente” para “desenhar loops que enviam prompts aos agentes”. Addy Osmani resumiu essa mudança como a passagem do prompt manual para um sistema que encontra trabalho, distribui, verifica, registra estado e decide o próximo passo.
Neste artigo, vamos ajudar você a compreender o que é Loop Engineering.
E se você quiser compreender como aplicar isso em projetos do mundo real, com loop, arquitetura e automações completas, você encontra projetos práticos na Formação AI Software Engineer 4.0, como por exemplo neste projeto:
Um Loop é Um Conjunto de 6 Peças e 1 Pergunta
Por baixo do hype, um loop funcional tem seis partes. Elas parecem simples quando aparecem numa tabela, mas é dentro de cada uma que o sistema se sustenta ou começa a vazar custo, contexto e confiança.
Você não precisa mais construir tudo isso com scripts frágeis e improvisados. Codex e Claude Code já incorporam várias dessas peças.
No Codex, automações podem rodar tarefas recorrentes, enviar achados para uma inbox de triagem e arquivar execuções sem achados. Essas automações também podem usar skills e worktrees para manter o fluxo mais organizado.
No Claude Code, existem diferentes formas de agendamento: o /loop serve para recorrência dentro de uma sessão, tarefas locais dependem da máquina ligada e Routines podem rodar na infraestrutura da Anthropic com gatilhos por agenda, API ou eventos do GitHub.
A ferramenta importa, mas não é o centro. O centro é o desenho do loop.
Estado é a Única Coisa Que a Próxima Execução Herda
Comece pela base, porque tudo o mais depende dela.
Um modelo esquece quando a execução termina. A conversa pode até parecer memória, mas ela morre com a sessão, com a janela de contexto ou com a próxima execução. Se o loop precisa continuar amanhã de onde parou hoje, a memória não pode viver apenas no chat. Ela precisa viver fora.
Na prática, isso pode ser um STATUS.md no repositório, um arquivo de progresso, uma issue no Linear, um quadro de projeto ou qualquer fonte persistente que o agente consiga ler e atualizar. O importante é que esse estado responda a quatro coisas: o que já foi feito, o que está em andamento, o que falhou e o que o loop não tem permissão para tocar.
Pense no loop como um turno da noite que você não assiste. Você não será julgado pelo que ele tentou fazer às três da manhã. Você será julgado pelo bilhete que encontrará na mesa às nove. Projete esse bilhete primeiro. O restante do loop fica mais fácil de desenhar.
Automações São a Diferença Entre Um Loop e Uma Execução Isolada
Um loop só merece esse nome quando dispara por conta própria.
No Codex, uma automação pode ser configurada para rodar em um projeto, com um prompt, uma cadência e um ambiente. Ela pode procurar falhas recentes, resumir CI, investigar bugs introduzidos por commits recentes ou fazer triagem de issues. Quando há achados, eles aparecem na triagem. Quando não há nada relevante, a execução pode ser arquivada.
No Claude Code, vale separar bem as primitivas. O /loop é útil para repetir um prompt enquanto a sessão está viva. Routines são mais adequadas para trabalhos recorrentes que precisam sobreviver ao notebook fechado, pois rodam na infraestrutura da Anthropic e podem ser acionadas por agenda, API ou GitHub.
Já o /goal é outra categoria: ele não roda por horário, mas por condição de conclusão. Você escreve o que precisa ser verdadeiro e o agente continua trabalhando até que essa condição seja satisfeita. A documentação do Claude Code descreve que, depois de cada turno, um modelo menor e rápido avalia se a condição foi cumprida.
A regra é simples: “todos os testes em test/auth passam” é uma condição de parada. “Deixe melhor” é um convite para gastar tokens sem saber quando parar. Ou seja, você precisa compreender claramente o que está desenvolvendo.
Worktrees Mantêm Agentes Paralelos Fora do Caminho Um do Outro
Quando você roda um agente, o problema é fazer ele entender a tarefa. Quando você roda vários, o problema passa a ser evitar que eles se atropelem.
Dois agentes escrevendo no mesmo arquivo podem criar a mesma bagunça de dois engenheiros alterando as mesmas linhas sem conversar. Um git worktree resolve parte disso ao permitir múltiplas árvores de trabalho ligadas ao mesmo repositório, cada uma com seu próprio diretório e branch. A documentação oficial do Git descreve justamente esse uso: trabalhar com mais de uma working tree no mesmo repositório.
Isso não elimina conflitos conceituais, mas elimina colisões mecânicas. Um agente pode investigar uma falha de autenticação em um worktree, enquanto outro refatora um módulo de billing em outro. As edições não se misturam até você decidir revisar e integrar.
Só existe uma ressalva: worktrees removem a colisão, não o gargalo. O teto continua sendo a sua capacidade de revisão. Você pode iniciar dez agentes. Isso não significa que consegue confiar em dez diffs sem ler.
Skills São Intenção Escrita Uma Vez
Um agente começa cada execução com lacunas. Se você não disser como seu projeto funciona, ele vai preencher essas lacunas com palpites. Alguns palpites serão úteis. Outros serão caros.
Skills resolvem esse problema transformando instruções recorrentes em capacidades reutilizáveis.
No Codex, uma skill é um diretório com um SKILL.md, instruções, metadados e recursos opcionais, como scripts e referências. Ela pode ser chamada explicitamente ou escolhida quando a descrição combina com a tarefa.
No Claude, skills também empacotam instruções, metadados e recursos para que o modelo use quando forem relevantes.
Sem skills, cada ciclo reaprende seu projeto do zero. Com skills, o loop carrega seu jeito de trabalhar: comandos de build, padrões de teste, convenções de PR, regras de segurança, áreas proibidas e critérios de revisão.
É aqui que o loop começa a ficar mais parecido com um sistema operacional de engenharia do que com um chatbot esperto.
Connectors Permitem Que o Loop Aja, Não Apenas Responda
Um loop que só enxerga arquivos locais é limitado. Ele pode sugerir, mas não consegue operar de verdade.
Connectors mudam isso. Com MCP, os agentes conseguem se conectar a sistemas externos de forma padronizada, como arquivos locais, bancos de dados, ferramentas, fluxos de trabalho e aplicações. A documentação oficial do Model Context Protocol o define como um padrão aberto para conectar aplicações de IA a sistemas externos.
Essa é a linha que separa um agente que diz “aqui está a correção” de um loop que abre o pull request, vincula o ticket, comenta no canal, executa uma verificação em staging e atualiza o estado quando tudo passa.
Com conectores, o agente deixa de ser apenas narrador. Ele vira operador. Por isso o escopo precisa ser explícito. Dar acesso de leitura a issues é uma coisa. Dar permissão para alterar branches, rodar deploy ou chamar APIs de produção é outra completamente diferente.
Subagentes Mantêm o Criador Longe do Revisor
O movimento de maior valor em qualquer loop é separar quem cria de quem verifica.
Um agente que escreveu a solução tende a aceitar sua própria explicação. Isso não é um defeito moral do modelo. É uma falha estrutural do desenho. O verificador precisa ter instruções diferentes, foco diferente e, em tarefas críticas, até um modelo diferente.
O padrão mais saudável é dividir papéis. Um agente explora o problema. Outro implementa a menor mudança possível. Um terceiro revisa contra testes, especificação e regras do projeto. Codex já oferece subagentes e agentes customizados definidos em arquivos de configuração, incluindo agentes com instruções e modelos específicos.
Essa segunda opinião custa tokens, porque cada subagente chama modelo e ferramentas. Então use onde o erro custa caro: segurança, billing, autenticação, migrações, dados de usuário e fluxos de deploy.
Como é Um Loop na Prática?
Imagine uma automação rodando toda manhã no repositório. Ela chama uma skill de triagem, lê falhas de CI da noite, issues abertas e commits recentes. Tudo que parece real vai para o STATUS.md, com contexto suficiente para você entender em poucos minutos.
Para cada achado relevante, o loop abre um worktree isolado. Um subagente investiga a causa. Outro propõe a menor correção. Um terceiro revisa contra testes, padrões do projeto e critérios da skill. Se passar, o connector abre o pull request, vincula o ticket e deixa um resumo curto. Se não passar, o achado volta para triagem com o motivo.
O que você encontra ao acordar não é uma parede de logs. É um repasse claro: o que foi encontrado, o que foi corrigido, o que foi verificado e o que precisa de decisão humana.
Você projetou o sistema uma vez. Não precisou enviar prompt a cada etapa.
Construa os Freios Antes de Sair da Frente
Esta é a parte que decide se o loop vira ativo ou passivo.
Um caso bastante citado de falha envolveu quatro agentes em um loop que rodou por onze dias e gerou 47 mil dólares em custo. O problema relatado não foi um modelo “maluco”. Foi uma arquitetura sem teto de orçamento, sem limite de passos e sem uma condição de parada eficaz. Dois agentes ficaram alimentando trabalho um para o outro até a conta aparecer.
No outro extremo, há relatos de frotas com cerca de cem agentes Codex consumindo mais de 1,3 milhão de dólares em trinta dias em um projeto patrocinado, com 603 bilhões de tokens e milhões de requisições. Esse caso mostra a potência da abordagem, mas também deixa claro que o cenário de fronteira não é a referência econômica de uma equipe comum.
A tecnologia é a mesma. A diferença são os freios.
Antes de aumentar a autonomia, defina o raio de impacto. Quais repositórios o loop pode tocar? Quais branches? Quais comandos? Quais APIs? Quanto dinheiro pode gastar? Quantos passos pode executar? Quando precisa parar? Quando precisa pedir revisão humana?
Freios primeiro. Potência depois.
Como os Loops Morrem?
Todo loop ruim costuma morrer de uma das mesmas formas.
A primeira é a recursão descontrolada. Um agente pede revisão, o outro pede mais análise, o primeiro expande, o segundo pede nova verificação e ninguém tem autoridade para encerrar. A cura é simples e pouco glamorosa: limite de passos, teto de custo e condição de parada.
A segunda é a morte silenciosa. A execução parece viva, mas está presa numa janela de contexto lotada, num erro repetido ou numa ferramenta que falha sempre do mesmo jeito. A cura é heartbeat, checkpoint e fases curtas, em vez de uma execução infinita tentando parecer inteligente.
A terceira é a caminhada aleatória. Sem uma condição verificável, o loop se afasta do objetivo enquanto produz atividade. Uma suíte de testes que passa é um ponto de chegada. “Parece melhor” não é.
A quarta é a dívida de compreensão. Quanto mais rápido o loop envia código que você não escreveu, maior fica a distância entre o que o repositório faz e o que você entende. Se você deixa isso correr tempo suficiente, para de ser Engenheiro de Software e vira apenas carimbo de aprovação.
Construa o Loop. Continue Sendo o Engenheiro.
Duas pessoas podem construir o mesmo loop e obter resultados opostos. Uma usa o loop para acelerar um trabalho que entende profundamente. A outra usa o loop para parar de entender o trabalho. O loop não sabe a diferença. Você sabe.
Loop Engineering não torna o trabalho mais fácil. Ele desloca a alavanca. O valor sai do prompt isolado e vai para a arquitetura do sistema. Sai da digitação e vai para julgamento, revisão, escopo, memória, verificação e segurança. Os fundamentos serão mais importantes do que nunca.
Então comece pequeno. Pegue amanhã uma tarefa maçante que você ainda faz manualmente: triagem de CI, issues paradas, testes instáveis, revisão de PRs simples, atualização de dependências ou limpeza de backlog. Envolva essa tarefa em um loop limitado. Dê estado, skill, conector, worktree, verificador e freios.
Pequeno o suficiente para você ler cada diff. Útil o suficiente para economizar tempo toda semana.
Ninguém começa confiando em 100 agentes. Você começa com um loop que entende, mede, revisa e melhora. Esse é o loop que vale construir.
Se quiser pular toda a etapa chata do hype e ir direto para a prática do que realmente importa, conheça a Formação AI Software Engineer 4.0.
Equipe DSA
Referências:
E-book Claude Code – O Guia Prático Completo