c-CRAB, o Benchmark de Agentes de Revisão de Código: O Que Ele Mede, O Que Ele Descobriu e o Que 41,5% Realmente Significa

Um agente de revisão de código e um revisor humano analisaram o mesmo pull request e levantaram a mesma preocupação. Agir de acordo com o comentário do agente corrige o bug; o teste passa. E todas as métricas de similaridade de texto que os autores calcularam classificaram a revisão do agente como essencialmente não relacionada à do humano: BLEU-4 0,00, ROUGE-L 7,02, chrF 20,74, similaridade de embedding 54,59. Mesma preocupação, palavras diferentes, e a forma padrão de avaliar uma revisão não conseguiu perceber que eles concordavam. Esse único exemplo é o argumento por trás do c-CRAB (pronuncia-se “see-crab”), o Code Review Agent Benchmark publicado como arXiv:2603.23448.

c-CRAB avalia agentes de revisão de código, não agentes de escrita de código. Dado um pull request — que pode vir de um humano ou de um agente de codificação — um agente de revisão produz uma revisão, e o c-CRAB pontua essa revisão com base em se agir sobre ela produz uma correção comportamentalmente correta. O benchmark foi construído pelos pesquisadores de engenharia de software Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen e Abhik Roychoudhury, e avalia quatro ferramentas: PR-Agent, Devin, Claude Code e Codex. Um dos autores é afiliado à SonarSource, e o artigo é explícito sobre o que isso significa e o que não significa, nas próprias palavras: “As opiniões e conclusões expressas neste artigo são exclusivamente dos autores e não representam as políticas oficiais ou endossos da SonarSource. Além disso, os resultados aqui apresentados são independentes e não devem ser interpretados como uma avaliação da qualidade dos produtos da SonarSource.”

Duas notas antes do detalhe. Alguns artigos de terceiros referem-se ao mesmo trabalho como “CR-bench”; é o mesmo benchmark, e esta página usa c-CRAB ao longo de todo o texto. Cada figura abaixo é o resultado relatado pelo próprio artigo, obtido hoje do artigo e do pacote de replicação — não reexecutado de forma independente — e a interpretação é nossa, juntamente com a discussão dos profissionais da área que o artigo já atraiu. Nada disso é orientação dos fornecedores cujas ferramentas foram avaliadas. E se você ainda está decidindo se deve ou não executar um agente de revisão de código, nosso guia do comprador sobre agentes de revisão de código é o melhor ponto de partida; esta página é sobre como esses agentes são medidos.

Por que o c-CRAB classifica avaliações com testes, e não com um juiz LLM

A maneira usual de avaliar um agente de revisão de código é comparar sua revisão com a de um humano, usando um LLM como juiz ou uma métrica de similaridade de texto. Os autores do c-CRAB rejeitam ambas. Eles argumentam que o LLM como juiz sofre de viés, instabilidade e sensibilidade ao prompt, o que dificulta uma pontuação reproduzível e consistente. E o estudo de caso acima mostra o que as métricas de strings realmente medem: redação, não eficácia. Naquele pull request do python-telegram-bot, a revisão do Codex disse o mesmo que o humano, e o BLEU-4 e o ROUGE-L não conseguiram reconhecer isso.

Então, o c-CRAB faz o oposto. Cada comentário de revisão humana é convertido em um teste executável que captura o problema subjacente. Um comentário de revisão é considerado correto se agir sobre ele produzir uma correção comportamentalmente correta — uma que faça o teste passar. Cada instância vem com um ambiente Docker executável, então a decisão de passar/falhar é tomada executando código, não perguntando a outro modelo quão semelhantes são dois textos. É por isso que isso importa: o trabalho de uma revisão é mudar o que um desenvolvedor faz, e um teste é o único sinal de pontuação que mede essa mudança diretamente.

O artigo define dois tipos de testes, em suas próprias palavras: “Testes comportamentais importam e executam o código testado em tempo de execução. Eles invocam as funções testadas com entradas específicas e conferem as saídas ou verificam exceções. Por outro lado, testes estruturais inspecionam o texto do código-fonte, buscam padrões e verificam superfícies de API para determinar se as alterações de código desejadas foram feitas.” A divisão final é de 42 comportamentais (17,9%) e 192 estruturais (82,1%). Vale uma frase de honestidade: a maior parte do oráculo é correspondência de padrões no texto-fonte, não execução do código. Esse viés é uma limitação real a se ter em mente.

Como o benchmark foi construído, e quanto custou o funil

c-CRAB é construído sobre o conjunto de dados existente inclusionAI/SWE-CARE, que fornece instâncias de pull-request com metadados de commit; a contribuição própria do c-CRAB é o oráculo, não o corpus de PRs. O pipeline de curadoria executa quatro filtros, e cada um custa instâncias. O artigo relata o funil da seguinte forma:

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

