O GitHub publicou nesta sexta-feira, 11 de setembro de 2026, uma atualização do Copilot code review, a revisão automática de código com inteligência artificial dentro de pull requests, o pedido para incorporar mudanças no repositório. A partir de agora, quando um novo commit corrige um apontamento feito pelo Copilot, o agente fecha sozinho aquele comentário na reanálise, em vez de deixar a conversa aberta até alguém clicar em resolver manualmente.
A mudança apareceu no changelog oficial do GitHub na tarde de 11 de setembro e foi registrada de forma independente em 12 de setembro por veículos especializados em qualidade de software. O anúncio faz parte de um pacote que também inclui mensagens de commit mais descritivas ao aplicar sugestões do Copilot e uma revisão Lite mais profunda por trás dos panos.
O changelog do GitHub publicado em 11 de setembro de 2026 confirma o fechamento automático de comentários na reanálise, as smart commit messages e o ensemble no nível Lite, com métricas de experimentos internos. A documentação oficial consultada em 12 de setembro exige reanálise e a opção Review new pushes para revisar novos commits, enquanto o QATechTools registra de forma independente o impacto para times de qualidade.
Comentários que somem quando a correção chega
Antes, quem seguia o fluxo de revisão com Copilot precisava marcar manualmente cada thread como resolvida depois de aplicar a sugestão. Com a nova lógica, o Copilot reavalia o pull request no push seguinte e encerra os comentários que considera atendidos, mantendo abertos apenas os que ainda pedem trabalho.
O GitHub deixa claro que o fechamento automático depende de uma reanálise. Se o repositório não estiver configurado para revisar novos commits automaticamente, a pessoa ainda precisa pedir outra rodada de revisão pelo menu de revisores, conforme a documentação pública consultada em 12 de setembro.
A documentação também alerta que, durante reanálises, o Copilot pode repetir comentários antigos mesmo que alguém já os tenha resolvido ou rebaixado. A lista de pendências tende a ficar mais limpa, mas não promete um histórico perfeito em projetos com muitos pushes seguidos.
Mensagem de commit que descreve a mudança
Quando a pessoa aceita uma sugestão de código gerada por um comentário do Copilot, o editor deixa de preencher a mensagem de commit genérica e passa a propor um texto baseado no que foi alterado. O GitHub chama isso de smart commit message, mensagem inteligente de commit, e trata como extensão natural do botão de correção automática já existente na revisão.
Na prática, quem revisa dezenas de pull requests por semana ganha um rastro mais legível no histórico do Git, o registro de versões do projeto. A mensagem continua editável antes do envio, mas já chega com contexto em vez de um rótulo vazio que obriga a reescrever tudo na pressa.
Terminal, testes e build dentro da revisão
Por trás da interface, o agente de revisão passou a usar a biblioteca completa de ferramentas de terminal do Copilot SDK, o kit de desenvolvimento do Copilot, executando comandos dentro do agent firewall, barreira de segurança que isola a execução. Isso inclui rodar build, testes automatizados, scripts pontuais e consultas a APIs disponíveis no ambiente.
O GitHub descreve essa expansão como melhoria de análise, não como mudança na forma de pedir uma revisão. A empresa afirma, com base em experimentos internos, que desenvolvedores deixaram feedback mais positivo nos comentários do Copilot, que o agente encontrou mais achados de alta gravidade e que reduziu observações triviais, chamadas de nits.
Esses números vêm de testes internos da GitHub divulgados no changelog de 11 de setembro, não de uma auditoria externa. A documentação não garante que todo pull request receberá a suíte de testes completa do projeto, apenas que o agente ganhou mais caminhos para validar o trecho em análise.
Vários agentes no modo Lite
O nível Lite de esforço, opção mais rápida e econômica da revisão com Copilot, deixou de depender de um único agente. Agora um conjunto de agentes, ensemble, examina o código em paralelo e o GitHub combina os achados em uma única revisão publicada no pull request.
Segundo o changelog, essa abordagem aumentou em 47% a média de comentários de alta gravidade que acabaram sendo endereçados, em 31% os de gravidade média e em 11% os de baixa, enquanto o custo médio da revisão caiu cerca de 8%. São métricas reportadas pela própria GitHub a partir de experimentação interna, não benchmarks públicos replicáveis.
Para quem paga por créditos de inteligência artificial no Copilot, a promessa é revisão mais densa sem subir a conta na mesma proporção. O Lite continua sendo a opção de menor esforço, enquanto níveis mais profundos permanecem disponíveis para quem aceita gastar mais tempo e créditos.
Quem pode usar e como ativar
O Copilot code review exige plano Copilot compatível e, para correções automáticas com agente na nuvem, a política do cloud agent precisa estar liberada pelo administrador da organização. Repositórios gratuitos sem assinatura não recebem automaticamente essas funções só porque o changelog foi publicado.
Times que querem reaproveitar o fechamento automático de comentários precisam combinar duas peças: revisão automática habilitada e a opção Review new pushes, revisar novos envios, ligada nas regras do repositório ou da organização. Sem isso, o Copilot analisa o pull request uma vez e só volta a olhar o diff se alguém pedir manualmente.
A documentação pública de 12 de setembro também lista instruções por caminho de código em arquivos como .github/copilot-instructions.md, onde o time descreve padrões de segurança ou estilo que o agente deve priorizar. Essas instruções não substituem testes de integração contínua nem a aprovação humana exigida por muitas empresas antes do merge.
O que continua sendo responsabilidade humana
Comentários do Copilot seguem sendo consultivos: não bloqueiam o merge por si só, salvo quando o repositório combina o recurso com regras adicionais de qualidade ou segurança. A nova limpeza automática de threads ajuda a enxergar o que falta, mas não prova que a correção passou por teste de regressão real.
Veículos como o QATechTools, em 12 de setembro, recomendam pilotos controlados: abrir um pull request com defeito conhecido, aplicar correção parcial e completa em commits separados e observar se o Copilot fecha apenas o que foi de fato resolvido. São sugestões de avaliação externa, não resultados que o GitHub publicou.
Falsos positivos continuam possíveis, especialmente em código que usa bibliotecas raras ou padrões internos pouco documentados. O agente pode sugerir mudanças desnecessárias ou fechar um comentário cedo demais se interpretar mal o diff, motivo pelo qual equipes maduras ainda exigem olhar humano antes de incorporar alterações sensíveis.
Relação com outras novidades do Copilot
A atualização de 11 de setembro chega três dias depois do anúncio de APIs REST para ligar o AI Scan de segurança em pull requests, recurso diferente que mira administradores de GitHub Advanced Security. Code review e AI Scan convivem no mesmo fluxo de merge, mas respondem a problemas distintos: qualidade de código versus detecção de vulnerabilidades.
Quem já usa o Copilot no VS Code ou no JetBrains para completar linhas enquanto digita não verá essas mudanças no editor local de imediato. Elas operam na interface web e no ciclo de vida do pull request no github.com, onde o time discute, revisa e decide se a mudança entra na branch principal.
Por que a lista aberta importa na rotina
Quem já passou a tarde limpando dezenas de comentários repetidos em um pull request grande sabe o custo invisível: cada thread aberta vira ruído que esconde o que ainda quebra build ou viola política interna. Fechar automaticamente o que foi corrigido devolve foco ao que continua vermelho na lista.
Em times que adotaram vibe coding, quando a pessoa descreve a tarefa e a inteligência artificial propõe o patch, a revisão automática virou primeira barreira antes do colega humano entrar. Se o agente mantém comentários obsoletos abertos, a confiança no fluxo cai rápido e alguém volta a revisar linha por linha no diff.
A combinação de ensemble no Lite, ferramentas de terminal e fechamento automático posiciona o Copilot code review menos como leitor estático de diff e mais como colega que tenta rodar o projeto antes de opinar. A promessa ainda depende do ambiente de build disponível para o agente e das permissões que o administrador liberou.
Limites que a documentação deixa explícitos
Respostas que a pessoa escreve em um comentário do Copilot aparecem para outros revisores humanos, mas não voltam como contexto para o agente, segundo a documentação oficial. Quem discorda precisa ajustar o código ou pedir nova revisão com o diff atualizado.
Revisões automáticas podem ser configuradas por usuário, repositório ou organização, o que cria cenários híbridos em empresas grandes: um projeto piloto liga Review new pushes enquanto outro continua manual. Sem inventário claro de onde a política está ativa, alguém pode achar que o Copilot ignorou um push quando na verdade a reanálise nunca foi pedida.
Na próxima rodada de pushes, quem tiver Review new pushes ativo verá a lista de comentários encolher sozinha conforme as correções entram, e só precisará discutir o que ainda estiver aberto antes de chamar o revisor humano.