TL;DR
· Em junho de 2026, vários praticantes de programação com IA propuseram quase simultaneamente a Engenharia de Loop, e o Stripe já usa Minions para mesclar mais de 1300 PRs gerados por IA por semana.
· Esse método não depende mais de prompts humanos sequenciais, mas permite que o sistema descubra tarefas automaticamente, faça handoffs, valide, salve o estado e avance para a próxima rodada.
· A confiabilidade ainda depende de avaliadores independentes, portões rígidos e revisão humana; dívida de validação e declínio na compreensão podem amplificar os riscos ao contrário.

Recentemente, um engenheiro da Anthropic publicou um material de 11 páginas sobre "Engenharia de Ciclo para Sistemas de Agentes", colocando a Engenharia de Loop após a Engenharia de Prompt, Engenharia de Contexto e Engenharia de Harness, como um método chave para a programação com IA entrar no próximo estágio.

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

Esse número é importante não porque a IA escreveu mais algumas linhas de código, mas porque o foco do desenvolvimento de software está mudando de "humanos dizem ao modelo o que escrever" para "humanos projetam um sistema que se alinha, pega tarefas, escreve código, verifica resultados, salva estado e continua a operar".

No ano passado, a narrativa das ferramentas de programação com IA girava principalmente em torno da capacidade do modelo: conclusão de código mais precisa, janela de contexto mais longa, agentes capazes de concluir tarefas mais complexas de uma só vez. Mas a Engenharia de Loop discute outra coisa: quando a própria geração de código se torna mais barata, o que os engenheiros realmente precisam projetar é um ciclo que funcione de forma sustentável. A máquina pode produzir continuamente candidatos, e os humanos decidem quais resultados são confiáveis, quais devem ser bloqueados e quais custos de longo prazo estão sendo escondidos.

Recentemente, um engenheiro da Anthropic publicou um material de 11 páginas sobre "Engenharia de Ciclo para Sistemas de Agentes", colocando a Engenharia de Loop após a Engenharia de Prompt, Engenharia de Contexto e Engenharia de Harness, como um método chave para a programação com IA entrar no próximo estágio. Este artigo usa esse material como ponto de partida, combinando discussões públicas de Boris Cherny, Addy Osmani e outros, além do caso do Stripe Minions mesclando mais de 1300 PRs gerados por IA por semana, para explicar o que é a Engenharia de Loop, por que de repente ganhou atenção online, e como ela realmente muda não a escrita de código, mas a validação, o agendamento e o julgamento no desenvolvimento de software.

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

A Engenharia de Loop é colocada após a Engenharia de Prompt, Engenharia de Contexto e Engenharia de Harness, como a quarta camada da pilha 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 conectar uma execução única do modelo a ferramentas, testes e fluxos de trabalho". A Engenharia de Loop vai um passo além: 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 rodada.

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

A primeira é descobrir trabalho, como escanear falhas de CI, issues abertas, commits de código ou tarefas pendentes; a segunda é o handoff de tarefas, organizando as tarefas em um contexto que o modelo possa processar; a terceira é a validação independente, verificando se o código produzido pelo modelo realmente funciona, passa nos testes e não introduz efeitos colaterais; a quarta é a persistência de resultados, escrevendo estado, julgamentos e itens não concluídos em arquivos ou sistemas; a quinta é o agendamento de ciclo, permitindo que a próxima rodada continue em um momento adequado.

O mais crucial aqui não é "geração", mas "validação". Se um ciclo apenas faz o modelo escrever código repetidamente e depois elogiar seus próprios resultados, ele pode facilmente se tornar um "ciclo de concordância": cada rodada parece avançar, mas na verdade apenas empacota erros de forma mais completa.

O ciclo matinal de triagem do próprio Osmani é um exemplo pessoal: o sistema lê automaticamente todos os dias as falhas de teste do dia anterior, issues abertas e commits recentes, gera um arquivo de estado e coloca itens não tratáveis na caixa de entrada manual. Seu valor não é tomar todas as decisões pelo engenheiro, mas fazer uma triagem antes de o engenheiro acordar, deixando a atenção para as partes que realmente precisam de julgamento.

Os 1300 PRs do Stripe: confiabilidade vem das restrições, não do modelo

O pipeline Minions do Stripe é o caso empresarial mais impactante desta 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 por linha por humanos.

Mas isso não significa que o Stripe entrega seu sistema de produção a um grande modelo para agir livremente. Pelo contrário, o segredo dos Minions está em um processo altamente controlado: um orquestrador determinístico primeiro monta o contexto, extraindo informações de tarefas do Jira, busca de código e ferramentas internas; o LLM gera o código; depois, linters codificados, portões de envio e revisão humana final determinam se pode ser mesclado.