• Filtragem de revisões — 410 PRs, 595 comentários. Um classificador de LLM, calibrado em relação a 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 de linguagem natural em testes — 339 PRs, 481 comentários. Os testes são gerados com GPT-5.2 sob um loop de refinamento guiado por execução de até três tentativas; um teste só é mantido se falhar no código original e passar após a correção.

• Validação com um agente de codificação — 184 PRs, 234 comentários. O Claude Code em um backend Sonnet-4.6 tenta corrigir o código com base apenas no comentário de revisão humano; os casos em que ele não consegue fazer o teste passar são descartados. Este é o conjunto final.

Cerca de 27% das pull requests iniciais sobrevivem. Esse é o preço honesto de um oráculo baseado em testes, e também é a razão pela qual o benchmark é pequeno em vez de extenso. O conjunto sobrevivente: 184 instâncias de PR, 234 comentários de revisão validados, 1,27 testes por instância, 418,1 linhas modificadas por PR em média, 31,8 linhas por teste. Dois anotadores julgaram de forma independente se um teste gerado capturou fielmente a preocupação do revisor humano, em 50 instâncias amostradas, e concordaram 84% das vezes.

Uma discrepância que você notará se ler com atenção: a tabela do conjunto de dados lista 67 repositórios, enquanto a seção de 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 vamos calcular uma média deles nem escolher silenciosamente o mais conveniente. Os leitores usam exatamente esse tipo de detalhe para julgar se um benchmark vale o seu tempo, portanto ambos são reproduzidos aqui como foram publicados.

Os resultados e como interpretá-los.

A taxa de aprovação é a taxa agregada de aprovação dos testes: por instância, é a parcela dos testes desse PR’s que passa, e o destaque é a média entre as instâncias. O artigo relata, por ferramenta:

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

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

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

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

• Humano — 234 comentários, 1,3 por PR — 100% por construção. Os humanos escreveram o oráculo, portanto esta linha é um marcador de escala, não um concorrente.

Leia essas linhas com atenção antes de citar qualquer uma delas. Os “apenas cerca de 40%” do resumo são uma união: 41,5% dos 234 testes foram aprovados por pelo menos uma das quatro ferramentas. Não é a pontuação de um único agente — a melhor pontuação individual é a do Claude Code, com 32,1% — e não significa que as quatro ferramentas juntas detectaram 40% dos defeitos reais. A seção abaixo explica o porquê.

O número mais interessante não é o vencedor. Claude Code e Devin postaram cada um mais de 1.300 comentários — cerca de 7,3 por PR — para chegar a 32,1% e 24,8%. O Codex postou 324, cerca de 1,8 por PR, para chegar a 20,1%. A linha de base humana é de 1,3 comentários por PR. Faça as contas: aproximadamente quatro vezes o volume de comentários compra bem menos que o dobro da taxa de aprovação. Volume não é cobertura. Um revisor tagarela não é a mesma coisa que um revisor útil, e o c-CRAB é o primeiro benchmark criado para mostrar isso.

A utilidade corta no sentido contrário.

