Revisão de código com IA em pull requests: o que delegar e o que não

Revisão de código com IA em pull requests: o que delegar e o que não

Revisão de código com IA funciona melhor como uma primeira leitura rápida do pull request: ela aponta padrões fora do combinado, bugs óbvios, tratamento de erro ausente e testes que faltam antes de uma pessoa gastar tempo. A decisão de aprovar, o contexto de negócio, a arquitetura e o risco de segurança continuam com o revisor humano. Para usar bem, defina o que a IA comenta, o que ela nunca decide e quem responde pelo merge.

Principais pontos

• A IA é boa em leitura repetitiva e atenta a detalhes: padrões, nomes, erros comuns, casos de borda esquecidos e testes ausentes.
• A IA não conhece sozinha a intenção do negócio, o histórico das decisões nem o impacto de uma mudança em outros sistemas. Isso é papel do revisor humano.
• O comentário da IA é uma sugestão, nunca uma aprovação. A aprovação formal do PR deve ser sempre de uma pessoa.
• O diff é entrada não confiável: segredos, dados pessoais e instruções escondidas em código ou comentários exigem limites claros.
• Comece com um repositório e um tipo de PR, meça se os comentários são úteis e só então expanda.

O que a IA revisa bem em um pull request?

Uma revisão humana cansa quando o PR é grande e cheio de detalhes mecânicos. É exatamente nesse ponto que a IA ajuda, porque não perde atenção na centésima linha. As categorias abaixo costumam render melhor.

• Padrões e convenções: nomes inconsistentes, funções longas demais, código duplicado, importações não usadas, estilo diferente do restante do projeto.
• Bugs óbvios: comparação errada, variável usada antes de ser definida, condição que nunca é verdadeira, recurso aberto e não fechado, erro engolido sem registro.
• Casos de borda: lista vazia, valor nulo, texto com acento, data em fuso diferente, divisão por zero, entrada fora do esperado.
• Testes faltando: caminho novo sem teste, ramo de erro sem cobertura, teste que não verifica nada de fato.
• Legibilidade: descrição do PR que não bate com o diff, comentário desatualizado, função que faz coisas demais.
• Sinais de segurança básicos: segredo escrito no código, consulta montada por concatenação de texto, log que imprime dado sensível.

Nesses casos o ganho é de tempo e consistência. O revisor humano chega ao PR com o ruído já removido e pode olhar o que importa.

Há um limite importante: a IA também erra. Ela pode apontar um problema que não existe, sugerir uma mudança que quebra outro ponto ou deixar passar um defeito real. Por isso o texto que ela gera deve ser tratado como hipótese a verificar, não como fato.

O que continua com o revisor humano?

O que depende de contexto fora do diff não deve ser delegado. A pergunta útil é: este julgamento exige saber algo que não está no código? Se sim, é humano. Para uma visão mais geral dessa fronteira, vale ler o que não delegar para inteligência artificial na empresa.

Ficam com a pessoa:

• Intenção e regra de negócio: a mudança resolve o problema certo? A regra implementada é a que o negócio combinou?
• Arquitetura e direção técnica: a solução cabe no desenho do sistema, cria dependência indesejada ou dívida que ninguém assumiu?
• Impacto em outros sistemas: contratos de API, filas, integrações, relatórios e rotinas que dependem do comportamento antigo.
• Risco e segurança de verdade: autorização, exposição de dados, fluxo de pagamento, migração de banco, qualquer coisa difícil de desfazer.
• Conformidade: tratamento de dados pessoais conforme a LGPD, retenção, finalidade e quem pode acessar. A IA pode sinalizar, mas a decisão é da empresa.
• Decisão de merge e de deploy: quem aprova responde pelo que entra em produção.

Uma regra simples ajuda: quanto mais difícil de reverter e mais perto de dinheiro, dados pessoais ou acesso, mais a revisão humana deve ser cuidadosa e independente do comentário da IA.

Como colocar a IA no fluxo de revisão, passo a passo

