Ao testar revisores de PRs por IA, é essencial não apenas avaliar o desempenho em termos de precisão e recall, mas também entender como eles lidam com situações reais. O ReviewBench, um conjunto de 219 PRs públicos em 19 linguagens, é um ponto de partida útil, mas não substitui o teste em seu próprio projeto. Separe PRs antigos cujo desfecho a equipe conhece, misture mudanças com bugs já corrigidos e mudanças sem defeito conhecido, e inclua uma alteração de interface, outra de regra de negócio e uma de maior risco. Antes de rodar qualquer revisor, confira o que ele recebe: diff, arquivos vizinhos, testes e instruções do projeto. Não envie código ou dados sensíveis a um serviço externo sem verificar as permissões e a política da equipe. Depois, peça a revisão sem entregar a lista dos bugs conhecidos para evitar ensinar a resposta ao sistema. Teste também o que o time já usa: lint, testes e revisão humana. Se a IA repetir o que o lint já detecta, ela pode aumentar o trabalho. Se apontar um caso de borda que ninguém tinha notado, investigue como chegou ali e se esse tipo de achado se repete em PRs semelhantes. Precisão e recall ajudam a organizar a conversa, mas tempo de triagem e gravidade das omissões também entram na conta. Decida onde vale usar, não apenas se vai usar. Por exemplo, um PR de texto ou ajuste visual pequeno talvez não justifique mais uma etapa obrigatória. Já uma mudança em cobrança, permissões ou comportamento entre módulos pode merecer uma segunda leitura, desde que alguém confira os achados. Se o revisor falhar justamente nos defeitos graves do ensaio, ajuste o escopo ou mantenha-o como apoio; não o transforme num bloqueio automático de merge só porque foi bem em um benchmark público. Dá para começar com um único PR antigo. Esconda a correção, rode a revisão em condições seguras e anote acertos, omissões e minutos de triagem.
