O GitHub Copilot deixou de ser apenas o colega que aponta problemas no código. Em prévia pública, o recurso de revisão agora pode enviar uma aprovação real para pull requests — e essa aprovação pode contar para a regra de revisões obrigatórias do repositório quando os administradores ativam a opção.
A mudança parece pequena na interface, mas mexe em uma fronteira importante: a IA passa de comentar uma alteração para participar formalmente do caminho que libera um merge. O recurso está desligado por padrão, é controlado em mais de um nível e não transforma qualquer comentário positivo em autorização automática.
O que o GitHub mudou no Copilot
Segundo o anúncio do GitHub, toda revisão do Copilot passa a exibir uma avaliação indicando se o pull request parece pronto para aprovação. Essa avaliação aparece no comentário-resumo junto das observações sobre o código.
Esse sinal, sozinho, não conta para os requisitos de merge. A aprovação que altera o fluxo é outra coisa: quando autorizada pelos administradores, ela é enviada como uma revisão de aprovação e pode satisfazer a quantidade exigida pela proteção da branch.
Como a aprovação funciona na prática
O recurso está em prévia pública para os planos GitHub Copilot Pro, Pro+, Max, Business e Enterprise. A configuração pode ser governada em três camadas:
- Empresa: o administrador pode manter a aprovação desativada ou permitir que as organizações decidam.
- Organização: a equipe pode liberar o recurso de forma ampla, deixar a decisão para cada repositório ou bloquear a função.
- Repositório: o administrador define se o Copilot pode aprovar e pode restringir a aprovação a determinados caminhos de arquivos.
Essa hierarquia é importante porque um time pode querer usar o Copilot em documentação ou testes simples, mas não em arquivos de autenticação, pagamentos ou regras de negócio críticas. A possibilidade de limitar caminhos reduz o alcance do risco, embora não substitua uma política de revisão.
O que acontece quando alguém envia novos commits
Se novos commits forem enviados depois da aprovação do Copilot, a aprovação é descartada da mesma forma que uma aprovação humana pode ser invalidada quando o repositório usa a remoção de revisões obsoletas. É preciso solicitar uma nova revisão para que o sistema avalie o estado atualizado do código.
Isso evita um problema óbvio: aprovar um pull request e deixar a aprovação valendo depois que o conteúdo mudou. Ainda assim, a equipe precisa entender o comportamento das próprias regras de branch, porque a aprovação automática não é uma garantia de que os testes passaram nem de que a alteração é segura.
Por que essa mudança importa
O GitHub já usa o Copilot para sugerir correções e explicar trechos. A aprovação adiciona uma consequência operacional: em determinados repositórios, o modelo pode deixar de ser apenas uma segunda opinião e passar a preencher uma etapa formal do processo.
Para equipes pequenas, isso pode reduzir o tempo gasto em alterações de baixo risco. Para equipes maiores, pode criar uma falsa sensação de controle se a aprovação do modelo for tratada como equivalente à análise de uma pessoa que conhece o contexto do produto. Um modelo pode não perceber uma decisão de negócio errada mesmo quando o código compila, os testes passam e o diff parece coerente.
O ideal é começar com escopo limitado, registrar quais pull requests receberam aprovação do Copilot e manter revisão humana para mudanças sensíveis. O próprio GitHub informa que o recurso está em prévia pública, portanto configurações e comportamento ainda podem mudar.
Copilot aprovando código é uma boa ideia?
Minha leitura é que a função faz sentido como uma válvula para tarefas repetitivas, não como substituta universal de revisão. Aprovar automaticamente um ajuste de documentação ou uma mudança mecânica bem delimitada é diferente de liberar código que altera dados de clientes.
Quem ainda está organizando o fluxo pode começar pelo guia do JSMS para revisar código com o Copilot no VS Code e combinar essa etapa com testes automatizados. Também vale entender como rodar testes no GitHub Actions antes de permitir que uma aprovação tenha efeito sobre o merge.
Perguntas frequentes
A avaliação do Copilot já libera o merge?
Não. A avaliação no comentário-resumo apenas informa que o Copilot considera o pull request pronto. Ela não conta para a regra de aprovações obrigatórias por si só.
A aprovação do Copilot fica ativada automaticamente?
Não. O GitHub informa que a função fica desativada por padrão e depende de autorização administrativa nos níveis aplicáveis.
Uma aprovação do Copilot substitui a revisão humana?
Não necessariamente. Ela pode contar para a regra configurada, mas não comprova que a alteração atende ao contexto do negócio. Em código crítico, revisão humana, testes e monitoramento continuam necessários.