Os agentes substituem o revisor, não a revisão

Em junho de 2026, Martin Monperrus, pesquisador de engenharia de software conhecido pelo reparo automático de programas, publicou um artigo intitulado The End of Code Review: Coding Agents Supersede Human Inspection. O argumento é que os coding agents cruzaram um limiar de capacidade no qual ter um humano examinando um diff antes do merge deixou de ser um portão de qualidade necessário, e que a configuração comum em que agentes escrevem código e humanos permanecem como os revisores obrigatórios é um beco sem saída.¹

O artigo está certo em mais coisas do que seus críticos vão admitir, e errado em um ponto específico que importa. Os agentes substituíram o revisor: o humano que lê um diff linha por linha em busca de defeitos está fazendo um trabalho que um conjunto de agentes hoje faz melhor e em cada commit. Mas o artigo confunde esse papel com a revisão em si. Quando você de fato roda o pipeline de agentes que ele prescreve, o trabalho humano não desaparece. Ele se realoca, de inspecionar o código para ser dono da intenção que o código deveria satisfazer. Eu rodo esse pipeline. O revisor está morrendo. A revisão está subindo na pilha.

Quero levar o artigo a sério, porque a maioria das respostas a ele não vai levar. A réplica reflexiva é “mas os agentes alucinam”, e Monperrus já concede isso. O engajamento honesto começa concedendo o que ele acerta.

Resumo

• Monperrus argumenta que os coding agents acabaram com a necessidade de revisão de código humana, porque todo objetivo da revisão (detecção de defeitos, estilo, segurança, transferência de conhecimento) é atendido de forma melhor e mais barata por agentes, e a capacidade de revisão humana não consegue escalar com a vazão impulsionada por agentes.¹
• Ele está correto ao dizer que a caixinha de aprovação humana obrigatória acabou, e correto ao dizer que os agentes fazem a inspeção sistemática melhor do que um humano cansado passando os olhos por um diff grande.
• Ele não é ingênuo quanto a isso: o artigo reconhece a alucinação, a injeção de prompt, a correlação de pontos cegos de segurança, e reserva os humanos para mudanças de alto risco, inéditas, reguladas e éticas.¹
• A lacuna é que ele trata o papel humano residual como um pequeno conjunto de escalonamentos. Em produção ele é o centro de sustentação: o agente otimiza para a especificação que recebeu, e escrever e ser dono dessa especificação é o ato irredutivelmente humano.
• O papel do revisor está sendo automatizado. A revisão, entendida como o julgamento sobre se o software está correto para o seu propósito, está se realocando para onde o agente não consegue seguir.

O que o artigo acerta

Monperrus parte da enumeração de Bacchelli e Bird sobre por que as equipes revisam código: detecção de defeitos, imposição de estilo e padrões, transferência de conhecimento e consciência da equipe, com a segurança como uma quinta dimensão.¹² Sua jogada é pegar cada objetivo e argumentar que um agente o atende melhor. Os agentes inspecionam cada commit sem fadiga ou atraso de fuso horário. Eles enumeram classes de vulnerabilidades de forma mais sistemática do que um humano fazendo uma passada improvisada. Eles geram resumos arquiteturais e documentação atualizada no momento do merge. O artigo mobiliza a curva de capacidade do SWE-bench para sustentar o argumento do limiar, do melhor modelo resolvendo menos de 2 por cento dos issues reais do GitHub quando o benchmark foi lançado em 2023 até os principais agentes ultrapassarem 70 por cento no final de 2025.¹³

Não tenho nenhuma objeção a essa parte, porque a vejo funcionar diariamente. Meu loop autônomo de build roda um portão de três revisores: agentes separados verificam correção, convenções e segurança antes de o código entrar no merge, e um segundo loop envia a implementação para um modelo independente para uma passada adversarial. Esses agentes pegam defeitos reais, e os pegam em cada mudança, não nas mudanças para as quais um humano teve tempo. Os dois posts que antecederam este aqui neste site cada um passou por um avaliador agente que os pontuou contra uma rubrica e sinalizou problemas factuais específicos que eu então tive que corrigir. A afirmação do artigo de que os agentes produzem uma saída de revisão acionável e estruturada comparável à de um revisor treinado não é especulativa para mim. É a minha terça-feira.

O argumento da vazão também está correto, e é a parte que as pessoas subestimam. Um desenvolvedor assistido por agentes produz mais pull requests por dia do que a capacidade de revisão humana consegue absorver. Quando quem escreve é rápido e o revisor é um humano, a fila de revisão se torna a restrição limitante, e a revisão degenera em uma formalidade realizada sob pressão de tempo.¹ Monperrus está certo ao dizer que o arranjo ingênuo, agentes escrevem e um humano carimba, não oferece garantia real. Um humano que aprova porque o código parece correto e os testes passam não está revisando. Está assinando.

