Antes de confiar na revisão de PRs por IA, teste os bugs que ela deixa passar
Imagine um PR antigo que corrigia uma tela de pagamento. Na época, passou despercebido um caso em que o usuário podia confirmar duas vezes a mesma operação. Você sabe qual era o defeito porque ele já foi resolvido. Se um revisor de IA olhar aquele PR e só sugerir trocar nomes de variáveis, você aprendeu algo útil sobre ele. Mas seria só o começo do teste, não um veredito sobre todos os PRs.
O ReviewBench, lançado pelo GitHub, oferece um ponto de partida mais amplo: um conjunto de 219 PRs públicos em 19 linguagens, com achados de referência e métricas como precisão e recall. Há também um subconjunto de 25 PRs para experimentação. Isso ajuda a comparar revisores sob condições definidas. Só não responde como um deles vai se sair no seu projeto, com suas regras de negócio, contexto privado e tempo limitado de quem lê os comentários.
Um ensaio pequeno no seu próprio projeto
Separe alguns PRs antigos cujo desfecho a equipe conhece. Misture mudanças com bugs já corrigidos e mudanças sem defeito conhecido. Se puder, inclua uma alteração de interface, outra de regra de negócio e uma de maior risco, como autorização. Não é preciso fingir que essa amostra representa toda a produção; ela serve para encontrar falhas óbvias antes de colocar a ferramenta no fluxo.
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. Assim você evita ensinar a resposta ao sistema que está tentando avaliar.
O exemplo da tela de pagamento acima é hipotético. Este roteiro também é uma proposta de teste, não o resultado de um ensaio que eu tenha executado.
Anote o que o comentário fez você fazer
Para cada PR, registre:
- quais defeitos relevantes o revisor apontou corretamente;
- quais defeitos conhecidos ele deixou passar, com a gravidade de cada um;
- quais comentários exigiram investigação e não ajudaram a decidir nada;
- quanto tempo uma pessoa gastou conferindo e respondendo à revisão.
Guarde o trecho do código e a justificativa da decisão. Um comentário fora da sua lista inicial pode revelar um bug novo; vale conferir antes de chamá-lo de falso positivo. Do outro lado, um alerta sobre estilo não compensa deixar passar uma falha de permissão. Olhar só a quantidade de comentários encontrados esconde essa diferença.
Compare o ensaio com o que o time já usa: lint, testes e revisão humana. Se a IA repetir o que o lint já detecta e ainda criar uma fila de comentários vagos, 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
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. Depois repita com casos diferentes. A pergunta que interessa não é quantos comentários a IA escreveu, mas se ela ajudou sua equipe a perceber algo importante antes de aprovar a mudança.