Benchmark de Agente de Revisão de Código: Como Avaliar um Revisor e Executar o c-CRAB no Seu Próprio Código

Como saber se um agente de revisão de código é bom? Durante a maior parte da curta história deste campo, a resposta era {{1}}"medir o quanto seus comentários se aproximam dos de um revisor humano"{{/1}} — {{2}}o que parece razoável até você realmente tentar fazer isso, porque dois revisores podem apontar o mesmo problema com palavras completamente diferentes{{/2}}. {{3}}O Code Review Agent Benchmark{{/3}} — {{4}}o artigo é arXiv:2603.23448{{/4}}, {{5}}seu conjunto de dados é o c-CRAB{{/5}} — {{6}}é a primeira tentativa séria de avaliar uma revisão pelo que agir com base nela produz, em vez de pela sua redação{{/6}}. {{7}}Ele converteu 234 comentários de revisão humana em testes executáveis{{/7}}, {{8}}executou quatro revisores amplamente utilizados contra eles — PR-Agent, Devin, Claude Code e Codex — e descobriu que, em conjunto, os quatro passam em 41,5% desses testes{{/8}}, {{9}}"apenas cerca de 40%"{{/9}} nas palavras do próprio artigo. {{10}}Esta página é um guia prático: como ler esse resultado sem deturpá-lo, como executar o c-CRAB você mesmo e o que fazer quando a sua base de código simplesmente não está no benchmark.{{/10}}

O número da manchete é a coisa menos útil nesta página. As coisas úteis são o método e os modos de falha: por que todo esquema de pontuação anterior estava medindo a coisa errada, o que custa pontuar uma revisão com testes executáveis em vez disso, e por que "agentes de revisão só capturam 40% dos bugs" é uma leitura equivocada em três aspectos do resultado real. Tudo aqui é uma leitura comunitária do benchmark publicado e da experiência de profissionais que o executam — não orientação de fornecedores dos criadores de ferramentas envolvidos.

Por que as métricas óbvias não funcionam

Antes do c-CRAB, as avaliações de agentes de revisão de código se dividiam em um pequeno número de famílias, e a própria tabela de comparação do artigo (Tabela 1) expõe essa linhagem. A mais antiga é a sobreposição de texto — BLEU, ROUGE, chrF e companheiros, usados por benchmarks como CodeReviewer e ContextCRBench. A ideia é que o comentário de um agente é bom quando seus n-gramas correspondem aos de um humano. A ideia falha exatamente no tipo de caso que é onipresente na revisão de código: o mesmo defeito descrito com palavras diferentes.