Em outras palavras, a confiabilidade não vem de "o modelo de repente ficou inteligente o suficiente", mas de uma série de restrições. O modelo propõe alterações candidatas, o sistema limita o que ele pode tocar e quais verificações deve passar, e os humanos decidem se entra no branch principal.

Esta é também a diferença entre a Engenharia de Loop e scripts comuns de programação com IA. Scripts comuns geralmente focam em "fazer o modelo completar a tarefa"; sistemas de ciclo devem 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 essas restrições, 1300 PRs por semana não são um salto de eficiência, mas possivelmente uma máquina de dívida técnica.

Gerador e avaliador devem ser separados

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

O gerador é responsável por escrever código, modificar arquivos e enviar resultados candidatos. O avaliador é responsável por encontrar erros e, de preferência, assumir por padrão que o código tem problemas. Ambos não podem ser realizados pelo mesmo "agente otimista", porque o modelo tende a aprovar sua própria saída ao se autoavaliar, 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. Ele não precisa resolver problemas criativamente, apenas verificar se a página abre, se os testes passam, se as condições de contorno não são quebradas e se o código segue regras estabelecidas. Algumas práticas fazem o avaliador usar ferramentas de automação de navegador para clicar na página, em vez de apenas ler o código e dar um palpite.

Isso explica por que a "validação" é a parte mais difícil do ciclo de cinco etapas. A geração de código está cada vez mais barata, mas provar que um código está realmente correto ainda é caro. Especialmente em grandes bases de código, erros podem não aparecer imediatamente, e os testes podem não cobrir caminhos reais de negócios. Quanto mais rápido o ciclo roda, mais rápido as suposições não validadas se acumulam.

Custos ocultos se reforçam mutuamente

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

O primeiro tipo de custo é a dívida de validação. Erros não cobertos por testes se acumulam continuamente no ciclo até explodirem em uma mesclagem ou implantação. O segundo tipo é o declínio na compreensão. A base de código cresce continuamente, mas os engenheiros não vivenciaram pessoalmente as decisões de design críticas, e seu mapa mental fica em versões antigas. O terceiro tipo é a rendição cognitiva. Humanos começam a aceitar a saída da máquina por padrão, fazendo apenas aprovações formais. O quarto tipo é a explosão no consumo de tokens. Tentativas repetidas, subagentes, contexto longo e validação em várias rodadas fazem a conta subir rapidamente.

Esses quatro custos se alimentam mutuamente: testes insuficientes levam a dívida de validação, dívida de validação torna os engenheiros menos dispostos a entender profundamente, diminuição da compreensão transforma a revisão humana em carimbo de borracha, e revisões de carimbo de borracha impulsionam mais repetições automáticas e custos mais altos.

Portanto, o mesmo conjunto de componentes de ciclo pode produzir resultados completamente opostos nas mãos de engenheiros diferentes. Aqueles com bom julgamento e limites claros podem usar o ciclo para ampliar sua compreensão do sistema, tratando a máquina como uma camada de execução incansável; aqueles com julgamento fraco ou excessiva dependência da automação podem, após alguns meses, se tornar "porteiros" de seus próprios sistemas, apenas aprovando ou rejeitando, sem conseguir explicar por que o sistema funciona dessa forma.

Com o código mais barato, o caro é o julgamento

A Engenharia de Loop empurra uma tendência de longo prazo para uma posição mais clara: código, planos, PRs e decomposição de tarefas estão se aproximando de gratuitos, mas "o que é realmente correto" não ficou mais barato.

Para as empresas, isso significa que o foco do investimento em programação com IA pode mudar 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 ocorrerem anomalias. A capacidade do modelo ainda é importante, mas é apenas uma parte do sistema.

Para os engenheiros, o papel também está mudando. Antes, o trabalho principal era escrever código; agora, cada vez mais, o trabalho se torna revisar as respostas candidatas produzidas pela máquina: se atendem aos requisitos, se quebram a arquitetura, se são apenas aparentemente razoáveis, se transferem complexidade para futuros mantenedores.

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

A verdadeira bifurcação está em se os humanos ainda mantêm poder de julgamento e veto suficientes. A IA pode enviar PRs continuamente, mas se eles podem ser mesclados, se devem entrar em produção e se vão prejudicar o sistema a longo prazo, ainda depende das pessoas.

Clique para saber mais sobre as vagas da BlockBeats

Bem-vindo ao grupo oficial da BlockBeats:

Grupo de assinatura no Telegram: https://t.me/theblockbeats

Grupo de discussão no Telegram: https://t.me/BlockBeats_App

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