As baixas taxas de aprovação parecem uma condenação até você olhar o que mais os autores mediram. Eles inspecionaram manualmente 92 comentários em 6 PRs e julgaram 84% deles úteis (77 de 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Então, a maioria dos comentários que falham no teste c-CRAB não é ruído; eles abordam algo que o revisor humano não levantou. A amostra é pequena — 92 comentários, 6 PRs — e o artigo reconhece isso, e nós também deveríamos.

O mesmo padrão aparece no que os revisores comentam. Revisores humanos penderam para manutenibilidade, design e documentação; as ferramentas penderam para robustez, testes e tratamento de erros. O artigo interpreta isso como um argumento a favor da colaboração humano-agente, em vez da substituição. É também a melhor explicação disponível para as pontuações parecerem baixas: agentes e humanos frequentemente não estão olhando para as mesmas coisas, e o oráculo só recompensa a lista do humano.

O que o c-CRAB não consegue ver

O benchmark é explícito sobre seu ponto cego, e nós também. O c-CRAB não dá crédito para 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 obtém zero por isso. O artigo coloca isso diretamente — ferramentas automatizadas de revisão podem gerar outros comentários valiosos que os revisores humanos não identificaram, mas “como outros benchmarks existentes, o c-CRAB não avalia diretamente esses comentários adicionais.”

Essa única frase é a correção para a maior parte da cobertura desse resultado. Quem cita “agentes de revisão resolvem apenas 40%” como se isso medisse quantos defeitos reais os agentes detectam está interpretando mal o número. Ele mede quantas preocupações levantadas por humanos os agentes, em conjunto, conseguiram resolver — uma afirmação mais restrita e muito mais honesta.

Executando você mesmo

Se você quiser reproduzir os números ou adicionar seu próprio revisor, o pacote de replicação está público em c-CRAB-Benchmark/dataset. O README é a verdadeira documentação, e é honesto sobre a natureza do projeto. A configuração é code>uv sync/code>; você precisa do Docker e de uma code>OPENAI_API_KEY/code> ou code>ANTHROPIC_API_KEY/code>, e o Claude Code também lê credenciais de code>~/.claude/.credentials.json/code>. A organização também publica imagens Docker pré-construídas para os ambientes.

O layout: code>pipeline//code> contém a lógica do pipeline e os prompts, code>execution//code> os construtores de imagens Docker e utilitários de runtime, code>results_preprocessed//code> o subconjunto de benchmark lançado (410 instâncias pré-processadas), code>results_pipeline_funnel//code> os arquivos JSONL do stage0–stage4 e o resumo do funil, e code>raw_results_compressed//code> as saídas brutas do experimento.

Reproduzir a execução completa envolve cinco etapas: construir os ambientes Docker (code>execution.build_swe_care/code>), gerar os testes (code>run_testgen_full.sh/code>), coletar as revisões de base (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), executar a resolução por agente (code>run_batch_agent_resolution.py/code>) e, em seguida, avaliar (code>run_batch_tool_eval.py --tool <name>/code>). Se você quiser adicionar um quinto revisor, esteja ciente de que o ponto de extensão não é uma interface de plugin: os prompts de revisão de base para cada ferramenta estão em code>run_batch_baselines.py/code>, e o README não documenta uma maneira mais limpa — você edita esse script.

Mais dois fatos antes de você clonar. O artigo é licenciado sob CC BY 4.0; a página do repositório não declara uma licença para o código, portanto não presuma uma. E o artigo não publica números de custo ou uso de tokens para executar o benchmark — isso não é publicado, então não vamos inventar. O que o pipeline implica: uma imagem Docker por PR em 184 instâncias, mais uma passada de resolução por agente, não é uma tarde em escala de laptop.

O que isso significa para quem lança um pipeline de revisão

O argumento central do c-CRAB é que um juiz LLM é um oráculo não confiável. Se você não pode construir oráculos executáveis — e a maioria das equipes não pode — a melhor mitigação disponível é nunca deixar o juiz rodar no modelo que produziu a revisão. Um juiz que compartilha o modelo do revisor concorda consigo mesmo, e a etapa de verificação se torna um carimbo de borracha que ainda retorna um número.

É exatamente essa a falha contra a qual a receita de roteamento por trás do revisor que distribuímos protege — e é um paralelo de design com a crítica do c-CRAB, não um resultado de benchmark. O harness executa um juiz LLM mesmo assim, como uma segunda passada que agrupa os achados, atribui a cada grupo uma pontuação de 0–1 sobre se é um defeito concreto nesta mudança e descarta tudo o que fica abaixo de um limiar. A receita que rege isso, code>recipes/orcacode-review.dsl.yaml/code>, é um arquivo público. A Action nunca nomeia um modelo: ela chama um alias de roteador, e a receita decide. Conforme provisionada, a receita tem quatro linhas — o padrão do revisor é code>deepseek/deepseek-v4-flash-0731/code>, e uma regra que corresponde ao cabeçalho code>x-cr-lens: judge/code> envia a passada do juiz para code>z-ai/glm-5.3/code>, um fornecedor diferente. As próprias palavras da receita exigem que o juiz “NÃO DEVE NOMEAR O MODELO DO PADRÃO”, porque no modelo do próprio revisor ele “concorda consigo mesmo, então a passada fica inerte embora ainda relate sucesso”.

Um avaliador de outro fornecedor reduz a autoconsistência; isso não transforma um avaliador de LLM em um teste. O c-CRAB não testou nosso revisor, e não vamos dar a entender o contrário. OrcaCode Review executa uma etapa de revisão além de um avaliador 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.

Conclusão

c-CRAB é o primeiro benchmark de revisão de código cuja pontuação você pode confiar em grande parte para significar o que diz: uma revisão só passa quando agir sobre ela corrige o código. Os números principais são genuinamente baixos — melhor ferramenta individual 32,1%, união 41,5% — mas eles medem a sobreposição com as preocupações levantadas por humanos, não a qualidade das revisões, e os dados de utilidade mostram que a maioria dos comentários é sinal real. As conclusões duradouras são aquelas que o próprio artigo defende: volume não é cobertura, agentes e humanos olham para coisas diferentes, e a implantação certa é a colaboração humano-agente. E o benchmark é aberto, então o próximo passo honesto é rodar seu próprio revisor nele e obter seu próprio número.