A Revisão de Código por IA Define Seus Próprios Padrões. Quem Revisa o Revisor?
Quando escrevemos sobre o BugBot do Cursor em janeiro, a taxa de resolução era de 70%. Três meses e 50.310 PRs depois, chegou a 78,13%. Um salto de 26 pontos percentuais desde o lançamento em julho de 2025.
O número impressiona. O mecanismo por trás dele é mais interessante.
O BugBot opera hoje em mais de 110 mil repositórios com aprendizado ativo. Acumulou 44 mil regras, cada uma gerada a partir de feedback de desenvolvedores. Regras se promovem automaticamente quando a evidência sustenta. Se auto-desativam quando desenvolvedores rejeitam suas sugestões. O sistema escreve seus próprios padrões e os aplica sem esperar aprovação humana para mudar a política.
É aqui que a conversa fica séria.
Duas Filosofias, Mesmo Problema
Dois artigos publicados com 24 horas de diferença em abril de 2026 revelam uma tensão fundamental na forma como times de engenharia pensam sobre revisão assistida por IA.
O BugBot do Cursor (Michael Zhao, blog do Cursor) apresenta benchmarks comparando seis ferramentas. BugBot lidera com 78,13%. Greptile vem em seguida com 63,49%. CodeRabbit marca 48,96%. GitHub Copilot fica em 46,69%. Codex em 45,07%. Gemini Code Assist fecha com 30,93%.
A metodologia: apenas repositórios públicos, com um LLM avaliando se os comentários gerados por IA foram incorporados antes do merge.
Claude PR Review (Ikeh Akinyemi, LogRocket) segue o caminho oposto. Em vez de um sistema autônomo, Akinyemi construiu um pipeline de cinco agentes: qualificação, detecção de bugs, contexto via git blame, padrões de PRs anteriores e alinhamento entre código e comentários. Cada revisão passa por um limiar de confiança de 80 pontos. Subagentes de pontuação são projetados para refutar achados, não para confirmá-los.
O sistema capturou um bypass de autenticação com confiança 100. Um bloco catch silencioso pontuou 75 e foi filtrado. Custo: US$ 15-25 por revisão.
Um sistema aprende suas próprias regras. O outro segue regras que um humano escreveu.
O Espectro da Autonomia
O painel do BugBot oferece controle manual, mas o padrão é autônomo. Regras sobem e descem com base no comportamento agregado dos desenvolvedores. Se desenvolvedores suficientes em repositórios suficientes aceitam uma sugestão, ela vira padrão. Se rejeitam, desaparece.
Governança por consenso, medida em decisões de merge.
O pipeline de Akinyemi funciona de outro modo. O arquivo CLAUDE.md define o que significa “correto” para o time dele. Os agentes aplicam essas definições. Nada sobe ou desce sem que um humano edite a configuração. Nas palavras dele: “A configuração importa tanto quanto a ferramenta. Um CLAUDE.md que de fato reflete as regras de correção do seu time… é o que separa sinal de ruído.”
As duas abordagens funcionam. Nenhuma responde à pergunta mais difícil: quem decide o que é “correto” quando a ferramenta é mais competente que a maioria dos revisores?
O Problema da Medição
Cobrimos o paradoxo do benchmark em fevereiro: todo fornecedor vence seu próprio teste. Os novos dados do BugBot acrescentam uma complicação.
A metodologia usa um LLM para julgar se comentários de IA foram incorporados. IA avaliando IA. A equipe do Cursor reconhece a limitação: apenas repositórios públicos, que podem não refletir bases de código corporativas. O LLM como juiz introduz circularidade. Um modelo treinado em dados semelhantes avalia a saída de outro modelo sobre esses mesmos dados.
Isso não invalida os resultados. Uma taxa de resolução de 78%, mesmo medida de forma imperfeita, é um sinal real. Desenvolvedores estão aceitando a maioria do que o BugBot sugere. Mas “desenvolvedores aceitaram” e “foi a decisão certa” são afirmações diferentes.
Já vimos isso antes. O estudo METR mostrou que desenvolvedores percebiam IA como 20% mais rápida quando na verdade eram 19% mais lentos. Aceitação não é precisão.
A Questão do Custo
O pipeline de Akinyemi custa US$ 15-25 por revisão. Em escala, isso soma rápido. Um time que faz merge de 50 PRs por dia gasta entre US$ 750 e US$ 1.250 diários só com revisão.
O custo do BugBot está embutido na assinatura do Cursor. Isso o torna mais barato por revisão, mas remove o preço como sinal de qualidade. Quando revisão é gratuita, não existe pressão econômica para reduzir falsos positivos. A única pressão é a irritação dos desenvolvedores, que é mais difícil de medir que uma linha no orçamento.
A economia empurra na direção do modelo do BugBot: autônomo, empacotado, alto volume. A questão da governança empurra na direção do modelo de Akinyemi: deliberado, configurável, caro.
Como argumentamos em Você não está matando o code review, a pergunta nunca foi sobre a ferramenta. É sobre quem é dono do padrão que a ferramenta aplica.
O que 44 Mil Regras Realmente Significa
Cada uma dessas 44 mil regras aprendidas representa uma decisão sobre qualidade de código tomada sem processo formal de revisão. Nenhum comitê de arquitetura as aprovou. Nenhum gerente de engenharia assinou embaixo. Elas emergiram do comportamento agregado de desenvolvedores interagindo com sugestões.
Algumas dessas regras provavelmente são excelentes. Outras codificam as preferências dos contribuidores mais ativos ou mais barulhentos. Algumas podem refletir os vieses dos repositórios onde o BugBot recebe mais tráfego.
Não é um defeito. É uma decisão de design. E é a decisão de design que mais importa, porque determina quem controla o padrão. Cursor escolheu consenso emergente. Akinyemi escolheu configuração explícita. A maioria dos times não fez essa escolha de forma consciente. Adotou uma ferramenta e herdou seu modelo de governança por padrão.
A Pergunta Real para Líderes de Engenharia
As ferramentas estão melhorando. Isso não está em disputa. A questão é organizacional.
Quando o BugBot auto-promove uma regra que conflita com as decisões de arquitetura do seu time, quem percebe? Quando um limiar de confiança filtra um bug real porque pontuou 75 em vez de 80, quem ajusta o limiar? Quando 44 mil regras se acumulam ao longo de meses, quem as audita para verificar consistência com os padrões reais de engenharia?
Três perguntas que todo time deveria responder antes de adotar revisão de código com IA:
1. Quem escreve as regras? Se a resposta é “a ferramenta aprende sozinha”, você delegou uma decisão de governança a uma função de otimização. Pode estar correto. Mas faça disso uma escolha consciente.
2. Quem revisa as regras? O painel do BugBot existe. Quantos times de fato o usam? O padrão é autônomo. Padrões se tornam permanentes.
3. O que acontece quando a ferramenta erra em escala? Uma regra ruim que se auto-promove em 110 mil repositórios afeta mais bases de código do que qualquer decisão de engenharia individual jamais tomada por um humano.
Essas não são perguntas técnicas. São organizacionais. As ferramentas vão continuar melhorando. Os 78% vão virar 85%, depois 90%. A questão de quem governa o governador só fica mais difícil à medida que as ferramentas ficam melhores.
Fontes
- Zhao, M. “BugBot Self-Improves.” Cursor Blog, abril 2026.
- Akinyemi, I. “Using Claude Code for Automated PR Reviews.” LogRocket Blog, abril 2026.
Victorino Group ajuda times de engenharia a construir estruturas de governança para desenvolvimento assistido por IA, antes que as ferramentas tomem as decisões por eles: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa