Em 11 de setembro de 2026, o GitHub mudou duas partes visíveis do Copilot Code Review: comentários do próprio Copilot que já foram atendidos podem ser resolvidos automaticamente durante uma nova revisão, e sugestões de código aplicadas pela interface passam a receber uma mensagem de commit gerada de acordo com a alteração. Ao mesmo tempo, o mecanismo de análise ganhou mais ferramentas e uma abordagem com vários agentes no nível Lite.
A consequência prática é menos trabalho de “limpeza” de threads e menos mensagens genéricas ao aceitar sugestões. Mas a atualização não transforma qualquer push em uma nova revisão, não fecha feedback humano e não substitui a decisão de aceitar, testar e mesclar o código.
O que mudou no fluxo de pull request
| Etapa | Comportamento relevante agora | O que isso significa no dia a dia |
|---|---|---|
| Comentário do Copilot já atendido | Durante o rereview, o Copilot pode resolver o próprio comentário quando um commit posterior atende ao feedback subjacente. | Threads antigas podem desaparecer da lista de pendências sem resolução manual. |
| Comentário ainda não atendido | Permanece aberto. | A lista de threads abertas tende a concentrar o que ainda exige ação. |
| Novo push | Não dispara rereview por si só, salvo quando o repositório está configurado para revisar novos pushes. | Sem essa configuração, é preciso solicitar a nova revisão manualmente. |
| Aplicação de sugestão do Copilot | O GitHub gera uma mensagem de commit contextual, baseada na alteração sugerida. | A mensagem deixa de ser apenas um preenchimento padrão e passa a funcionar como rascunho mais descritivo. |
| Análise da revisão | O Copilot passou a usar um conjunto mais amplo de ferramentas de shell e, no nível Lite, um conjunto de agentes. | A revisão pode validar mais aspectos do código sem mudar a forma básica de solicitar o review. |
A auto-resolução depende de rereview, não apenas do push
O detalhe mais importante da atualização é a ordem dos eventos. O GitHub diz que o comentário é resolvido durante a nova revisão quando um commit posterior atende ao problema apontado. Portanto, a sequência típica fica assim:
- O Copilot revisa o PR e deixa comentários.
- Você altera o código para atender alguns deles.
- Você faz push do novo commit.
- O Copilot executa um rereview, manualmente solicitado ou acionado por uma regra de revisão de novos pushes.
- Nessa nova análise, comentários que o Copilot considera atendidos podem ser marcados como resolvidos; o que ainda estiver pendente continua aberto.
Por padrão, enviar um novo commit a um PR já revisado não obriga o Copilot a revisar novamente. Para ter rereviews automáticos a cada push, o repositório precisa habilitar a revisão automática e a opção Review new pushes em rulesets. Sem isso, a nova revisão é solicitada no menu de revisores do PR.
Também é importante delimitar o alcance da função: o anúncio fala dos comentários do próprio Copilot Code Review. Ele não afirma que threads de revisores humanos serão encerradas automaticamente. Além disso, a documentação informa que respostas textuais adicionadas aos comentários do Copilot ficam visíveis às pessoas, mas não ao Copilot. Na prática, o sinal que interessa à automação é a mudança de código avaliada no rereview, não uma discussão escrita com o bot.
Antes e depois em um PR: um exemplo simples
Imagine um pull request com três comentários do Copilot: um sobre tratamento de erro, outro sobre um teste ausente e um terceiro sobre duplicação de lógica. O desenvolvedor corrige o tratamento de erro e a duplicação, mas decide deixar o teste para um commit seguinte.
Antes da atualização: mesmo depois de aplicar as correções, era comum ainda haver trabalho manual para encerrar threads que já tinham perdido relevância.
Com a atualização: depois do push e do rereview, o Copilot pode resolver automaticamente os dois comentários que considera atendidos e manter aberto o comentário sobre o teste. O ganho não é “o Copilot decidiu que o PR está pronto”; é uma lista de pendências potencialmente mais limpa.
Há uma ressalva útil: a documentação atual do GitHub ainda avisa que, em rereviews, o Copilot pode repetir comentários anteriores mesmo quando eles foram resolvidos ou receberam feedback negativo. Por isso, a auto-resolução reduz o trabalho de acompanhamento, mas não deve ser tratada como garantia de que nunca haverá repetição ou reabertura de um ponto semelhante.
Smart commit messages: o recurso é mais específico do que parece
A segunda mudança visível aparece quando você aplica uma sugestão de código fornecida em um comentário do Copilot Code Review. Em vez de preencher uma mensagem padrão, o Copilot gera uma mensagem baseada no que a sugestão altera.
Isso não significa que o Copilot passe a reescrever as mensagens de todos os commits do PR, nem que commits feitos localmente recebam automaticamente uma descrição inteligente. O gatilho descrito pelo GitHub é o fluxo de suggested changes do próprio comentário de revisão.
O fluxo normal de sugestões continua relevante: é possível aplicar uma sugestão isolada ou agrupar várias em um único commit. O GitHub continua apresentando um campo de mensagem antes da confirmação do commit. A melhor prática, portanto, é tratar a mensagem sugerida como um rascunho: confira se ela descreve exatamente o escopo aplicado, especialmente quando várias sugestões forem agrupadas.
O que mudou por trás da análise
O anúncio de 11 de setembro também trouxe mudanças que não alteram os botões do workflow, mas podem influenciar a qualidade do feedback.
- Mais ferramentas de shell: além da leitura de arquivos já usada na revisão, o Copilot Code Review passou a usar o conjunto completo de ferramentas de shell do Copilot SDK, executado atrás do firewall do agente. O GitHub cita como exemplos rodar builds, testes e scripts direcionados e obter informações de ferramentas e APIs disponíveis.
- Vários agentes no nível Lite: o review Lite passou a usar um conjunto de agentes, cujas análises são combinadas em uma revisão única.
Nos experimentos divulgados pelo GitHub, a abordagem com vários agentes aumentou a média de comentários atendidos por review em 47% para achados de alta severidade, 31% para média e 11% para baixa, com redução de cerca de 8% no custo da revisão. Esses números são resultados experimentais do GitHub, não uma promessa de desempenho idêntico em qualquer repositório.
O próprio changelog separa essas melhorias do fluxo de uso: elas aprofundam a análise, mas não mudam a maneira básica de solicitar ou receber uma revisão.
O que continua exigindo decisão humana
- Um comentário resolvido não é prova de correção. Significa que, no rereview, o Copilot avaliou que o commit posterior atendeu ao feedback que ele havia deixado.
- O rereview ainda precisa acontecer. Ele pode ser pedido manualmente ou configurado para ocorrer após novos pushes.
- Feedback pendente continua pendente. A atualização foi desenhada para deixar abertos os pontos que ainda exigem atenção.
- Comentários humanos continuam sendo responsabilidade da equipe. A auto-resolução anunciada é dos comentários do Copilot.
- Aplicar uma sugestão ainda merece inspeção do diff. A mensagem de commit melhor não valida a mudança por si só.
- A decisão de merge permanece no processo do repositório. Por padrão, o Copilot Code Review envia uma revisão do tipo comentário; aprovações do Copilot são uma capacidade separada e configurável.
Um fluxo prático para usar a novidade sem delegar o PR
- Solicite a revisão inicial do Copilot — manualmente ou por configuração automática.
- Leia os comentários e priorize primeiro os achados de maior impacto, em vez de aplicar sugestões em lote sem triagem.
- Quando houver uma sugestão de código, revise o diff antes de aplicá-la.
- Se usar a sugestão, revise também a smart commit message e ajuste o texto para refletir o escopo real do commit.
- Faça push das correções.
- Garanta que haverá rereview: solicite-o manualmente ou confirme que Review new pushes está habilitado.
- Depois do rereview, olhe tanto para o que foi resolvido quanto para o que permaneceu aberto. O desaparecimento de uma thread é um sinal de acompanhamento, não uma substituição de teste ou revisão técnica.
- Antes do merge, mantenha as validações normais do projeto: CI, testes, revisão humana quando exigida e checagem do impacto da mudança.
O ganho real da atualização
O benefício principal é operacional. O Copilot Code Review passa a manter melhor o estado dos próprios comentários depois que o código muda e a produzir mensagens de commit mais úteis ao aceitar sugestões. Isso reduz duas tarefas mecânicas — limpar threads atendidas e reescrever mensagens genéricas — sem alterar a responsabilidade final do autor e dos revisores pelo conteúdo do PR.
Para equipes que já usam rereview automático, a mudança tende a ser percebida imediatamente: após cada novo push revisado, a lista de comentários pode refletir melhor o que ainda falta. Para equipes que revisam apenas uma vez, o recurso de auto-resolução só aparece quando uma nova revisão for realmente executada.
