Code review com IA: o que o robô revisa e o arquivo que ele não lê

Durante anos, code review foi uma conversa entre pessoas: alguém abre um pull request, um colega lê, comenta, pede ajuste e aprova. Com a IA escrevendo boa parte do código, essa conversa ganhou um terceiro participante, que lê em segundos o que um colega levaria uma tarde para ler.

Em setembro de 2026, esse participante ganhou poder de voto: no GitHub, a aprovação do Copilot passou a poder contar para liberar o merge. Este guia explica o que é code review, o que muda com a IA, o que o revisor automático deixa de ler por regra e como decidir, arquivo por arquivo, quando a aprovação dele pode valer.

O que é code review?

Code review, ou revisão de código, é a etapa em que uma alteração é lida por outra pessoa antes de entrar no código principal do produto. Nas equipes que usam Git, ela acontece no pull request: a pessoa propõe a mudança, o revisor comenta e só depois da aprovação a alteração é mesclada.

A revisão tem três funções. A primeira é achar defeito antes que ele chegue ao cliente. A segunda é manter o código legível para quem vier depois. A terceira, a mais esquecida, é controle: garantir que nenhuma mudança entre em produção sem que uma segunda pessoa tenha visto. É essa terceira função que a aprovação da IA coloca em discussão.

Por isso muitos repositórios têm uma regra de proteção que exige um número mínimo de aprovações antes do merge. Ela não mede qualidade; mede que alguém, além do autor, assumiu a responsabilidade pela mudança.

O que muda quando a IA entra na revisão de código?

A IA muda a velocidade e a cobertura da primeira leitura. Ela não se cansa no décimo arquivo, não pula o teste porque está com pressa e comenta a mudança minutos depois de o pull request ser aberto. Para erro de lógica evidente, variável esquecida, tratamento de erro ausente ou trecho duplicado, ela é uma primeira passada muito boa.

O que a IA não muda é a responsabilidade. Ela não conhece o contrato com o cliente, não sabe que aquele endpoint é usado por um parceiro que não pode ser quebrado e não responde quando o incidente acontece. E, como mostra a documentação do próprio GitHub, há arquivos inteiros que ela nem abre.

Há ainda um efeito de volume. Quando a IA também escreve o código, o número de pull requests cresce, e a revisão humana vira o gargalo. A tentação é deixar a IA revisar o que a IA escreveu e seguir em frente. Já mostramos por que isso cobra a conta depois em a IA na programação produz mais e quebra mais.

Qual a diferença entre a revisão humana e a revisão da IA?

As duas não competem: cada uma enxerga um tipo de problema. A tabela resume o que a Alliance observa na prática ao montar a esteira de revisão de projetos de software:

Comparativo elaborado pela Alliance Comunicação com base na documentação do GitHub e na prática de revisão de código em projetos de software.

A linha mais importante da tabela é a quarta. Uma aprovação é, antes de tudo, alguém assumindo a mudança. Quando quem aprova é um modelo, a responsabilidade volta para quem configurou a regra que deixou a aprovação dele valer.

O que mudou no GitHub em setembro de 2026?

Até agosto, os comentários do Copilot num pull request eram sugestões: úteis, mas sem efeito na regra de aprovações. Em 1º de setembro, o GitHub anunciou que o Copilot code review pode aprovar pull requests, e que essa aprovação pode satisfazer a exigência de aprovações do repositório.

A documentação do Copilot code review é explícita: com as aprovações ativadas, o Copilot pode enviar uma revisão que satisfaz a regra de aprovações obrigatórias do mesmo jeito que a aprovação de um colega. Sem essa configuração, as revisões dele não contam.

Há dois detalhes que ajudam o gestor. Primeiro, toda revisão traz uma avaliação de prontidão no comentário de resumo, mas essa avaliação sozinha não conta para o merge: ela serve para a pessoa decidir. Segundo, a liberação por caminho de arquivo é o que permite uma política fina, em que a IA aprova a pasta de documentação e nunca a de autenticação.

O que o revisor de IA não lê?