O desenho abaixo é uma proposta de implementação, não uma exigência de qualquer ferramenta. Ele funciona com assistentes integrados ao GitHub, GitLab ou Bitbucket e também com agentes próprios. Se você ainda está escolhendo a ferramenta, o artigo sobre Claude Code, Cursor ou GitHub Copilot ajuda a comparar.

• Passo um: escolha um repositório e um tipo de PR. Por exemplo, mudanças de backend em um serviço com testes razoáveis. Evite começar por código de pagamento ou de autenticação.
• Passo dois: escreva as regras da equipe em um documento curto que a IA possa ler: convenções, o que é proibido, o que sempre exige teste. Um arquivo de instruções do repositório cumpre esse papel, como explicado em como escrever um bom CLAUDE.md.
• Passo três: defina o escopo da IA. Ela comenta, resume e sugere. Ela não aprova, não faz merge e não altera a branch sem pedido explícito.
• Passo quatro: limite o acesso. Leitura do diff e dos arquivos necessários, sem acesso a segredos, produção ou bases com dados reais. Para ferramentas que rodam na máquina, veja segurança no Claude Code: permissões, sandbox e segredos.
• Passo cinco: peça um formato fixo de resposta: resumo do que mudou, riscos encontrados com arquivo e linha, testes sugeridos e dúvidas para o autor. Formato fixo facilita comparar e medir.
• Passo seis: o revisor humano lê o comentário da IA depois de ler o PR, não antes, para não ser conduzido por ele.
• Passo sete: registre o que aconteceu. Para cada comentário da IA, marque se foi útil, irrelevante ou errado. Esse registro é a base para ajustar as instruções.
• Passo oito: revise as regras depois de um período combinado e decida se expande, ajusta ou para.

Checklist de PR para autor e revisor

A IA rende mais quando o PR já chega bem preparado. O autor faz a primeira parte.

Checklist do autor antes de abrir o PR:

• O PR tem um único objetivo e a descrição explica o porquê, não só o quê.
• O tamanho é revisável. Se for grande, foi dividido ou há uma explicação de por que não dá.
• Há testes para o comportamento novo e para pelo menos um caso de erro.
• Nenhum segredo, chave, token ou dado real de cliente aparece no código, nos testes ou nos logs.
• A mudança de comportamento visível a outros sistemas está descrita.
• Existe plano de reversão quando a mudança é difícil de desfazer.

Checklist do revisor humano, depois da leitura da IA:

• A descrição bate com o que o código faz de fato.
• Os comentários da IA foram lidos e cada um foi aceito, descartado ou respondido.
• A regra de negócio implementada é a combinada, e não só uma que parece razoável.
• Autorização e acesso a dados estão corretos para cada papel de usuário.
• Dados pessoais só são usados para a finalidade prevista e não vão parar em log.
• Migrações, filas e integrações foram avaliadas quanto a ordem, repetição e falha parcial.
• Os testes realmente falhariam se o código estivesse errado.
• Se a IA não comentou nada, isso não foi tomado como prova de que o código está bom.

Cenário ilustrativo: uma regra de desconto em um PR

Cenário ilustrativo: uma equipe de e-commerce altera a função que calcula desconto para clientes recorrentes. O PR mexe em poucos arquivos e inclui um teste novo.

A IA comenta que o desconto é aplicado depois do frete em um ponto e antes em outro, que a função não trata carrinho vazio e que o teste novo só cobre o caso feliz. Os três apontamentos são verificáveis no código e economizam a primeira rodada de ajustes.

A IA não percebe que a área comercial combinou que o desconto nunca se acumula com um cupom de campanha. Essa regra está em uma conversa, não no repositório. O revisor humano, que participou da decisão, nota que o código permite o acúmulo e pede a correção. Também pergunta se relatórios financeiros que leem o valor final continuam coerentes.

O resultado combina as duas leituras: a IA cuidou do detalhe mecânico, a pessoa cuidou da intenção e do impacto. Nenhum dos dois substitui o outro.

