O GitHub colocou no ar em 5 de outubro de 2026 o ReviewBench, um benchmark aberto criado para medir a qualidade de agentes de revisão de código baseados em inteligência artificial. O anúncio foi assinado por Michelle Zhou e Alejandro Carderera de Diego no blog da empresa, e o conjunto de dados já está disponível para uso público.
A proposta é oferecer uma forma reproduzível de comparar sistemas que inspecionam pull requests, apontam problemas e ajudam a decidir o que merece atenção antes de o código seguir para produção.
Revisão de código agêntica ganha um medidor próprio
Segundo os autores, revisores de IA diferem bastante entre si. Alguns levantam mais problemas, outros produzem menos ruído, alguns são melhores em falhas críticas e outros se destacam em melhorias menores.
Sem uma medida comum, fica difícil saber o que cada sistema captura, o que deixa passar e quais tradeoffs assume dentro de um fluxo de trabalho. É justamente essa lacuna que o benchmark tenta fechar, com cortes por severidade, categoria e preferências de precisão e recall.
A ideia é permitir que times escolham o revisor mais adequado ao seu contexto, em vez de confiar em impressões soltas.
O que entra no conjunto de dados
Para desenhar a base, o GitHub analisou 103,9 milhões de pull requests da plataforma e caracterizou a distribuição real dessas cargas de revisão. O resultado é um corpus com 219 pull requests vindos de 187 repositórios públicos de código aberto licenciado, cobrindo 19 linguagens.
As distribuições de linguagem e de tamanho de repositório acompanham de perto o panorama geral do GitHub. As demais linguagens, fora as que aparecem destacadas no gráfico do conjunto, somam 51 pull requests.
Houve um ajuste deliberado: o tamanho dos pull requests foi ponderado para o meio e a cauda revisável da distribuição, reduzindo o peso desproporcional de mudanças minúsculas de arquivo único e preservando casos com múltiplos arquivos, onde a qualidade da revisão importa mais. A concentração não aparece como risco relevante: o maior repositório responde por apenas 4,6% do total, o máximo de pull requests de um único repositório é 10, e a média é de 1,17 PR por repositório.
A distribuição de linguagens foi inferida a partir de títulos e descrições para fins de análise de cobertura, e não como rótulo humano formal.
Como a verdade de referência é construída
O ponto de partida é o reconhecimento de que nenhum revisor isolado, humano ou modelo, consegue enxergar tudo o que vale a pena encontrar em um pull request. Por isso, o ReviewBench monta seu conjunto dourado em três etapas.
Na primeira, reúne achados candidatos de fontes diversas: revisores humanos reais, problemas inferidos a partir de commits de acompanhamento feitos pelos próprios autores, ferramentas de análise determinística e vários LLMs de fronteira, de diferentes famílias de modelos. Na sequência, faz uma deduplicação semântica, unindo achados que apontam para o mesmo problema subjacente.
A cadeia de confiabilidade é auditável de ponta a ponta. Há uma rubrica publicada, um único padrão explícito aplicado a todos os achados, um conjunto de desenvolvimento rotulado por engenheiros sêniores e um avaliador calibrado para ficar alinhado ao julgamento humano.
A mesma régua é usada em todas as fontes, e a auditoria de concordância também é divulgada. Antes do lançamento, engenheiros sêniores rotularam de forma independente os verdadeiros positivos do conjunto dourado e chegaram a 96,6% de concordância.
Quatro métricas e um sinal que antecipa produção
A avaliação usa quatro métricas, capazes de medir tanto problemas já conhecidos quanto achados novos descobertos pelos sistemas avaliados. Os resultados podem ser fatiados por severidade e por categoria, o que ajuda a comparar agentes de forma objetiva e a escolher o revisor que melhor se encaixa em cada necessidade.
O benchmark segue cinco princípios, entre eles o de não ser um conjunto de demonstração: os pull requests precisam representar a diversidade do trabalho real de revisão.
O ganho prático aparece do lado de dentro do GitHub. Com o ReviewBench, a avaliação offline do Copilot code review (CCR) passou a antecipar com mais eficácia a direção dos experimentos em produção, o que aumenta a confiança de que as melhorias medidas se traduzem em ganhos reais para quem usa o produto.
Melhoras tendem a aparecer nos testes online, e regressões também, o que funciona como uma checagem contínua da validade do próprio benchmark.
Por que isso importa
Ferramentas de revisão automática já influenciam o que é corrigido e o que é ignorado em bases de código. Sem uma avaliação rigorosa, o risco é adotar um revisor barulhento demais, que gera desgaste, ou permissivo demais, que deixa passar falhas críticas.
Ao publicar dados, rubrica, métricas e auditoria de concordância, o GitHub tenta transformar uma discussão qualitativa em comparação verificável, aberta a qualquer time que queira submeter seu próprio sistema de revisão e divulgar resultados.
