Até agora, o Copilot funcionava sobretudo como apoio à revisão de código: analisava alterações, assinalava possíveis problemas e deixava comentários. A GitHub deu agora um passo diferente. Numa pré-visualização pública anunciada a 1 de setembro, os administradores podem permitir que o Copilot aprove um pedido de integração de código e podem fazer com que essa aprovação conte para o número mínimo exigido antes de integrar a alteração.
A opção vem desligada por defeito. Pode ser controlada ao nível da empresa, da organização e de cada repositório, com possibilidade de limitar o seu efeito a determinados caminhos de ficheiros.
Isto torna a mudança mais relevante do que uma simples melhoria na revisão feita pelo Copilot. Se uma aprovação automática pode satisfazer uma regra que bloqueia ou permite a integração, a IA passa a participar diretamente num dos mecanismos que decidem se o código entra na branch principal.
O que muda na prática
Cada revisão feita pelo Copilot inclui agora uma avaliação sobre se a alteração parece pronta para aprovação. Essa avaliação, por si só, é apenas informativa e não cumpre os requisitos de integração.
Quando a funcionalidade de aprovação é ativada, o Copilot pode registar uma aprovação formal. A GitHub pode então contá-la entre as aprovações obrigatórias definidas para o repositório.
A decisão é hierárquica. Ao nível da empresa, a funcionalidade pode continuar bloqueada ou ser disponibilizada apenas a determinadas organizações. A organização pode ativá-la para todos os repositórios, escolher apenas alguns ou deixar a decisão a cada repositório. Por fim, o administrador do repositório decide se o Copilot pode aprovar e se essa aprovação tem valor efetivo nas regras de integração.
Isto evita que a simples utilização da revisão de código com Copilot lhe dê automaticamente poder para autorizar uma integração.
A aprovação pode valer apenas em partes específicas do repositório
A principal forma de limitar o risco é definir onde a aprovação do Copilot pode contar. A GitHub permite configurar até 15 padrões de ficheiros. Para que a aprovação satisfaça os requisitos de integração, todos os ficheiros alterados têm de corresponder a um dos padrões autorizados.
Esta granularidade permite separar áreas de menor risco de componentes mais sensíveis. Uma equipa pode aceitar a aprovação do Copilot para documentação gerada, algumas configurações ou zonas de manutenção, mantendo revisão humana obrigatória para autenticação, pagamentos, infraestrutura ou controlos de segurança.
Não se trata apenas de uma preferência do Copilot. A configuração determina em que partes do código a sua aprovação pode realmente contribuir para abrir o caminho à integração.
Alterações posteriores anulam a aprovação anterior
A GitHub também protege contra aprovações que ficam desatualizadas. Se forem adicionados novos commits depois de o Copilot aprovar a alteração, essa aprovação é anulada e é necessária uma nova revisão.
O princípio é semelhante ao aplicado a revisores humanos quando o código muda depois da aprovação. O que interessa não é saber se a alteração foi aprovada em algum momento, mas se a versão atual foi revista.
Em equipas que voltam a pedir revisão após cada push, este comportamento pode fazer parte de um controlo contínuo. Ainda assim, quanto mais automatizado se torna o ciclo entre revisão, aprovação e integração, mais importante é manter uma verificação independente nas áreas críticas.
Uma aprovação obrigatória pode deixar de significar revisão independente
A documentação da própria GitHub continua a dizer que o Copilot pode não detetar todos os problemas, pode cometer erros e que o seu feedback deve ser validado e complementado por revisão humana.
Ao mesmo tempo, a nova funcionalidade permite que uma aprovação do Copilot satisfaça a regra de aprovações obrigatórias do repositório.
É aqui que o significado da regra muda. Muitas equipas usam «é necessária uma aprovação» como forma simples de garantir que outra pessoa analisou a alteração. Se o Copilot puder fornecer essa aprovação, a regra continua tecnicamente cumprida, mas já não garante, por si só, o mesmo grau de independência na revisão.
Por isso, a governação deve passar a considerar quem aprovou, e não apenas quantas aprovações existem.
A questão torna-se ainda mais importante quando o código foi criado por outro agente de IA. Se um agente produz a alteração e o Copilot a aprova sem intervenção humana, autoria e autorização podem passar a fazer parte de uma cadeia totalmente automática.
Dar ao Copilot um papel limitado e explícito
Uma abordagem mais segura é tratar o Copilot como um revisor automatizado com permissões próprias.
Um repositório pode permitir que o Copilot apenas comente, permitir que aprove mas sem que essa aprovação conte para a integração, ou aceitar a aprovação apenas em repositórios e caminhos de menor risco previamente definidos.
Nas áreas críticas, pode continuar a ser exigida uma barreira independente: aprovação de outro programador, intervenção de um responsável através de CODEOWNERS ou um controlo técnico que o Copilot não consiga satisfazer sozinho.
Também convém definir quando é obrigatória uma nova revisão, que informação fica disponível para auditoria e se alterações geradas por outra IA podem ser aprovadas sem intervenção humana.
Continua a ser uma funcionalidade experimental
As aprovações do Copilot continuam em pré-visualização pública e a GitHub avisa que o comportamento pode mudar. As organizações devem, por isso, evitar criar regras difíceis de alterar com base numa funcionalidade que ainda está em evolução.
Apesar disso, a direção é clara: o Copilot deixa de ser apenas uma fonte de comentários sobre o código e pode, quando os administradores assim o permitem, participar no mecanismo formal que autoriza uma integração.
A pergunta relevante para as equipas de engenharia já não é apenas se o Copilot consegue aprovar uma alteração. É decidir em que repositórios e partes do código essa aprovação deve ter peso real e que verificação independente deve continuar obrigatória.