Enquanto eu escrevia este texto, percebi uma ironia. Tem uma rotina rodando no meu lado toda segunda de manhã. Ela vasculha fontes da semana, cruza com os pilares da minha tese, monta um digest e me entrega um rascunho de artigo para eu aprovar. Eu não fico promptando nada. Eu desenhei o sistema que faz isso e reviso o que ele me traz.
Aí esbarrei num repositório do Cobus Greyling sobre uma ideia que tem nome agora: loop engineering. E a definição que ele usa me parou. Loop engineering é deixar de ser a pessoa que prompta o agente. Você projeta o sistema que faz isso no seu lugar.
Era exatamente o que eu já estava fazendo sem o nome. E acho que é a próxima dobra natural de quase tudo que venho escrevendo aqui.
De promptar para projetar
Tem duas citações no repositório que dizem a coisa toda. Peter Steinberger: você não deveria mais estar promptando agentes de código, você deveria estar projetando loops que promptam os seus agentes. E o Boris Cherny, que lidera o Claude Code na Anthropic, foi mais longe: ele diz que não prompta mais o Claude, tem loops rodando que promptam o Claude e decidem o que fazer, e que o trabalho dele agora é escrever loops.
Leia de novo a última parte. O trabalho dele virou escrever loops.
Um loop, do jeito que o material define, é um objetivo recursivo. Você define um propósito e a IA itera, muitas vezes com sub-agentes, verificação e estado externo, até cumprir o objetivo ou decidir devolver para você. Não é um prompt melhor. É um sistema que prompta sozinho, observa o resultado e segue.
O ponto de alavanca se mexeu. Saiu de redigir o prompt perfeito e foi parar no desenho do sistema de controle que orquestra o agente ao longo do tempo. É a mesma migração de valor que eu venho chamando de 70/30. Quando a execução comprime, o que sobra de valioso é a intenção, a arquitetura e a validação. Loop engineering é essa migração aplicada ao jeito de operar o agente no dia a dia.
Loop não é harness, mas não vive sem um
Escrevi há algumas semanas que um agente não é só o modelo, é o modelo mais o harness que segura ele quando ganha autonomia. O loop é o passo seguinte dessa ideia. Se o harness é a estrutura que envolve o modelo e o torna governável, o loop é o que coloca esse harness para rodar de forma recorrente, sem você no meio de cada iteração.
O material separa bem as duas coisas, e gosto da distinção. Harness é a infraestrutura que torna o agente confiável numa execução. Loop é a disciplina de fazer essa execução acontecer repetidamente, com começo, verificação e fim. Um sem o outro não entrega. Loop sem harness é um agente solto fazendo besteira em escala. Harness sem loop é um truque pessoal que só funciona quando você está sentado na frente dele.
Os primitivos que compõem um loop, na lista do repositório, são reconhecíveis para quem trabalha com isso. Automação e agendamento para disparar o loop numa cadência. Worktrees para rodar em paralelo sem um pisar no outro. Skills para guardar o conhecimento do projeto. Plugins e conectores, via MCP, para o loop alcançar suas ferramentas de verdade. E sub-agentes para separar quem faz de quem confere. Por cima de tudo, memória e estado, a espinha durável que vive fora de qualquer conversa.
Repare que nenhum desses é "um modelo melhor". São peças de engenharia ao redor do modelo. De novo, o valor está nos 70%.
Comece reportando, suba para assistido, só então solte
A parte que mais me agradou no material é que ele não vende loop autônomo como passe de mágica. Ele propõe um rollout em fases. Primeiro o loop só reporta, na semana um ele não conserta nada, apenas observa e te conta o que viu. Depois passa a sugerir e aplicar correções assistidas. Só então, e em escopo apertado, roda sem supervisão direta.
Isso é, na prática, a mesma régua que descrevi no post das quatro camadas de autonomia. Autonomia se dá proporcional ao risco, não de uma vez. E o repositório tem um detalhe que fecha o raciocínio: um portão humano no meio do fluxo. Quando a ação é segura e está na lista do permitido, o loop comita, abre o PR, executa. Quando é arriscada ou ambígua, ele para e escala para você, com o contexto inteiro na mão.
É a regra de ouro de novo, vinda de outro lugar. Alta criticidade somada a alta autonomia não pode. O loop bem desenhado não é o que faz tudo sozinho. É o que sabe a hora de te chamar.
A conta tem dois lados
Loop engineering amplifica julgamento, o bom e o ruim. Essa frase está nos avisos do próprio material e acho ela honesta. Duas pessoas rodam o mesmo loop e chegam a resultados opostos. O loop não sabe disso. Você sabe.
Tem dois custos que o material nomeia bem. O primeiro é óbvio depois que você leva o susto na fatura: token explode com sub-agentes e loops longos rodando o tempo todo. Loop é poderoso e caro, e tratar custo como métrica de primeira classe não é opcional.
O segundo é mais sutil e me parece o mais perigoso. Eles chamam de comprehension debt, dívida de compreensão. É o buraco que cresce quando o loop entrega mais rápido do que você consegue ler. A verificação continua sendo sua. Loop sem supervisão comete erros sem supervisão. Se você para de ler o que o loop manda, a dívida não aparece num gráfico, ela aparece num incidente.
O Addy Osmani, num dos ensaios que o repositório aponta como canônicos, resume do jeito que eu queria ter escrito. Construa o loop, mas construa como alguém que pretende continuar sendo o engenheiro, não só a pessoa que aperta o play. Guardo isso.
Onde isso encaixa
Loop engineering não é mais uma ferramenta para colocar no radar. É o nome de uma mudança de papel que já estava acontecendo. O desenvolvedor que estava virando arquiteto de intenção agora vira também arquiteto de loops. A TI que eu venho chamando de curadora de capacidades ganha um item concreto no catálogo: loops confiáveis, com harness, portão humano e orçamento, que qualquer time pode clonar e rodar.
A barreira técnica para montar um desses caiu bastante. Os primitivos existem, os padrões estão documentados, dá para começar reportando hoje. O que pesa, de novo, é querência e critério. Saber qual problema vale um loop, onde fica o portão, o que o loop nunca deve fazer sozinho. Isso não é prompt. É projeto.
E é por isso que a ironia do começo não me incomoda. A rotina que rascunha estes artigos é um loop. Ela me reporta, eu reviso, eu aprovo. O dia que ela publicar sozinha sem eu ler, a dívida de compreensão cobra a conta. Então ela não publica. Ela me chama. É assim que um loop bem desenhado deveria funcionar.
Referências
- Cobus Greyling – Loop Engineering (repositório de referência). GitHub. Fonte-âncora deste artigo, lida na íntegra: definição de loop, primitivos, padrões, rollout L1 a L3, portão humano, comprehension debt e as citações de Steinberger, Cherny e Osmani.
- Addy Osmani – Loop Engineering (ensaio). Ensaio canônico apontado pelo repositório acima.
- Cobus Greyling – Loop Engineering (Substack). Ensaio do autor do repositório.
- Cory Hymel – The AI-Native Software Development Lifecycle (modelo V-Bounce). arXiv 2408.03416, 2024. Base do paradigma 70/30.