Code review com IA sem baixar a régua de qualidade

Colocar um LLM para revisar pull requests é uma das primeiras ideias que surgem quando um time adota IA. Também é uma das mais fáceis de fazer errado, porque parte de um mal-entendido sobre o que o code review serve.

Code review não existe só para achar bug

O estudo mais completo sobre o assunto, feito no Google, mostra que a revisão de código sustenta quatro coisas ao mesmo tempo: encontrar defeitos, manter consistência de estilo e arquitetura, espalhar conhecimento pelo time e criar registro de quem conhece cada parte do sistema.

Um LLM contribui bem para a primeira e a segunda. Ele não contribui em nada para a terceira e a quarta. Se você automatizar a revisão inteira, troca defeito encontrado por conhecimento não distribuído, e a conta chega alguns meses depois, quando só uma pessoa entende o módulo crítico.

Onde a revisão automática paga

Três categorias rendem de imediato:

• Checagens mecânicas com contexto. Nome inconsistente com a convenção do repositório, tratamento de erro faltando num caminho específico, log que vaza dado sensível. O LLM lê o diff e o arquivo em volta, coisa que o linter não faz.
• Primeira passada em PR grande. Não para aprovar, mas para o revisor humano chegar já sabendo onde olhar.
• Explicação de código alheio. Reduz o custo de revisar uma área que você não conhece, que é exatamente onde a revisão humana costuma ser superficial.

Onde ela atrapalha

O modo de falha mais comum não é o falso positivo, é o volume. Um bot que comenta quinze observações de baixo valor em cada PR treina o time a fechar os comentários sem ler. A partir daí, o comentário que importava também é ignorado.

O segundo modo de falha é a falsa sensação de cobertura. "O bot revisou" vira justificativa para o humano revisar menos, sem que ninguém tenha decidido isso explicitamente.

O dado que deveria mudar a sua configuração

Um experimento controlado publicado na CCS 2023 comparou pessoas escrevendo código com e sem assistente de IA em tarefas relacionadas a segurança. Dois resultados juntos:

1. Quem usou o assistente escreveu código significativamente menos seguro na maioria das tarefas.
2. Quem usou o assistente ficou mais confiante de que o próprio código era seguro.

A combinação é o problema. Não é só que a IA introduz risco, é que ela reduz a desconfiança de quem deveria revisar. Isso significa que o quality gate de segurança precisa ficar mais rígido quando o time adota IA, não mais frouxo.

Desenhando o gate

Um desenho que funciona na prática separa três níveis, com autoridades diferentes:

Nível 1, bloqueante e determinístico. Lint, tipagem, testes, SAST, verificação de dependência. Nada de LLM aqui: precisa ser reproduzível e não pode variar entre execuções.

Nível 2, LLM como revisor consultivo. Comenta, não bloqueia, e com orçamento explícito: no máximo três a cinco observações por PR, ordenadas por severidade. O limite é a parte importante. Ele força priorização e preserva a atenção do time.

Nível 3, humano com escopo declarado. O revisor aprova mirando em corretude de domínio, decisão de arquitetura e legibilidade para quem vier depois. Explicitar que ele não precisa caçar vírgula é o que torna o nível 2 útil em vez de redundante.

Para requisitos de segurança, ancore o nível 1 e o nível 3 num padrão verificável em vez de bom senso. O ASVS da OWASP serve bem para isso porque é organizado em níveis, o que permite exigir mais de um endpoint de pagamento que de uma tela interna.

Meça o gate, não o bot

A métrica que importa não é quantos comentários o bot gerou, nem quantos foram aceitos. É se o gate está segurando defeito antes da produção sem travar a entrega. Duas séries bastam: taxa de falha em mudanças e tempo de revisão. Se a taxa de falha não caiu e o tempo de revisão subiu, o gate está cobrando pedágio sem entregar segurança.

Vale também acompanhar a proporção de código reescrito logo depois de entrar. Relatórios de análise de repositórios vêm apontando aumento de duplicação e queda de refatoração à medida que assistentes se popularizam, e esse é um sintoma que aparece semanas antes de virar incidente.

O que isso significa para o seu time

Comece consultivo e limitado: LLM comentando no máximo cinco pontos por PR, sem poder de bloqueio, por um mês. Compare taxa de falha em mudanças antes e depois. Só promova uma checagem para bloqueante quando ela tiver histórico de acertar.

E mantenha revisão humana obrigatória em código gerado por IA, especialmente em caminho de autenticação, autorização e manipulação de dado pessoal. A evidência disponível diz que é justamente ali que a confiança sobe mais do que a qualidade.