Aqui está o ponto que quase ninguém comenta. O GitHub mantém uma lista de arquivos excluídos da revisão do Copilot. Se um desses arquivos estiver no pull request, o Copilot não o considera ao revisar. A página diz que são arquivos de gerenciamento de dependências, logs, SVG e locais típicos de código de terceiros ou gerado automaticamente.

A exclusão tem lógica. Um lockfile tem milhares de linhas geradas por máquina, e um modelo de linguagem lendo hashes de pacote gastaria crédito sem achar nada útil. O problema não é a regra, é o que ela deixa sem dono: a troca de uma versão de dependência pode passar num PR em que a IA aprovou todo o resto.

O padrão de casos em que isso pesa é previsível: atualização de biblioteca, pacote novo adicionado num PR que também mexe em código, mudança de configuração de build que altera o que vai para produção. Em todos, o arquivo que importa é justamente um dos que o robô pula.

Por que os arquivos que o robô pula são os de maior risco?

Porque dependência é código de terceiro entrando no seu produto, e terceiro virou o principal vetor de incidente. Uma biblioteca comprometida, uma versão com falha conhecida ou um pacote com nome parecido com o original entram pelo lockfile, não pelo arquivo que a pessoa escreveu.

Junte as duas informações: quase metade das violações do DBIR 2026 da Verizon envolve terceiros, e os arquivos que registram quais terceiros entram no seu software estão fora da revisão automática. Se a aprovação da IA contar para o merge num caminho que inclui esses arquivos, a empresa terá automatizado a parte do processo que menos precisava de pressa.

O revisor de IA lê o código que você escreveu. O risco que mais cresce mora no código que você só baixou.

Isso não é argumento contra a IA na revisão. É argumento para separar o que ela aprova do que ela só comenta, e para dar a cada arquivo excluído um revisor humano e uma ferramenta própria.

Como montar o code review com IA em duas camadas?

O desenho que a Alliance recomenda para empresas médias tem duas camadas: a IA faz a primeira passada em todo pull request, e uma pessoa aprova tudo o que é crítico. A IA só aprova sozinha onde um erro é barato e reversível.

1. Ligue a revisão automática em todo PR

A primeira camada vale para tudo. A IA comenta cedo, e o autor corrige o óbvio antes de ocupar o tempo de um colega. Isso sozinho já encurta a fila de revisão humana, porque o revisor recebe um PR mais limpo.

2. Escreva as instruções do repositório

O Copilot lê instruções personalizadas do repositório (no arquivo .github/copilot-instructions.md). Use para dizer o que importa no seu código: padrões de tratamento de erro, bibliotecas proibidas, como os dados pessoais devem ser registrados. Instrução curta e específica rende mais do que um manual inteiro, e pesa menos no consumo.

3. Libere a aprovação por caminho, nunca no repositório inteiro

Se for ligar a aprovação da IA, faça por pasta. Documentação, textos de interface e testes são bons candidatos. Autenticação, pagamentos, infraestrutura e qualquer pasta com dados pessoais ficam fora, sempre com aprovação humana.

4. Dê dono humano aos arquivos excluídos

Use o recurso de responsáveis por código (o arquivo CODEOWNERS do GitHub) para que lockfiles, arquivos de build e configuração exijam aprovação de uma pessoa definida. Assim, um PR que mexe em dependência não fecha só com a aprovação da IA, mesmo que ela tenha aprovado o resto.

5. Coloque uma varredura de dependências no pipeline

O que a IA de revisão pula, uma ferramenta de análise de dependências lê: ela compara as versões do lockfile com bases de vulnerabilidades conhecidas e alerta no próprio PR. É barato, automático e cobre exatamente o ponto cego. Para o caso específico de aplicativos gerados por IA com banco exposto, veja a tabela que o gerador de SaaS deixa aberta.

Quando a aprovação da IA pode contar para o merge?

A regra prática é perguntar duas coisas sobre cada pasta: o revisor de IA lê esse arquivo? E quanto custa um erro ali? Se ele não lê, a aprovação dele não pode valer. Se lê e o erro é barato, pode. A tabela mostra como isso fica num repositório típico:

Política sugerida pela Alliance Comunicação; a coluna “A IA lê?” segue a lista de arquivos excluídos da documentação do GitHub (consultada em 01/10/2026).

A coluna da infraestrutura diz “parcialmente” porque arquivos de infraestrutura como código podem ser lidos, mas parte da configuração de build está na lista de exclusão. Na dúvida, trate como não lido.

A documentação do Copilot code review traz a frase que deveria estar no acordo de trabalho de todo time: o Copilot não tem garantia de identificar todos os problemas de um pull request, às vezes erra, e o feedback dele deve ser complementado por revisão humana. Uma política de aprovação honesta parte dessa frase.

Quanto custa uma revisão do Copilot?

Cada revisão consome créditos de IA, e o valor varia com o esforço escolhido e o tamanho do PR.

Para quem revisa dezenas de PRs por dia, a diferença entre os dois esforços pesa. Uma política simples: “Lite” como padrão e “Balanced” só nos caminhos críticos, onde a leitura mais cuidadosa compensa. PR pequeno também é economia, e não só de crédito: é mais fácil de revisar por qualquer um.

Como os créditos saem do mesmo pool usado pelo chat e pelo agente, o custo da revisão precisa entrar no orçamento do Copilot da empresa. Os planos, o assento e a cobrança por uso estão detalhados em o que o assento do GitHub Copilot cobre e o que consome créditos.

Quais os erros mais comuns no code review com IA?

• Ligar a aprovação no repositório inteiro. É o atalho que transforma a IA em revisora de autenticação e de dependência, inclusive dos arquivos que ela não lê.
• Tratar o “aprovado” da IA como “revisado”. A aprovação dela diz que não achou problema no que leu, não que o PR está seguro.
• Deixar a IA revisar o código que a própria IA escreveu, sem pessoa no meio. Os dois erram no mesmo tipo de lugar.
• Misturar atualização de dependência com mudança de código no mesmo PR. O lockfile some no meio do diff e ninguém olha.
• Escrever instruções do repositório genéricas e longas. Aumentam o consumo e não mudam o resultado.
• Não medir. Sem saber quantos problemas a IA apontou e quantos chegaram à produção, a empresa não sabe se a revisão automática funciona.

Como medir se a revisão com IA está funcionando?

1. Tempo até a primeira revisão: deve cair logo nas primeiras semanas, porque a IA comenta em minutos.
2. Tempo até o merge: se não cair, o gargalo continua na aprovação humana, e a solução é PR menor, não mais IA.
3. Comentários da IA aceitos: a fração de sugestões que o autor de fato aplica. Muito baixa indica ruído; reveja as instruções.
4. Defeitos que escaparam: incidentes e bugs de produção cuja causa estava num PR aprovado. É a métrica que diz se a política de aprovação está certa.
5. PRs com dependência sem aprovação humana: deve ser zero. Qualquer outro número é falha de configuração.
6. Custo por PR: créditos consumidos divididos pelo número de revisões, separado por esforço.

Meça antes de ligar a aprovação da IA em qualquer caminho. Um mês de dados com a IA só comentando mostra onde ela acerta e onde gera ruído, e essa é a melhor base para decidir onde deixar o voto dela contar.

Por onde começar hoje?

1. Ligue a revisão automática da IA em todos os PRs, sem aprovação, e deixe rodar por um mês.
2. Escreva instruções curtas do repositório com as três regras que mais importam no seu código.
3. Configure CODEOWNERS para lockfiles, arquivos de build, infraestrutura e autenticação.
4. Ative uma varredura de dependências que comente no próprio PR.
5. Com os dados do mês, libere a aprovação da IA só nas pastas de baixo risco e revise a decisão a cada trimestre.

Se a dúvida for onde a IA renderia mais na sua operação, não só no código, o diagnóstico gratuito de marketing mapeia a maturidade por área e mostra o gargalo real. E quando o passo for montar uma esteira de desenvolvimento com IA, revisão em duas camadas e governança, é disso que trata o desenvolvimento assistido por IA da Alliance: a IA acelera a primeira leitura, e a empresa decide quem assina.