TL;DR
· Em junho de 2026, vários praticantes de programação com IA propuseram quase simultaneamente a Engenharia de Loop, e a Stripe já usa Minions para mesclar mais de 1300 PRs gerados por IA por semana.
· Este método já não depende de prompts humanos sequenciais; em vez disso, o sistema descobre tarefas, faz transições, valida, guarda estado e passa para a próxima ronda automaticamente.
· A fiabilidade continua a depender de avaliadores independentes, controlos rígidos e revisão humana; a dívida de validação e o declínio da compreensão podem reverter o risco.

Recentemente, um engenheiro da Anthropic publicou um documento de 11 páginas sobre "Engenharia de Loop para Sistemas de Agentes", colocando a Engenharia de Loop depois da Engenharia de Prompt, Engenharia de Contexto e Engenharia de Harness, considerando-a um método-chave para a próxima fase da programação com IA.

Este documento chamou a atenção porque coincide com o ponto de viragem nas discussões sobre programação com IA em junho de 2026. Addy Osmani, Boris Cherny e Peter Steinberger chamaram quase na mesma semana a nova fase da programação com IA de Engenharia de Loop, e o pipeline Minions da Stripe já usa uma abordagem semelhante para mesclar mais de 1300 Pull Requests gerados por IA por semana.

Este número é importante não porque a IA escreveu mais algumas linhas de código, mas porque o foco do desenvolvimento de software está a mudar de "os humanos dizem ao modelo o que escrever" para "os humanos concebem um sistema que organiza filas, obtém tarefas, escreve código, verifica resultados, guarda estado e continua a funcionar".

No último ano, a narrativa das ferramentas de programação com IA girou principalmente em torno das capacidades dos modelos: autocompletar código mais preciso, janelas de contexto mais longas, agentes capazes de completar tarefas mais complexas de uma só vez. Mas a Engenharia de Loop discute outra coisa: quando gerar código se torna cada vez mais barato, o que os engenheiros realmente precisam de conceber é um ciclo sustentável. As máquinas podem produzir candidatos continuamente, e os humanos decidem quais resultados são fiáveis, quais devem ser bloqueados e quais custos a longo prazo estão a ser escondidos.

Recentemente, um engenheiro da Anthropic publicou um documento de 11 páginas sobre "Engenharia de Loop para Sistemas de Agentes", colocando a Engenharia de Loop depois da Engenharia de Prompt, Engenharia de Contexto e Engenharia de Harness, considerando-a um método-chave para a próxima fase da programação com IA. Este artigo usa este documento como ponto de partida, combinando discussões públicas de Boris Cherny, Addy Osmani e outros, bem como o caso da Stripe Minions a mesclar mais de 1300 PRs gerados por IA por semana, para explicar o que é realmente a Engenharia de Loop, porque foi subitamente discutida em toda a rede, e como a verdadeira mudança não é escrever código, mas sim a validação, agendamento e julgamento no desenvolvimento de software.

Programação com IA: de "um prompt" para "ciclo contínuo"

A Engenharia de Loop é colocada depois da Engenharia de Prompt, Engenharia de Contexto e Engenharia de Harness, como a quarta camada da stack de engenharia de IA.

A Engenharia de Prompt resolve "como perguntar"; a Engenharia de Contexto resolve "o que mostrar ao modelo"; a Engenharia de Harness resolve "como ligar uma execução do modelo a ferramentas, testes e fluxos de trabalho". A Engenharia de Loop dá um passo em frente: o sistema não executa apenas uma tarefa, mas pode reiniciar em intervalos fixos ou sob condições de gatilho, usando o resultado anterior como entrada para a próxima ronda.

Um ciclo completo geralmente contém cinco ações.

O primeiro passo é descobrir trabalho, por exemplo, verificar falhas de CI, Issues abertas, submissões de código ou tarefas pendentes; o segundo passo é a transição de tarefas, organizando-as num contexto que o modelo possa processar; o terceiro passo é a validação independente, verificando se o código produzido pelo modelo realmente funciona, passa nos testes e não introduz efeitos colaterais; o quarto passo é a persistência de resultados, escrevendo o estado, julgamentos e itens não concluídos num ficheiro ou sistema; o quinto passo é o agendamento do ciclo, para que a próxima ronda continue no momento adequado.

O mais crítico aqui não é a "geração", mas a "validação". Se um ciclo apenas faz o modelo escrever código repetidamente e depois elogiar os seus próprios resultados, facilmente se torna um "ciclo de aprovação": cada ronda parece avançar, mas na verdade apenas empacota erros de forma mais completa.

O ciclo de triagem matinal de Osmani é um exemplo pessoal: o sistema lê automaticamente as falhas de CI do dia anterior, Issues abertas e submissões recentes, gera um ficheiro de estado e coloca itens não tratáveis na caixa de entrada manual. O seu valor não é tomar todas as decisões pelo engenheiro, mas sim fazer uma triagem inicial antes de o engenheiro acordar, deixando a atenção para as partes que realmente precisam de julgamento.

Os 1300 PRs da Stripe: fiabilidade vem de restrições, não do modelo

O pipeline Minions da Stripe é o caso empresarial mais impactante nesta discussão: mais de 1300 Pull Requests gerados por IA são mesclados por semana, e o código em si não é escrito linha a linha por humanos.

Mas isto não significa que a Stripe tenha entregado o sistema de produção a um grande modelo para agir livremente. Pelo contrário, o segredo do Minions está num processo altamente controlado: um orquestrador determinístico monta primeiro o contexto, extraindo informações de tarefas do Jira, pesquisa de código e ferramentas internas; o LLM gera o código; depois, através de linters codificados, controlos de submissão e revisão humana final, decide-se se pode ser mesclado.