O pipeline que ele descreve é o que eu rodo

O que o artigo propõe para substituir a revisão humana não é “confie em um modelo”. É um pipeline de verificação com agente no loop: múltiplos agentes independentes, idealmente modelos diferentes, produzindo um sign-off calibrado e estruturado (cobertura de testes, varreduras de segurança, rastros de raciocínio em JSON ou SARIF, o formato de intercâmbio padrão para resultados de análise estática) em vez de threads informais de comentários, com agentes instruídos a se abster quando incertos e humanos reservados para os casos difíceis.¹

Ou seja, com nomes diferentes, é a arquitetura que venho construindo e sobre a qual venho escrevendo há um ano. Eu argumentei que os pull requests de agentes precisam de superfícies de revisão menores, que a revisão automatizada precisa de dissidência em vez de um único juiz confiante, e que os pacotes de revisão de evidência estruturada estão substituindo o comentário informal no diff. Então eu não estou argumentando contra o pipeline. Eu ajudei a defendê-lo. Estou argumentando sobre o que sobra para o humano uma vez que o pipeline existe, porque eu vivi dentro da resposta, e ela não é a resposta que o artigo dá.

Onde o argumento se quebra: a revisão nunca foi só inspeção

Monperrus reserva o humano para mudanças de alto risco, arquitetura inédita, caminhos de código regulados e julgamento ético, e ele enquadra isso como escalonamento: exceções roteadas para uma pessoa quando os agentes as sinalizam.¹ O enquadramento faz o papel humano soar como uma interrupção rara em uma linha que de resto é automatizada.

Rodar a linha ensina o oposto. O agente não gera o seu próprio propósito. Ele otimiza para a especificação que lhe é entregue, e em cada mudança que importa, alguém tem que decidir o que correto significa antes que os agentes possam verificar qualquer coisa contra isso. O próprio artigo admite a fronteira em sua seção de discussão: os agentes otimizam para métricas técnicas de qualidade e não estão confiavelmente equipados para perceber que uma mudança de telemetria viola a expectativa razoável de privacidade de um usuário, ou que um ajuste de ranqueamento amplifica viés.¹ Isso é apresentado como uma limitação nas bordas. Não é nas bordas. A pergunta “esta mudança está correta para o que de fato queremos” está no centro de cada merge não trivial, e é exatamente a pergunta que um agente calibrado para uma especificação não consegue fazer sobre a especificação.

Eu senti isso concretamente nos dois posts que publiquei antes deste. O revisor agente os pontuou e pegou um exagero factual em cada um: uma afirmação institucional não verificada em um, uma estatística mal atribuída no outro. A pegada foi do agente. A correção não foi. Decidir como corrigir um exagero de forma verdadeira, qual fonte de fato sustentava a afirmação, qual era a versão honesta da frase, exigiu julgamento sobre a intenção que a rubrica conseguia sinalizar, mas não resolver. O agente descobriu que algo estava errado. Um humano decidiu como era o certo. Essa divisão de trabalho é a realocação, e ela aconteceu em conteúdo rotineiro, não em um caso de borda regulado.

Então o humano não sai do loop. O humano se move do fim dele para o começo. A revisão costumava ser o último ponto de controle, uma pessoa inspecionando código pronto. Em um pipeline de agentes a inspeção é automatizada e o trabalho humano irredutível se move para a frente: especificar a intenção com precisão suficiente para que os agentes tenham algo verdadeiro contra o qual verificar, e ser dono das consequências quando o resultado entregue atende à especificação mas erra o ponto. A responsabilização não pode ser delegada a um sistema que otimiza para métricas, porque a responsabilização é a disposição de estar errado de propósito e responder por isso.

A versão honesta da afirmação

Tire a provocação do título e a afirmação defensável é mais estreita do que “o fim da revisão de código”. A afirmação defensável é o fim do humano como inspetor de diff e como caixinha de aprovação obrigatória. Esse papel está genuinamente acabado, e fingir o contrário para proteger um ritual confortável é a sua própria desonestidade. As equipes que mantêm um humano na cadeira de inspeção como teatro, aprovando código de agentes que não conseguem de fato escrutinar, já perderam a garantia que pensam ter.

