Revisão de código com IA: o que ela pega e o que ela deixa passar

Colocar IA para revisar pull request é uma das aplicações que mais valem a pena — e uma das mais mal compreendidas. Times adotam esperando um revisor sênior automático, recebem uma enxurrada de comentário genérico, desligam em duas semanas e concluem que não funciona.

Funciona. Mas para uma classe específica de problema. O valor está em saber exatamente qual, para você não pedir o que ela não pode dar nem ignorar o que ela faz bem.

O que a IA pega muito bem

Erro mecânico e desatenção

É onde ela é imbatível, porque não cansa e não pula linha. Variável declarada e não usada, await esquecido numa chamada assíncrona, comparação com == onde deveria ser estrita, condição invertida, retorno faltando num ramo do if. São erros que um humano também pegaria — se estivesse atento no PR número sete do dia, o que raramente é o caso.

Caso-limite não tratado

Este é o de maior retorno. Ela é excelente em perguntar "e se a lista vier vazia?", "e se esse campo for nulo?", "e se a data estiver no fim do mês?". São perguntas que o autor não faz porque está imerso no caminho feliz que acabou de construir.

O melhor uso da IA em revisão não é apontar erro. É fazer a pergunta que o autor não faria — porque quem escreveu já sabe demais para enxergar a lacuna.

Inconsistência com o resto do projeto

Se você der contexto suficiente, ela nota que aquela função duplica algo que já existe em outro módulo, ou que o tratamento de erro ali difere do padrão usado nos outros arquivos. Humanos deixam isso passar o tempo todo, porque ninguém conhece a base inteira de cor.

Segurança na camada óbvia

Concatenação de string em SQL, entrada não validada indo direto para o banco, segredo em texto puro, log imprimindo dado sensível. São achados reais e ela pega bem. Não confunda com auditoria de segurança — a camada difícil ela não vê —, mas essa primeira camada já evita a maioria dos incidentes bobos.

O que ela deixa passar

Erro de regra de negócio

Este é o mais importante de entender. Se o código calcula comissão de 5% e a regra da empresa é 7%, a IA vai aprovar tranquilamente. O código está impecável: tipado, testado, legível — e errado. Ela não tem acesso à regra, e uma revisão que só olha o código nunca vai pegar isso.

É por isso que revisão automática não substitui revisão humana: a parte que mais custa quando passa é justamente a que ela não enxerga.

Decisão de arquitetura ruim

Ela revisa o diff, não o desenho. Se a abordagem inteira é equivocada — o cache deveria estar em outra camada, essa responsabilidade não pertence a esse módulo, isso vai criar acoplamento que dói daqui a seis meses — ela normalmente comenta a implementação e não questiona a premissa. Ela otimiza o que está na frente dela.

O que não está no diff

Um PR que altera o retorno de uma função pode quebrar três lugares que chamam essa função e não aparecem na mudança. Sem a base inteira em contexto, a IA não tem como ver. Um colega que conhece o sistema vê imediatamente — é literalmente a primeira coisa em que ele pensa.

Performance em escala real

Ela identifica o padrão clássico de consulta dentro de laço, o que já ajuda. Mas não sabe que aquela tabela tem 40 milhões de linhas, que o índice não cobre a coluna do filtro, ou que essa rota é chamada mil vezes por minuto. Sem os números do seu sistema, a análise de performance é genérica.

O que ela inventa (e como não cair)

Existe um comportamento que sabota a adoção mais do que qualquer limitação: a IA quase sempre acha alguma coisa. Peça uma revisão de um código perfeito e ela vai sugerir renomear uma variável, extrair uma função de três linhas ou adicionar um comentário desnecessário. Ela foi otimizada para ser útil, e "não achei nada" não parece útil.

O efeito prático é ruído — e ruído mata revisão automática, porque o time aprende a ignorar os comentários em bloco. Aí o achado importante, quando aparece, é ignorado junto.

Duas correções que funcionam bem:

1. Peça severidade e permita silêncio. "Classifique cada achado como bug, risco ou estilo. Se não houver nada de bug ou risco, responda apenas 'nada crítico'. Não invente sugestão de estilo para preencher."
2. Limite o escopo. "Comente apenas correção, segurança e casos-limite. Ignore formatação, nomenclatura e preferência de estilo — isso o linter já resolve."

Essa segunda regra é a que mais melhora a experiência. Estilo é trabalho de ferramenta determinística; gastar a atenção da revisão com isso é desperdiçar o que ela tem de melhor.

Como integrar sem irritar o time

• A IA comenta primeiro, o humano depois. Ela roda ao abrir o PR e limpa o trivial. O revisor humano chega para o que importa: regra de negócio, arquitetura, impacto. Assim ela economiza o tempo do colega em vez de disputar com ele.
• Comentário de IA não bloqueia merge. Se travar, vira burocracia e o time cria jeito de contornar. Sugestão é sugestão.
• Dê a ela as regras do projeto. As mesmas convenções que você usaria para gerar código valem para revisar. Sem isso, ela revisa contra o padrão médio da internet, não contra o seu.
• Meça a taxa de acerto. Se menos de um em cada cinco comentários gera mudança real, o ajuste está errado — aperte o escopo até a proporção melhorar.

O uso que eu mais recomendo: revisar o próprio código antes de abrir o PR

De todas as formas de usar IA em revisão, essa é a de melhor retorno e a menos adotada. Antes de pedir review a um colega, passe o seu próprio diff e peça a leitura crítica.

Três motivos. O erro é corrigido antes de custar o tempo de outra pessoa. Você chega no PR já tendo pensado nos casos-limite, e a discussão sobe de nível. E, principalmente, você lê o próprio código com olhos de revisor — que é o hábito que mais melhora quem programa, com ou sem IA.

Conclusão

Revisão com IA é um bom primeiro filtro: pega desatenção, caso-limite, inconsistência e a camada óbvia de segurança, sem cansar e sem ter dia ruim. Não é revisor sênior: não conhece a regra de negócio, não questiona arquitetura e não enxerga o que está fora do diff.

Use para limpar o trivial e liberar a atenção humana para o que exige contexto. Quem trata a aprovação dela como suficiente está automatizando a parte fácil da revisão e abandonando a difícil — que é exatamente a que evita o incidente.