Quais são os riscos de segurança e privacidade ao usar IA em PRs?

O conteúdo de um PR é entrada não confiável. Um comentário no código, um arquivo de documentação ou o texto de uma dependência podem conter instruções dirigidas ao modelo, como mandar ignorar regras ou aprovar. Isso é um caso de injeção de prompt, descrito pela OWASP, e vale tratar a saída da IA como sugestão que passa por validação humana.

Pontos de atenção práticos:

• Segredos: configure varredura de segredos no repositório e impeça que o assistente receba arquivos de ambiente ou credenciais.
• Dados pessoais: se o código ou os testes contêm dados reais, o envio a um serviço externo pode ter implicações na LGPD. Use dados fictícios nos testes e confirme com o jurídico ou o encarregado quais repositórios podem ser enviados.
• Permissões mínimas: a integração com o repositório deve poder ler e comentar, e nada além disso, sem permissão para fazer merge ou alterar regras de proteção da branch.
• Código proprietário: verifique nos termos do fornecedor como o conteúdo é retido e se é usado para treinamento. Essa é uma informação que deve vir da documentação oficial e do contrato, não de suposição.
• Rastreabilidade: guarde qual versão do modelo e quais instruções geraram cada comentário, para poder explicar uma revisão depois.

Para o aspecto contratual de quem é operador e controlador, o texto sobre operador e controlador na LGPD ajuda a organizar a conversa.

Como aplicar o método: mapear, limitar, pilotar, transferir

A mesma sequência usada em outros projetos de IA serve para revisão de código, sem exagero.

Mapear: descreva como a revisão acontece hoje. Quanto tempo um PR espera, quais comentários se repetem, onde os defeitos escapam. Esse é o ponto de partida para saber se algo melhorou.

Limitar: defina o que a IA lê, o que comenta e o que nunca faz. Sem aprovação automática, sem acesso a segredos, sem escrita na branch principal.

Pilotar: rode em um repositório, com registro dos comentários úteis e inúteis e uma métrica combinada de antemão, como tempo até a primeira revisão ou proporção de comentários aceitos. O texto sobre como medir um piloto de automação com IA detalha critérios de decisão.

Transferir: entregue à equipe as instruções, o registro e a decisão de expandir, ajustar ou parar. A operação passa a ser da equipe, com manutenção periódica das regras.

Esta é uma descrição do método, não uma promessa de resultado. O efeito depende da qualidade dos testes, do tamanho dos PRs e da disciplina do time.

Perguntas frequentes

A IA pode aprovar pull requests sozinha? Não é recomendável. Aprovar é assumir responsabilidade pelo que entra em produção, e isso exige contexto de negócio e julgamento de risco. Use a IA para comentar e resumir, e mantenha a aprovação com uma pessoa, especialmente em código de pagamento, acesso e dados pessoais.

A revisão por IA substitui o revisor humano em times pequenos? Ela reduz o trabalho mecânico, o que ajuda muito quando há poucas pessoas para revisar. Mas em time pequeno o risco de ponto cego é maior, então a leitura humana da intenção e do impacto continua necessária, ainda que mais curta.

Como saber se a revisão com IA está valendo a pena? Compare com a situação anterior usando uma métrica combinada de início e o registro de comentários úteis, irrelevantes e errados. Se muitos comentários são descartados, ajuste as instruções ou reduza o escopo. Se os defeitos continuam escapando nos mesmos pontos, o problema pode estar nos testes, não na revisão.

Posso enviar o código da empresa para uma ferramenta de IA? Depende do contrato do fornecedor, da sensibilidade do código e de haver dados pessoais nos repositórios. Leia a documentação oficial sobre retenção e uso de dados, remova segredos e dados reais e alinhe com o jurídico antes de ativar a integração em repositórios sensíveis.

Fontes

• OWASP: Top 10 for LLM Applications
• OWASP: prompt injection prevention
• Anthropic: Demystifying evals for AI agents