Agente de revisão de código com IA acha 30% dos problemas
Agentes de IA que revisam código encontram cerca de 30% dos defeitos que revisores humanos apontaram nos mesmos pull requests, no melhor resultado medido. O número vem do ReviewBench, benchmark de 59 tarefas que a LangChain montou a partir do histórico de revisão do próprio código e publicou no blog da empresa. É a única fonte deste levantamento.
O que é o ReviewBench
O ReviewBench é um benchmark criado pela LangChain para medir agentes de revisão de código. Ele tem 59 tarefas e 64 defeitos de referência, extraídos de comentários reais de revisores em pull requests já aprovados no monorepo do LangSmith, o produto de engenharia de agentes da própria empresa.
A LangChain diz que o construiu porque não confiava nos benchmarks existentes: nenhum deles carrega o padrão interno de revisão da casa.
O comentário cru não serviu como gabarito. Muitos são pedidos de detalhe ou perguntas. A empresa passou as revisões por um filtro de modelo para marcar candidatos fracos e depois revisou cada um à mão. Ficou o que apontava um defeito de fato introduzido pela mudança e era específico o bastante para um verificador julgar.
O que sobrou virou tarefa no formato Harbor, que padroniza instrução, ambiente e verificador.
Dois exemplos citados no texto dizem que tipo de erro está em jogo. Um é uma consulta SQL que buscava e apagava um recurso pelo identificador sem checar o inquilino. Para pegar isso, o agente precisa reconhecer uma regra de segurança do projeto e aplicá-la àquele trecho. O outro é a migração de um endpoint que deixou cair um filtro que existia na API anterior, mudando o comportamento. Achar exige comparar as duas implementações.
Nenhum dos dois aparece olhando só as linhas alteradas.
Como o ReviewBench pontua o agente
O agente recebe o contexto congelado do pull request. Um substituto local do GitHub serve os metadados e o diff, então a tarefa não depende do estado real do repositório remoto. O agente pode vasculhar o repositório inteiro e entrega uma lista estruturada de achados, cada um com local, título e explicação.
Um verificador oculto compara essa lista contra os defeitos de referência e usa um modelo como juiz para decidir o que bate.
São duas medidas, e a nota de manchete pesa as duas igual.
| medida | o que conta | o que não conta |
|---|---|---|
| Cobertura | o agente identificou o mesmo problema no mesmo trecho do defeito de referência, com qualquer redação | nada além da lista de referência |
| Precisão | fatia dos achados que o juiz considera correta, inclusive achado fora da referência que o código sustente | achado extra não soma cobertura nem ganha bônus |
| F1 | combina cobertura e precisão com peso igual, e é a nota de manchete |
O benchmark que avalia IA é corrigido por IA. A LangChain não relata teste de concordância entre esse juiz e um revisor humano.
Os 30% e o 0,32 não são o mesmo número
A rodada principal usou o mesmo arcabouço base, o Deep Agents, nas 59 tarefas, com três tentativas por tarefa e sem nenhuma instrução de sistema específica para revisão. A LangChain diz que omitiu essa instrução de propósito, para comparar os modelos sob o mesmo mínimo, e reconhece que isso não mede o melhor desempenho de cada um.
Essa rodada produziu o resultado central. No ReviewBench, as melhores execuções recuperaram cerca de 30% dos defeitos apontados por revisores humanos, e nenhum modelo com arcabouço básico chegou perto da lista completa. Esse 30% é cobertura.
O 0,32 vem de outro lugar. Saiu de uma comparação pareada em 20 tarefas, também com três tentativas, e é um F1. Comparar os dois números lado a lado é erro de leitura.
O texto menciona uma tabela com os modelos lado a lado. Os valores dela não estão no material apurado, e por isso esta matéria não publica nota por modelo.
O prompt rendeu mais que o modelo
Os resultados de Luna e Terra ficaram abaixo do que a LangChain esperava. Olhando as execuções, a empresa descreve uma estratégia mais estreita: os dois se concentravam em poucos achados e paravam. Gastaram menos token e custaram menos, e perderam cobertura, porque boa parte dos alvos exige olhar além das linhas mudadas.
A segunda rodada testou o Luna com esforço de raciocínio alto e um prompt de revisão estruturado. Nas 20 tarefas, essa configuração marcou 0,32, acima das execuções de Kimi K3 e Opus 4.8 com o arcabouço original nas mesmas tarefas.
A configuração ajustada não ganhou ferramenta nova. Continuava podendo ler e buscar no repositório, sem executar código nem rodar comando de shell. Mudou o prompt. A nova instrução mandava o modelo identificar o que o pull request alterou, rastrear como o sistema em volta dependia daquele comportamento, e conferir os achados contra chamadores, testes e implementações relacionadas.
A própria LangChain classifica isso como comparação de arcabouço, não de modelo. A conclusão que ela tira é que a estratégia de revisão pesa: o mesmo modelo que parecia fraco melhorou quando a instrução o obrigou a mapear a mudança antes de responder.
Quem publicou o benchmark também vende a ferramenta
O texto abre dizendo que a LangChain vinha construindo um agente de revisão de código para uso próprio e fecha divulgando o LangSmith, a plataforma da empresa. O benchmark nasceu do código dela, com os revisores dela e o padrão de revisão dela.
A empresa declara esse desenho, e ele responde ao objetivo que ela mesma se deu: um teste amarrado ao critério interno da casa. O efeito colateral é amarrar o resultado a um repositório específico. As tarefas premiam o agente que reconstrói contratos implícitos daquele sistema, e nada no material apurado mostra que a nota se transfere para outra base de código.
Nenhum outro veículo repercutiu o lançamento neste levantamento, e ninguém de fora rodou o ReviewBench até onde a apuração alcança. O que existe é o relato do autor sobre o próprio teste.
O que o material não responde
O texto não traz data de publicação. Não traz a nota de cada modelo, nem cobertura e precisão separadas por modelo. Não diz qual versão de cada modelo entrou, nem o custo por execução. E não informa se o ReviewBench pode ser baixado e rodado por terceiros. Ele cita o formato Harbor, o que ainda não diz se o conjunto está aberto.
A LangChain diz que quer ampliar o benchmark, com mais tarefas para estabilizar o resultado e cobertura maior de restrição de segurança, compatibilidade de API e casos que dependem de contexto fora das linhas alteradas.
O que isso muda para quem decide
Quem está comprando ou construindo agente de revisão de código passa a ter um teto de referência. No melhor caso medido, 30% de cobertura deixa sete em cada dez defeitos substantivos na mão do revisor humano. Na prática o agente encurta a fila do revisor, e o material apurado não sustenta mais que isso.
Duas perguntas passam a caber na conversa com fornecedor. A primeira é qual a cobertura na base de código do comprador, e não na do fornecedor. A segunda é ver cobertura e precisão separadas, porque a precisão só mede a fatia correta do que o agente enviou: quem envia pouco pontua bem nela sem achar quase nada. Foi a estratégia que a LangChain descreveu nos dois modelos que gastaram menos na rodada.
O custo apareceu invertido na medição. Os dois modelos que consumiram menos token foram os que menos acharam, e o ganho veio de mandar o modelo pensar mais, sem ferramenta nova. Quem escolher agente de revisão pelo preço da execução está escolhendo pela variável que andou junto com o pior resultado.
--- Apurado em 1 veículo de 1 país.