O estudo de caso do artigo é o exemplo mais claro. Em um pull request no python-telegram-bot (PR #3514), o revisor humano e o Codex apontaram o mesmo bug de robustez de indexação aninhada. A revisão do Codex estava comportamentalmente correta — um agente de codificação que agiu com base nela produziu uma correção que passou no teste executável. No entanto, as métricas de texto atribuíram a ela BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74 e similaridade de embedding 54.59. Nenhuma sobreposição de n-gramas, e a revisão estava correta. A mesma preocupação, palavras diferentes: as métricas de string não conseguiram captar isso. A similaridade de embedding é um avanço parcial — 54.59 contra uma aprovação confirmada ainda está longe de um limiar utilizável — e herda o mesmo problema de forma mais suave.

LLM-as-judge, em que um modelo compara a revisão do agente com a do humano e vota, resolve o problema de vocabulário, mas importa três novos, que o artigo nomeia diretamente: viés, instabilidade e sensibilidade ao design do prompt. Execute a mesma comparação duas vezes e um juiz pode lhe dar vereditos diferentes; reformule o prompt de julgamento e as classificações mudam. Quando você está escolhendo entre dois revisores que estão a três pontos de distância no mesmo benchmark, um juiz com essa variância não pode respaldar uma decisão — e uma pontuação que não se pode reproduzir não é uma pontuação.

O que um oráculo executável compra — e o que custa

A ideia sobre a qual o c-CRAB é construído é simples e radical ao mesmo tempo: em vez de perguntar "a crítica soa como a do humano?", pergunte "se você agir com base na crítica, o código é corrigido?". Cada comentário de revisão humana retido é convertido em um teste executável que captura o problema subjacente. Um comentário de revisão conta como correto se agir sobre ele produz uma correção comportamentalmente correta que faz o teste passar — e cada instância vem com um ambiente Docker executável, então "fazer o teste passar" é um fato em vez de um julgamento.

O artigo define dois tipos de teste. Testes comportamentais "importam e executam o código testado em tempo de execução", invocando funções "com entradas específicas" e verificando "saídas ou verifica[ndo] exceções". Testes estruturais "inspecionam o texto do código-fonte, correspondem a padrões e verificam superfícies de API para determinar se as mudanças desejadas no código foram feitas". A divisão final é de 42 comportamentais (17,9%) e 192 estruturais (82,1%) — e esse desequilíbrio merece uma frase honesta: a maior parte desse oráculo é correspondência de padrões no texto-fonte, não execução do código. O padrão-ouro é o teste comportamental; a maioria do conjunto de dados é a versão pragmática dele.

Construir o oráculo é um funil de quatro estágios, e cada estágio descarta coisas:

• Conjunto de dados inicial — 671 PRs, 1.313 comentários de revisão.

• Filtragem de revisões — 410 PRs, 595 comentários. Um classificador de LLM, calibrado contra um conjunto de referência de 100 comentários anotados manualmente, mantém apenas problemas objetivamente verificáveis e descarta feedback conversacional ou subjetivo.

• Construção de ambiente executável — 410 PRs, 595 comentários. Uma imagem Docker por PR, com resolução de dependências recorrendo a um agente de codificação quando a automação falha.

• Convertendo comentários em linguagem natural para testes — 339 PRs, 481 comentários. Gerado com GPT-5.2 em um loop de refinamento guiado por execução (até três tentativas); um teste é mantido apenas se falhar na versão anterior e passar na versão posterior.

Validação com um agente de codificação — 184 PRs, 234 comentários (final). O Claude Code em um backend Sonnet-4.6 tenta corrigir o código tendo apenas o comentário de revisão humana; as instâncias em que ele não consegue fazer o teste passar são descartadas.

Cerca de 27% dos pull requests iniciais sobrevivem. Diga isso claramente, porque é o preço honesto de um oráculo baseado em testes: se um comentário não for acionável o suficiente para se tornar um teste com falha, ou o ambiente não puder ser construído, ou um agente de codificação competente não puder corrigir o código apenas com base no comentário, a instância é descartada. É também por isso que o benchmark é pequeno. 184 instâncias de PR e 234 comentários validados são um conjunto de dados que você pode ler, não um corpus em que você pode se afogar — e, para um oráculo que precisa executar ambientes Docker reais, a pequenez é uma característica.

Para referência: uma instância média envolve 418,1 linhas modificadas, os testes têm em média 31,8 linhas e há 1,27 testes por instância. Dois anotadores concordaram 84% das vezes — em mais de 50 instâncias amostradas — sobre se um teste gerado capturou fielmente a preocupação do revisor humano.

Uma verruga bibliográfica que você vai encontrar se ler o artigo você mesmo: a tabela de dados (Tabela 4) lista 67 repositórios, enquanto a seção Ameaças à Validade diz "184 instâncias de pull requests com 234 oráculos verificáveis em 56 repositórios." O artigo apresenta ambos os números em lugares diferentes e não os reconcilia. Não escolha um favorito e não faça uma média deles — cite cada um onde aparece. Discrepâncias como essa são exatamente o detalhe que os leitores usam para decidir se um benchmark vale o seu tempo.

Para due diligence sobre independência: o artigo revela que um dos autores é afiliado à SonarSource e afirma que as conclusões não devem ser interpretadas como "uma avaliação da qualidade dos produtos da SonarSource". Esse é o aviso deles, citado em vez de parafraseado.

Como ler uma partitura no c-CRAB sem deturpá-la

A métrica principal é a taxa de aprovação: por instância, a parcela dos testes daquele PR que passam, calculada como média nas 184 instâncias. Aqui está a tabela de resultados completa do artigo, uma linha por revisor. A linha dos humanos é um marcador de escala, não um concorrente — os humanos escreveram o oracle, então eles pontuam 100% por construção:

• Claude Code — 1.336 comentários, 7,3 por PR, no geral 32,1% (comportamental 38,1%, estrutural 30,7%).

• Devin — 1.344 comentários, 7,3 por PR, no geral 24,8% (comportamental 31,0%, estrutural 23,4%).

• PR-Agent — 524 comentários, 2,8 por PR, no geral 23,1% (comportamental 38,1%, estrutural 19,8%).

• Codex — 324 comentários, 1,8 por PR, no geral 20,1% (comportamental 38,1%, estrutural 16,1%).

• Humano — 234 comentários, 1,3 por PR, 100% por construção.

Três correções, porque o "apenas cerca de 40%" do resumo é o número mais deturpado neste canto da conversa sobre codificadores de IA no momento. Primeiro, o número de 41,5% — 97 dos 234 testes aprovados por pelo menos uma ferramenta — é uma união entre todos os quatro revisores: um teste conta uma única vez se qualquer agente o passou. Nenhum agente individual alcançou 41,5%; a melhor pontuação individual é a do Claude Code, com 32,1%. Segundo, a linha humana é o oráculo, não uma concorrente; repeti-la como "humanos vencem os bots" é um erro de categoria. Terceiro, e mais importante: o c-CRAB não dá crédito por um problema válido que o revisor humano nunca levantou. O oráculo é a intenção da revisão humana. Um agente que encontra um bug real que ninguém mencionou recebe zero por isso. Portanto, "agentes de revisão de IA só capturam 40% dos bugs" está errado de três maneiras — é uma união, não é uma taxa de captura de bugs, e mede concordância com revisores humanos, não a correção total.

O volume de comentários é a armadilha.

O número mais interessante nos resultados não é o vencedor. Claude Code e Devin publicaram cada um mais de 1.300 comentários — cerca de 7,3 por PR — para alcançar 32,1% e 24,8%. Codex publicou 324 comentários, cerca de 1,8 por PR, e alcançou 20,1%. A linha de base humana é de 1,3 comentários por PR. Volume não é cobertura: cerca de cinco vezes mais comentários compra bem menos que o dobro da taxa de aprovação. Se você está escolhendo um revisor, o custo real de todos esses comentários extras é a fadiga da revisão humana — cada comentário que um agente publica é uma decisão que uma pessoa precisa triar.

A conclusão sobre a utilidade vai na outra direção, e é essa a parte que impede que isto seja uma história barata de "os bots são barulhentos". Os autores inspecionaram manualmente 92 comentários em 6 PRs e julgaram 84% (77/92) úteis — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Portanto, a maioria dos comentários que falham no teste não é ruído; eles dizem respeito a algo que o revisor humano não levantou. A amostra é pequena — 92 comentários, 6 PRs — e vale a pena dizer isso no mesmo fôlego que as porcentagens.

O que os dois lados realmente discutem explica a forma dos resultados. Os revisores humanos tenderam para manutenibilidade, design e documentação; as ferramentas tenderam para robustez, testes e tratamento de erros. O artigo interpreta isso como um argumento para a colaboração humano-agente, em vez de substituição — e também é a melhor explicação disponível para por que as pontuações parecem baixas. Um revisor que é afiado em casos extremos, mas silencioso quanto ao design, sistematicamente deixará de captar as categorias que os humanos sinalizam, e o oráculo é construído inteiramente a partir de sinalizações humanas.

Praticantes que já trabalharam nisso chegam ao mesmo lugar. Um artigo detalhado de Daniel Vaughan, que chama o trabalho de CR-bench, chega à mesma conclusão e o transforma em um fluxo de trabalho: deixe o agente fazer a varredura de robustez e correção, mantenha os humanos no design, nas convenções e na arquitetura — as categorias em que os agentes pontuam pior — e oriente o agente com instruções de revisão que nomeiem as categorias fracas. Sua ressalva mais útil para quem lê o leaderboard: "utilidade não é o mesmo que taxa de aprovação", porque o conjunto de testes exige que a correção corresponda à intenção do humano, e uma correção alternativa válida falha no teste. O caminho de 20% para uma pontuação significativamente maior, na leitura dele, não é uma atualização de modelo — é trabalho de configuração.

Executando o c-CRAB você mesmo

Tudo o que está acima é leitura de resultados de outras pessoas. O pacote de replicação torna o benchmark executável — ele está em c-CRAB-Benchmark/dataset no GitHub — e o README é honesto sobre o que é necessário.

Requisitos: code>uv sync/code>; Docker; e code>OPENAI_API_KEY/code> ou code>ANTHROPIC_API_KEY/code> (o Claude Code também lê credenciais de code>~/.claude/.credentials.json/code>, montadas em contêineres por padrão). A estrutura tem cinco diretórios: code>pipeline//code> (lógica do pipeline e prompts), code>execution//code> (construtores de imagens Docker e auxiliares de runtime), code>results_preprocessed//code> (o subconjunto publicado do benchmark), code>results_pipeline_funnel//code> (os arquivos JSONL do stage0–stage4 e o resumo do funil), e code>raw_results_compressed//code> (saídas brutas dos experimentos). As cinco etapas, em ordem:

1. Crie os ambientes Docker — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Imagens pré-construídas também são publicadas na organização de pacotes GitHub do c-CRAB-Benchmark, se você preferir pular a construção.

2. Gere os testes — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. Colete revisões de linha de base — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. Configure as credenciais da ferramenta externa correspondente antes desta etapa.

4. Execute a resolução de agentes — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. Avalie — repita uma vez por ferramenta: code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

Duas coisas que o README não anuncia. Adicionar um quinto revisor significa editar code>run_batch_baselines.py/code> — é aí que ficam os prompts de revisão de linha de base por ferramenta, e não há interface de plugin; o README não documenta nenhum ponto de extensão mais limpo. E o repositório não contém um arquivo de licença explícito, então não assuma que o código é MIT ou Apache — o artigo é CC BY 4.0, e os termos do próprio código não são declarados.

Custo é o outro item não anunciado. O artigo não publica números de tokens ou dólares para executar o pipeline, então trate qualquer número de custo que você vir citado online como não verificado. O que a estrutura implica é claro o suficiente: uma imagem Docker por PR em 184 instâncias, além de uma passada de resolução do agente de codificação e uma passada de avaliação por ferramenta. Isso não é uma tarde em escala de laptop — planeje computação real.

Quando você não pode pagar por oráculos executáveis

A posição honesta da maioria das equipes é: o benchmark está certo de que um juiz LLM não consegue pontuar revisões, mas construir um oráculo baseado em testes para os seus próprios PRs é um grande esforço. A distinção que vale a pena traçar é entre um juiz LLM como pontuador e um juiz LLM como filtro. A rejeição do c-CRAB ao juiz como oráculo não torna um juiz inútil dentro de um revisor — um juiz que agrupa descobertas duplicadas e descarta as fracas ainda pode aumentar a precisão. O modo de falha contra o qual se deve projetar é a independência.

Um juiz que roda no modelo do próprio revisor concorda consigo mesmo: lê a revisão, considera-a plausível e relata sucesso sem mudar nada. Um juiz de outro fornecedor reduz essa autoconcordância — não transforma um juiz em um teste, mas impede o carimbo automático. Podemos mostrar um exemplo concreto e verificável exatamente dessa salvaguarda porque nosso próprio arcabouço é aberto: Orca-Code-Review no GitHub é licenciado sob MIT, e sua receita de roteamento declara a regra nas próprias palavras do repositório — o juiz "NÃO DEVE NOMEAR O MODELO PADRÃO", porque "no modelo do próprio revisor ele concorda consigo mesmo, então a aprovação fica inerte embora ainda relate sucesso." A Action nunca nomeia um modelo; a receita decide. Conforme provisionado, o padrão do revisor é deepseek/deepseek-v4-flash-0731, e uma regra que corresponde ao cabeçalho code>x-cr-lens: judge/code> envia a avaliação do juiz para z-ai/glm-5.3 — um fornecedor diferente. Isso é um paralelo de design ao argumento do c-CRAB, não um resultado: não estamos no benchmark e não há pontuação c-CRAB para nosso revisor. Mas é a mitigação prática disponível para quem não pode construir oráculos executáveis, e é barato quando juiz e revisor podem estar em provedores diferentes atrás de uma única chave — que é para isso que serve um roteador. No OrcaRouter, o revisor e seu juiz são duas linhas em um DSL de roteamento, e você paga o preço de tabela do provedor com zero margem.

Quando o seu código não está no benchmark

184 PRs espalhados por 56 ou 67 repositórios públicos não são o seu código, e nunca seriam. A parte transferível é o método, e você pode executá-lo no seu próprio histórico em uma escala muito menor. Pegue PRs mesclados que tiveram comentários de revisão humana. Para uma amostra desses comentários, escreva um teste que falhe antes de a revisão ser aplicada e passe depois — a propriedade falha-depois-passa é o jogo inteiro. Execute o seu revisor candidato no diff pré-revisão. Depois verifique se agir sobre os comentários dele faz o teste passar. O que você obtém é um número calculado sobre o código que você realmente entrega, o que vale mais do que uma posição em leaderboard. O que isso custa é exatamente a parede em que o artigo esbarrou: você precisa de ambientes reproduzíveis por PR, porque um teste que só passa no seu laptop não é um oráculo.

Você não precisa de 234 testes. Uma dúzia de testes bem escolhidos em PRs sobre os quais seu time realmente debateu vai dizer mais sobre o seu revisor do que uma pontuação de benchmark. E uma análise paralela de profissionais sobre essa família de benchmarks é direta quanto ao gate: a precisão do classificador de LLM em decidir se um comentário é uma issue válida e verificável fica entre 66% e 85%; portanto, trate a filtragem automática como uma shortlist e mantenha uma etapa de arbitragem humana antes que qualquer coisa vire um teste. O mesmo artigo observa que o ReviewBench da LangChain, construído de forma independente sobre a mesma ideia de converter comentários em testes, recupera no máximo cerca de 30% das issues de sua linha de base — o mesmo patamar dos 20–32% do c-CRAB — e um lembrete de que deltas de um dígito no leaderboard entre ferramentas costumam ser menores do que o ruído da sua própria configuração.

Se você está decidindo se deve comprar uma ferramenta de revisão, essa é outra questão — nosso guia de compra de agentes de revisão de código aborda bot versus agente, precificação por assento versus por token e quando a auto-hospedagem compensa — e, depois que você tem uma, o custo operacional de um harness de revisão a cada push é abordado em nosso guia explicativo de revisão de código automatizada. Esta página trata apenas de medição, e o artigo que a acompanha detalha a anatomia do benchmark: o funil de construção, as estatísticas do conjunto de dados e a tabela completa de resultados.

Perguntas Frequentes

41,5% é a melhor pontuação de um agente? Não. 41,5% é a união de todas as quatro ferramentas — um teste é contado uma vez se alguma delas passou. A melhor pontuação individual é a do Claude Code, com 32,1%.

O c-CRAB mede quantos bugs um revisor encontra? Não. Ele mede o quanto uma revisão corresponde ao que um revisor humano levantou, convertido em testes executáveis. Um defeito real que o humano nunca mencionou pontua zero, por mais válido que seja.

Os revisores humanos "venceram" os bots? A linha 100% humana é o próprio oráculo — os humanos escreveram os testes — portanto, é um marcador de escala, não um concorrente.

c-CRAB é a mesma coisa que CR-bench? Sim. O dataset é c-CRAB; alguma cobertura de terceiros o chama de CR-bench, mas há apenas um benchmark aqui.

Quanto custa executá-lo?O artigo não publica valores de custo. Uma imagem Docker por PR em 184 instâncias, além de uma passada de resolução por agente, implica computação real — não uma tarde de escala de laptop.

Conclusão

A contribuição do c-CRAB não é o leaderboard — é a demonstração de que uma revisão pode ser pontuada executando seus conselhos, e que os esquemas de similaridade de texto e de LLM-judge que vieram antes estavam pontuando a coisa errada. Se você levar apenas uma coisa, que seja a correção em três partes: 41,5% é uma união, a linha humana é o oráculo, e o benchmark não dá nenhum crédito para defeitos que humanos nunca levantaram. E se você quer um número que possa usar na prática, o método transfere-se — testes que falham e depois passam nos seus próprios PRs mesclados, uma etapa de adjudicação humana e, se você não puder construir oráculos executáveis, pelo menos um juiz cujo modelo seja independente do modelo do revisor.

Se você preferir medir um revisor a discutir sobre um, comece por um harness que possa ler. OrcaCode Review executa uma rodada de revisão mais um juiz de verificação independente, por token em vez de por assento, e todos os prompts nele são públicos — para que você possa apontá-lo para um benchmark como este e obter seu próprio número em vez do nosso.