Mas “revisão de código” sempre foi uma palavra-proxy. Ela nomeava um ponto de controle e significava um julgamento: esta mudança faz o que precisamos, com segurança, de um jeito que possamos sustentar. Automatize o ponto de controle e o julgamento não evapora. Ele se realoca para a especificação de intenção na entrada e a responsabilização na saída, e em uma equipe movendo-se na velocidade dos agentes ele se torna mais importante, não menos, porque os agentes vão fielmente e rapidamente construir o que a especificação disser, inclusive a coisa errada. Quanto mais rápido quem escreve, mais o gargalo passa a ser saber o que pedir. Monperrus está certo ao dizer que o revisor está sendo substituído. Ele está errado ao dizer que a revisão está acabando. Ela está se mudando para a única cadeira que o agente não consegue ocupar.

Principais conclusões

Para líderes de engenharia: - Pare de alocar revisão humana como inspeção de diff. Os agentes fazem isso melhor e continuamente; uma caixinha de aprovação humana em código de agente é teatro de garantia. - Realoque essa capacidade humana para a especificação de intenção e a responsabilização, as partes da revisão que determinam se correto-para-a-especificação é correto-de-fato.

Para quem constrói ferramentas de desenvolvedor: - Construa o pipeline de revisão em conjunto que o artigo descreve: múltiplos modelos, abstenção calibrada, sign-off estruturado. A dissidência entre revisores é o sinal. - Projete a frente do pipeline, não apenas o portão. A superfície de maior valor é onde um humano transforma a intenção em uma especificação contra a qual os agentes possam verificar.

Para engenheiros: - Sua habilidade de revisão não está se tornando inútil; ela está mudando de endereço. O valor migra de farejar o bug no diff para definir o que o código deveria fazer e ser dono do resultado.

Perguntas frequentes

Este artigo significa que a revisão de código humana acabou?

O humano como inspetor de diff linha por linha e aprovador obrigatório acabou, que é o ponto mais forte do artigo: os agentes fazem a inspeção sistemática melhor e em cada commit. O que não acaba é o julgamento do qual a revisão de código era um proxy, ou seja, se uma mudança está correta para o seu propósito real. Esse julgamento se realoca para a especificação da intenção e para ser dono das consequências em vez de desaparecer.

O que Monperrus de fato argumenta?

Que os coding agents agora atendem a todo objetivo declarado da revisão de código (detecção de defeitos, estilo, transferência de conhecimento, segurança) a um custo mais baixo e com maior vazão, e que manter humanos como os revisores obrigatórios de código escrito por agentes é um beco sem saída porque não dá garantia real e não consegue escalar. Ele propõe um conjunto de agentes produzindo um sign-off estruturado, com humanos reservados para casos de alto risco e éticos. É um position paper, não um estudo empírico.¹

Onde o argumento é mais fraco?

Em tratar o papel humano residual como um escalonamento raro. Na prática, o papel humano é de sustentação em cada mudança não trivial, porque o agente otimiza para uma especificação que não consegue autorar nem questionar. Definir a especificação e responder pelo resultado é trabalho central, não um caso de borda.

As equipes devem manter uma etapa de aprovação humana nos pull requests de agentes?

Não como teatro de inspeção. Se o humano não consegue genuinamente escrutinar a mudança, a aprovação é uma assinatura, não uma revisão. Melhor investir o esforço humano a montante, especificando a intenção com precisão, e a jusante, sendo dono do resultado entregue, deixando que um conjunto de agentes faça a inspeção.

Fontes

• Martin Monperrus, “The End of Code Review: Coding Agents Supersede Human Inspection,” arXiv, 11 de junho de 2026: arxiv.org/abs/2606.13175. Um position paper sintetizando evidências de capacidade existentes; ele enumera os objetivos da revisão de código a partir de Bacchelli e Bird, cita a curva de capacidade do SWE-bench e discute limitações, incluindo alucinação, injeção de prompt e responsabilização ética.
• Alberto Bacchelli e Christian Bird, “Expectations, Outcomes, and Challenges of Modern Code Review,” ICSE 2013, a fonte empírica para a taxonomia dos objetivos de revisão sobre a qual o artigo se constrói: Microsoft Research
• Carlos E. Jimenez et al., “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?,” ICLR 2024, o benchmark por trás da curva de capacidade (o melhor modelo resolveu 1,96% no lançamento): arxiv.org/abs/2310.06770
• Textos relacionados sobre revisão por agentes a partir da experiência em produção: superfícies de revisão menores, a revisão precisa de dissidência, pacotes de revisão e o loop autônomo de build cujo portão de três revisores é o pipeline que este post descreve rodar.