# O Paradoxo do Benchmark no Code Review com IA > Benchmarks de vendors reportam F1 de 60%. Testes acadêmicos mostram 19%. O que a lacuna de 3x significa para medir code review com IA. Releezy Team · 2026-02-05 [Ler no site](https://releezy.com/pt/blog/ai-code-review-benchmark-paradox) Em fevereiro de 2026, pelo menos quatro empresas de code review com IA publicaram benchmarks mostrando que suas ferramentas lideram o mercado. Cada uma venceu o próprio teste. Isso não é coincidência. É um padrão, e o padrão é o insight. ## Cada Um Vence o Seu O padrão é consistente o suficiente para chamar atenção de qualquer pessoa que decide quais ferramentas o time vai adotar. A Qodo publicou um benchmark com 100 PRs e 580 issues injetados. Resultado: Qodo vence com F1 de 60,1%. A Augment publicou seu próprio benchmark com 50 PRs. Resultado: Augment vence com F1 de 59%. A Greptile publicou o dela. Resultado: Greptile vence com 82% de taxa de captura. A RevEval, da AIMultiple, analisou 309 PRs. Resultado: CodeRabbit vence em 51% dos casos. Quatro benchmarks. Quatro vencedores diferentes. Cada um publicado pela empresa que venceu, ou por uma entidade com incentivos alinhados. Isso não significa que os benchmarks são fraudulentos. Significa que são insuficientes. Cada empresa desenha o teste para medir o que faz melhor. Injetar bugs sintéticos favorece ferramentas otimizadas para detecção de padrões conhecidos. Medir taxa de captura bruta sem pesar falsos positivos favorece ferramentas que reportam tudo. Cada metodologia é legítima isoladamente. Mas quando o criador do teste é também o vencedor, o benchmark nos diz mais sobre estratégia de marketing do que sobre capacidade técnica. ## A Lacuna de 3x E então existe a evidência acadêmica. O SWR-Bench, publicado por pesquisadores da Universidade de Pequim, avaliou ferramentas de code review com IA em 1.000 PRs orgânicos: não injetados artificialmente, mas extraídos de projetos reais, com bugs reais encontrados por desenvolvedores reais. O melhor resultado: F1 de 19,38%. Releia: 19,38%. Contra os 60% que os vendors reportam. A diferença entre 60% e 19% não é marginal. É uma lacuna de 3x. E essa lacuna tem uma explicação técnica precisa: bugs injetados são mais fáceis de detectar do que bugs orgânicos. Quando um pesquisador injeta um bug em código limpo, ele cria uma anomalia visível, um corpo estranho em tecido saudável. Ferramentas de IA são boas em detectar anomalias. Mas bugs reais não são anomalias inseridas em código limpo. São consequências de decisões que faziam sentido no momento, interações sutis entre componentes, ou efeitos colaterais de mudanças incrementais. São o tipo de defeito que um revisor humano encontra não por padrão, mas por entender o contexto. O SWR-Bench revelou outro dado relevante: uma estratégia de múltiplas passagens de revisão melhora o F1 em 43,67% comparado com passagem única. Isso sugere que review de passagem única, o modelo padrão de quase todas as ferramentas comerciais, é fundamentalmente limitado. Não por falta de inteligência do modelo, mas por falta de iteração sobre o mesmo código. ## O Código que a IA Escreve, a IA Não Revisa Bem Há uma ironia nessa discussão que merece ser explicitada. O relatório da CodeRabbit de dezembro de 2025, analisando 470 PRs do GitHub, mostrou que código gerado por IA produz 1,7x mais issues que código escrito por humanos. Ineficiências de performance aparecem 8x mais frequentemente. Issues de lógica e correção aumentam 75%. A implicação é circular: usamos IA para gerar código mais rápido, o que aumenta o volume de PRs, o que sobrecarrega revisores humanos, o que cria demanda por agentes revisores, que têm dificuldade particular em encontrar os tipos de bugs que código de IA mais produz. A velocidade de geração de código aumentou exponencialmente. A capacidade de revisão permanece linear. Revisão está se tornando o gargalo da engenharia de software, não a codificação. E os benchmarks que deveriam nos ajudar a escolher ferramentas para resolver esse gargalo medem precisamente o tipo errado de bug. ## Recall versus Precision Não É Decisão Técnica Quando engenheiros avaliam ferramentas de code review, gravitam naturalmente para métricas técnicas: precision, recall, F1. Essas métricas são úteis, mas escondem uma decisão que não é técnica. É uma decisão de liderança de engenharia. Precision alta significa menos alarmes falsos. A ferramenta só reporta quando tem alta confiança. O custo: bugs reais escapam silenciosamente. Recall alto significa mais capturas reais. A ferramenta reporta tudo que parece suspeito. O custo: desenvolvedores são bombardeados com alertas, muitos deles irrelevantes. A escolha entre precision e recall não é uma configuração técnica. É uma decisão de política de engenharia. Times em setores regulados, como fintechs, saúde e infraestrutura crítica, provavelmente precisam de recall alto, mesmo ao custo de mais ruído. Times onde velocidade de entrega é prioridade podem preferir precision alta, aceitando que alguns bugs passem. Nenhum benchmark existente faz essa distinção. Todos reportam F1, a média harmônica entre precision e recall, como se houvesse um único número que captura a qualidade de uma ferramenta. Não captura. O time precisa decidir qual tipo de erro é mais caro: o falso positivo que desperdiça tempo do desenvolvedor, ou o falso negativo que escapa para produção. ## O Que os Desenvolvedores Realmente Pensam Um estudo de 2025 conduzido por pesquisadores da Chalmers em parceria com a WirelessCar investigou como desenvolvedores realmente experimentam code review com IA. Os resultados complicam a narrativa de adoção linear. Agentes de review complementam, não substituem revisores humanos. Desenvolvedores acham reviews de IA mais úteis para PRs grandes ou em áreas de código que não conhecem bem, essencialmente como um resumo inteligente antes da revisão detalhada. Mas o dado mais importante é sobre confiança: falsos positivos fazem desenvolvedores ignorarem todo o feedback de IA. Não apenas o alerta específico que estava errado, mas todo o feedback subsequente. Uma experiência ruim contamina a credibilidade de todas as experiências futuras. Isso explica o dado do mercado: mesmo com 84% dos desenvolvedores usando ferramentas de IA (Stack Overflow 2025), 46% desconfiam da precisão do output. A adoção é alta. A confiança, não. Para gestores, isso significa que calibração importa mais que capacidade bruta. Uma ferramenta que encontra 30% dos bugs com alta precisão gera mais valor do que uma que encontra 60% mas afoga o time em falsos positivos, porque a segunda será ignorada. ## O Que Nenhum Benchmark Mede Existe uma dimensão inteira do code review que nenhum benchmark tenta medir: a compreensão de intenção. O valor mais profundo de um revisor humano experiente não é encontrar bugs de sintaxe ou violações de padrão. Ferramentas automatizadas fazem isso há décadas. É entender por que uma mudança foi feita e avaliar se a abordagem escolhida é a melhor para o contexto. "Esse código funciona, mas cria uma dependência que vai complicar a migração que planejamos para o próximo trimestre." "A lógica está correta, mas o nome dessa variável vai confundir quem mantiver isso depois." "Essa otimização resolve o problema de performance, mas viola o contrato implícito que temos com o módulo vizinho." Esses são julgamentos de intenção, contexto e consequência de longo prazo. São exatamente o que torna a revisão humana a linha de base insubstituível para decisões arquiteturais, e são completamente invisíveis em qualquer benchmark existente. Quando um benchmark reporta F1 de 60%, está medindo a capacidade de encontrar defeitos localizados em um diff. A parte mais valiosa da revisão, o julgamento sobre direção, coerência e implicações futuras, não tem sequer uma métrica proposta. ## O Que Fazer Com Isso Se você é responsável por decisões de ferramentas de engenharia, três implicações práticas. **Primeiro, trate benchmarks de vendors como material de marketing.** Leia, entenda a metodologia, mas não base decisões de compra neles. O único benchmark confiável é o que você conduz no seu próprio código, com seus próprios PRs, medindo o que importa para seu contexto. **Segundo, decida sua política de precision versus recall antes de avaliar ferramentas.** Se você não sabe qual tipo de erro é mais caro para seu time, nenhuma métrica vai te ajudar. Essa é uma decisão de liderança de engenharia, não de configuração de ferramenta. **Terceiro, meça o que os benchmarks não medem.** Taxa de resolução, ou seja, alertas reportados que foram efetivamente corrigidos, é uma proxy melhor que F1 para valor real. Se 60% dos alertas são ignorados, a ferramenta não está gerando valor, está gerando ruído. E meça a confiança do time: uma pesquisa mensal de "você confia nos alertas da ferramenta?" vale mais que qualquer F1 score. A lacuna de 3x entre benchmarks de vendors e testes acadêmicos não é uma curiosidade estatística. É um convite para perguntas melhores. Não "qual ferramenta tem o maior score?", mas "o que essa ferramenta captura no nosso código, com os nossos bugs, na taxa de falsos positivos que aceitamos, em uma configuração que nossos desenvolvedores vão confiar?" O que você pode controlar é como seu time define "bom". Essa definição precisa vir de dentro, de uma régua própria, não de um benchmark que o vendor publicou para ganhar um deal. --- ### Fontes - Qodo. "AI Code Review Benchmark." Fevereiro 2026. 100 PRs, 580 issues injetados. - Augment. "AI Code Review Agent Benchmark." Fevereiro 2026. 50 PRs. - Greptile. "Code Review Agent Benchmark." greptile.com, 2026. - AIMultiple/RevEval. "AI Code Review Benchmark." Avaliação de 309 PRs. - SWR-Bench. "Do LLMs Provide Good Code Reviews?" Universidade de Pequim, 2026. 1.000 PRs orgânicos. - CodeRabbit. "AI-Generated Code: Quality Report." Dezembro 2025. 470 PRs do GitHub. - WirelessCar/Chalmers University. Estudo sobre LLMs em code review. 2025. - Stack Overflow. "Developer Survey 2025." Dados sobre adoção e confiança em ferramentas de IA. --- Se você quer construir essa régua própria para os seus pull requests, descubra como times medem a [efetividade do code review](/pt/code-review-effectiveness) contra a linha de base humana.