O GitHub Copilot code review ganhou espaço para revisar pull requests que antes paravam na porta: mudanças muito grandes e código aberto por agentes automáticos. A atualização publicada pelo GitHub em 27 de agosto também adiciona motivos para resolver comentários, um detalhe pequeno na interface que pode melhorar bastante a conversa sobre o que aconteceu depois da sugestão.
Na prática, a ferramenta passa a olhar para mais situações, mas isso não transforma a revisão automática em aprovação automática. O ganho está em ampliar o primeiro filtro. A decisão sobre aceitar, alterar ou ignorar uma sugestão continua dependendo de quem conhece o contexto do projeto.
O que entrou na revisão
O Copilot code review agora pode revisar pull requests criados por bots quando a organização libera essa política. O caso inclui pull requests gerados pelo Copilot cloud agent. Antes, uma revisão solicitada automaticamente para esse tipo de mudança podia cair em uma experiência limitada, porque não havia uma conta licenciada do Copilot para atribuir o trabalho.
Com a nova regra, o uso pode ser cobrado diretamente da organização. Esse ponto interessa mais a administradores do que a quem abre um pull request no dia a dia: habilitar a função significa aceitar também uma consequência de custo e governança. A configuração precisa acompanhar a política de revisão do time.
A segunda mudança é a retirada do limite anterior de 300 arquivos ou 20 mil linhas de código para a revisão. Isso não quer dizer que qualquer pull request enorme ficou fácil de entender. Significa que o Copilot não vai recusar a análise apenas por causa desse teto. Uma alteração grande ainda pode esconder dependências, migrações incompletas e decisões difíceis de avaliar em um único bloco.
Por que registrar o motivo da resolução
Ao resolver um comentário do Copilot, o usuário pode escolher entre “Addressed”, “Won’t fix” e “Incorrect”. Em português, as ideias são: o problema foi corrigido, a equipe decidiu não corrigir ou a sugestão estava errada.
Esse registro evita que todos os comentários desapareçam com a mesma aparência. Um alerta resolvido porque foi corrigido é diferente de um alerta ignorado por decisão consciente. E ambos são diferentes de uma sugestão incorreta. Para o time, essa distinção ajuda a revisar padrões de erro e a perceber quando o assistente está insistindo em um problema que não existe.
O GitHub diz que esses motivos também alimentam o aprimoramento do produto. Para a equipe que usa a ferramenta, o benefício mais imediato é local: fica mais fácil olhar para o histórico e entender se a revisão encontrou defeitos reais ou apenas produziu ruído.
O que muda para quem usa agentes de código
O cenário mais interessante é a combinação entre um agente que abre o pull request e outro processo que faz a primeira revisão. O fluxo pode economizar tempo em tarefas repetitivas, mas aumenta a importância de separar triagem de aprovação. Uma revisão automática pode apontar arquivos suspeitos, pedir contexto e encontrar um erro evidente. Ela não conhece sozinha a intenção da mudança nem o risco de colocar aquela alteração em produção.
Para pull requests grandes, vale dividir a checagem. Primeiro, confira o objetivo e os arquivos alterados. Depois, leia os comentários do Copilot que parecem ligados a segurança, dados, permissões ou comportamento externo. Por fim, execute testes que representem o caminho usado pelos clientes. O tamanho da revisão pode ter mudado, mas o tamanho do cuidado não diminuiu.
Também é uma boa hora para combinar uma convenção interna. Se o time marca “Incorrect” sem explicar nada, perde parte do valor do registro. Se marca “Won’t fix” para encerrar a fila, o histórico fica limpo, mas não necessariamente mais útil. Uma frase curta no comentário pode preservar o motivo técnico que a etiqueta não mostra.
O teste que faz sentido agora
Em vez de ativar a novidade em todo o repositório, escolha um projeto com testes razoáveis e uma rotina de revisão já conhecida. Compare alguns pull requests feitos por pessoas e por automações. Observe quais comentários viram correções, quais são descartados e quantos chegam com a classificação “Incorrect”. O objetivo não é dar uma nota para a IA; é descobrir onde ela ajuda sem criar uma segunda fila de manutenção.
A atualização do GitHub torna o Copilot code review mais presente em fluxos que envolvem agentes e mudanças extensas. Isso é útil, desde que a equipe não confunda alcance maior com julgamento melhor. O recurso ficou mais disposto a olhar. Ainda cabe ao time decidir o que merece entrar no código.
Fonte: GitHub Changelog, publicado em 27 de agosto de 2026. Imagens oficiais do GitHub, conferidas na fonte original.