Por outras palavras, a fiabilidade não vem de "o modelo ser subitamente inteligente o suficiente", mas de uma série de restrições. O modelo propõe alterações candidatas, o sistema limita o que pode tocar e que verificações deve passar, e o humano decide se entra no tronco principal.

Esta é também a diferença entre a Engenharia de Loop e os scripts de programação com IA comuns. Os scripts comuns focam-se frequentemente em "fazer o modelo completar a tarefa"; os sistemas de ciclo têm de considerar de onde vêm as tarefas, como lidar com falhas, como preservar o estado, como controlar o orçamento e quem impede que erros entrem em produção.

Sem estas restrições, 1300 PRs por semana não são um salto de eficiência, mas sim uma máquina de criar dívida técnica.

Gerador e avaliador devem ser separados

Um design central da Engenharia de Loop é separar o gerador do avaliador.

O gerador escreve código, modifica ficheiros e submete resultados candidatos. O avaliador deteta erros, e o melhor é assumir por defeito que o código tem problemas. Ambos não podem ser feitos pelo mesmo "agente otimista", porque o modelo tende a aprovar a sua própria produção na autoavaliação, especialmente quando a descrição da tarefa é vaga, a cobertura de testes é insuficiente ou o contexto está incompleto.

Um avaliador independente pode ser mais simples, mais cético e mais fácil de ajustar. Não precisa de resolver problemas criativamente; apenas precisa de verificar se a página abre, se os testes passam, se as condições de fronteira estão quebradas, se o código cumpre as regras estabelecidas. Algumas práticas fazem o avaliador clicar efetivamente na página através de ferramentas de automação de browser, em vez de apenas ler o código e dar um julgamento.

Isto explica porque a "validação" é o passo mais difícil dos cinco. A geração de código tornou-se cada vez mais barata, mas provar que um pedaço de código está realmente correto continua caro. Especialmente em bases de código grandes, os erros podem não se manifestar imediatamente, e os testes podem não cobrir caminhos de negócio reais. Quanto mais rápido o ciclo corre, mais rapidamente se acumulam suposições não validadas.

Os custos ocultos reforçam-se mutuamente

O risco da Engenharia de Loop não é se vai escrever código errado, mas sim que pode tornar mais difícil para a equipa perceber que perdeu a compreensão.

O primeiro tipo de custo é a dívida de validação. Erros não cobertos por testes acumulam-se continuamente no ciclo, até explodirem numa mesclagem ou lançamento. O segundo tipo é o declínio da compreensão. A base de código cresce, mas os engenheiros não viveram as decisões de design chave manualmente, e o mapa mental fica numa versão antiga. O terceiro tipo é a rendição cognitiva. Os humanos começam a aceitar por defeito a saída da máquina, apenas dando aprovação formal. O quarto tipo é a explosão de consumo de tokens. Retentativas, subagentes, contexto longo e validação em várias rondas aumentam rapidamente a fatura.

Estes quatro custos alimentam-se mutuamente: testes insuficientes levam a dívida de validação, o aumento da dívida de validação faz com que os engenheiros se aprofundem menos, a compreensão diminuída transforma a revisão humana num carimbo de borracha, e a revisão de carimbo impulsiona mais retentativas automáticas e custos mais altos.

Portanto, os mesmos componentes de ciclo podem produzir resultados completamente opostos nas mãos de diferentes engenheiros. Pessoas com bom julgamento e limites claros podem usar o ciclo para amplificar a sua compreensão do sistema, tratando a máquina como uma camada de execução incansável; pessoas com julgamento fraco ou excessivamente dependentes da automação podem, após alguns meses, tornar-se apenas "guardiões" do seu sistema, capazes de aprovar ou rejeitar, mas incapazes de explicar por que o sistema funciona assim.

O código fica mais barato, o caro é o julgamento

A Engenharia de Loop coloca uma tendência de longo prazo numa posição mais clara: código, planos, PRs e decomposição de tarefas estão a tornar-se quase gratuitos, mas "o que é realmente correto" não fica mais barato.

Para as empresas, isto significa que o foco do investimento em programação com IA pode passar da compra de modelos mais fortes para o design de processos mais estáveis: limites de tarefas, montagem de contexto, avaliação independente, persistência de estado, limite de orçamento, pontos de revisão humana e como parar o ciclo quando ocorre uma anomalia. A capacidade do modelo ainda é importante, mas é apenas parte do sistema.

Para os engenheiros, o papel também está a mudar. O trabalho central costumava ser escrever código, agora cada vez mais trabalho torna-se revisar as respostas candidatas produzidas pela máquina: se satisfazem os requisitos, se quebram a arquitetura, se parecem apenas razoáveis, se transferem complexidade para futuros mantenedores.

Isto não significa que os programadores já foram substituídos. Pelo contrário, a Engenharia de Loop é mais como um amplificador de julgamento. Pode permitir que um engenheiro produza mudanças que antes exigiam uma pequena equipa, e também pode amplificar a preguiça, a fé cega e a falta de validação em acidentes de produção.

A verdadeira bifurcação é se os humanos ainda retêm julgamento e poder de veto suficientemente fortes. A IA pode submeter PRs continuamente, mas se podem ser mesclados, se devem ser lançados, e se vão arrastar o sistema a longo prazo, ainda depende dos humanos.

Clique para saber as vagas abertas na BlockBeats

Bem-vindo a juntar-se à comunidade oficial da BlockBeats:

Grupo de subscrição Telegram: https://t.me/theblockbeats

Grupo de conversa Telegram: https://t.me/BlockBeats_App

Conta oficial Twitter: https://twitter.com/BlockBeatsAsia