Antes de deixar a IA aprovar PRs, defina o escopo da revisão
O pull request altera um texto de ajuda e passa em todos os checks. O Copilot revisa o diff e registra uma aprovação. Parece um ótimo candidato para seguir sem gastar o tempo de outra pessoa.
Só que, no meio dos arquivos de documentação, entrou uma mudança pequena numa regra de permissão.
A aprovação continua verde, mas agora estamos diante de outra classe de risco. Pouco importa se a IA "confia" no próprio review. Precisamos saber se aquela aprovação tinha autorização para contar nesse trecho do repositório.
O Copilot code review agora pode emitir aprovações em pull requests. O recurso pode ser habilitado nos níveis de empresa, organização e repositório, além de permitir restrição por caminhos de arquivo. Quando um novo commit chega, a aprovação anterior é descartada.
Esses limites são úteis. Ainda assim, eles não montam uma política pelo time. Uma aprovação não faz merge por conta própria, não substitui as regras de proteção da branch e não prova que o código está correto. Ela é um sinal dentro de um fluxo maior.
Classifique o diff antes de confiar no parecer
Eu começaria com três faixas simples. A classificação não precisa ser perfeita no primeiro dia; precisa ser explícita o bastante para que duas pessoas cheguem a uma decisão parecida.
| Faixa | Exemplos | Peso da aprovação da IA |
|---|---|---|
| Baixo risco | documentação, exemplos isolados, ajustes de texto e arquivos gerados com origem verificável | pode contar se o diff permanecer dentro dos caminhos permitidos e os checks passarem |
| Médio risco | código de aplicação coberto por testes, mudança reversível e sem acesso a áreas sensíveis | serve como triagem; uma pessoa confirma impacto e intenção |
| Alto risco | autenticação, pagamentos, dados, infraestrutura, segredos, permissões e dependências críticas | não substitui a revisão do responsável humano |
Se um PR mistura faixas, ele assume a mais alta. Um ajuste de README com uma mudança em permissions.ts não é um PR de documentação.
A classificação por caminho ajuda porque é fácil de auditar, mas não enxerga todo impacto indireto. Uma alteração num utilitário aparentemente comum pode afetar autenticação ou cobrança. Por isso, o mapa de risco deve combinar diretórios, donos de código e dependências conhecidas, em vez de depender apenas do nome do arquivo.
Começar por documentação talvez pareça tímido. Para um piloto, é uma vantagem: o time aprende onde a revisão automática economiza tempo sem transformar cada erro de classificação em incidente.
Faça os controles se complementarem
Nenhum controle isolado resolve o problema. O fluxo fica mais confiável quando cada camada verifica uma coisa diferente:
- Restrinja os caminhos nos quais a aprovação da IA pode ter peso.
- Mantenha checks obrigatórios para propriedades determinísticas, como testes, tipos, lint e políticas de dependência.
- Use CODEOWNERS para preservar uma pessoa ou equipe responsável pelas áreas sensíveis.
- Vincule cada decisão ao commit que foi realmente analisado.
- Bloqueie o merge quando surgir um arquivo fora do escopo ou faltar alguma evidência.
Um check verde não confirma intenção de produto. CODEOWNERS não garante que o responsável tenha tempo para revisar tudo. O escopo por caminho não detecta sozinho efeitos indiretos. As limitações continuam existindo, mas ficam visíveis e podem ser tratadas no fluxo.
Uma política inicial poderia ser descrita assim, em linguagem de equipe, antes mesmo de virar configuração:
A aprovação da IA pode contar quando:
- todos os arquivos estão em docs/ ou examples/;
- o commit aprovado ainda é o HEAD do pull request;
- testes e verificações obrigatórias passaram;
- nenhuma dependência ou permissão foi alterada.
A revisão humana é obrigatória quando:
- o diff toca auth/, billing/, infra/ ou permissions/;
- existe um arquivo sem classificação;
- um novo commit invalida a aprovação anterior;
- o impacto não pode ser conferido por um check determinístico.
Essa lista não é uma sintaxe do GitHub. É o contrato que o time deve conseguir revisar antes de configurar a ferramenta. Se ninguém consegue explicar a regra sem abrir cinco telas administrativas, a operação já começou opaca.
Também vale tratar políticas, retenção de dados, esforço de review e cobrança como parte da adoção. O agente não vive apenas no editor. Ele ocupa superfícies do GitHub, usa configurações organizacionais e pode criar custo ou guardar contexto conforme regras que mudam. A pessoa responsável pela automação precisa acompanhar essas decisões como acompanha qualquer integração de produção.
A interface deve mostrar por que a aprovação ainda vale
Um selo verde sozinho economiza espaço e esconde contexto. Para decidir rápido sem decidir no escuro, a tela deveria responder a pontos bem concretos:
- qual commit foi avaliado;
- quais arquivos estavam dentro do escopo permitido;
- quais arquivos exigem revisão humana;
- quais checks foram executados e quais ainda estão pendentes;
- por que a aprovação foi invalidada ou escalada;
- quem continua responsável pela decisão final.
A prioridade visual deveria estar nas exceções. Se 18 arquivos estão cobertos e um saiu do escopo, esse único arquivo merece aparecer primeiro. Obrigar o revisor a procurar a exceção numa lista longa anula boa parte do ganho da automação.
Para quem está construindo uma superfície própria de revisão agentiva, os recursos de Generative UI ajudam a comparar padrões de catálogo confiável, aprovação humana, estado e renderização controlada. Eles servem como referência de implementação; a política do repositório ainda precisa ser definida pela equipe.
Também evitaria um "índice de confiança" genérico no centro da tela. Uma nota alta pode indicar que o modelo achou o diff fácil de analisar, mas não mede o custo do erro. Uma mudança de texto com baixa confiança pode ser inofensiva. Uma alteração de permissão com parecer confiante continua sensível.
Mostre evidência e risco. Deixe a confiança como dado auxiliar, não como autorização.
Rode um piloto pequeno por duas semanas
Escolha um repositório com fluxo conhecido e poucos caminhos de baixo risco. Durante duas semanas, registre pelo menos:
- aprovações que o time aceitou sem alteração;
- aprovações descartadas após um novo commit;
- PRs escalados por arquivo fora do escopo;
- casos em que os checks passaram, mas a intenção estava errada;
- retrabalho ou reversões após o merge.
Não use apenas "quantos PRs foram aprovados" como métrica. Esse número cresce quando a automação fica mais permissiva, mesmo que a qualidade piore. Tempo poupado interessa, mas precisa vir acompanhado do custo de revisão posterior e dos erros que escaparam.
No fim do piloto, revise os falsos positivos. Se a IA aprovou algo que uma pessoa bloqueou, descubra se faltou contexto, check, regra de caminho ou dono. Ajuste o controle correspondente antes de ampliar o escopo.
Eu só abriria uma nova faixa quando os erros da faixa atual estivessem fáceis de detectar e baratos de corrigir. Ampliar porque "quase sempre funciona" é justamente como uma conveniência vira dependência sem que ninguém perceba.
Checklist antes de ativar
- Os caminhos em que a aprovação da IA pode contar estão listados?
- Mudanças mistas assumem a maior classe de risco?
- Áreas sensíveis têm CODEOWNERS ou revisão humana obrigatória?
- Checks críticos continuam obrigatórios, independentemente do parecer?
- Um novo commit invalida a decisão tomada sobre o diff anterior?
- Arquivos fora do escopo bloqueiam o fluxo ou são escalados de forma visível?
- A tela mostra commit, cobertura, checks e pendências?
- Existe uma pessoa responsável pela política e pelas configurações?
- O piloto mede retrabalho, reversões e falsos positivos?
Deixar a IA aprovar PRs pode tirar revisão mecânica da fila. O ganho aparece quando o time restringe essa aprovação a mudanças que sabe conferir e mantém responsáveis humanos onde o impacto exige julgamento.
Comece com poucos caminhos, escreva a política em linguagem simples e coloque as exceções no topo da tela. Só depois amplie o espaço em que a aprovação automática pode contar.