GitHub Copilot ganha configurações granulares de code review automatizado

O GitHub anunciou em 23 de setembro de 2026, via changelog oficial, um conjunto de ajustes na configuração do Copilot code review que muda a forma como equipes decidem quando e como a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → entra na revisão de pull requests. A mudança não é sobre qualidade da revisão em si, mas sobre quem controla o gatilho e o nível de esforço da IA, algo que até agora era limitado a poucos planos e pouco granular.

O que existia antes

Antes desse anúncio, as configurações pessoais de code review do Copilot ficavam disponíveis apenas para quem tinha Copilot Pro, Pro+ ou Max, dentro da página genérica "Copilot features". Existia um único interruptor de revisão automática, sem distinção entre pull request em draft, push novo ou coautoria. Ou seja: ou a IA revisava tudo automaticamente, ou nada.

Esse modelo binário criava atrito real em times grandes: quem trabalha com PRs em draft por dias (comum em fluxos de trunk-based development com feature flags) recebia comentários de revisão antes mesmo do código estar pronto para olhos humanos, gerando ruído que o desenvolvedor aprendia a ignorar, o que é o pior cenário possível para uma ferramenta de qualidade de código.

O que muda: configuração pessoal por gatilho

Agora, em Perfil → Copilot settings, existe uma página dedicada de "code review" disponível em todos os planos, incluindo Copilot Business e Copilot Enterprise, que antes ficavam de fora. A partir dela, o desenvolvedor controla separadamente:

• Revisão automática ao criar um PR, coautorar um PR ou tirar um PR do estado draft;
• Revisão automática em novos pushes;
• Revisão automática especificamente para PRs em draft que você criou ou coautorou;
• O esforço padrão de revisão, hoje com duas opções: Lite ou Balanced.

Na prática, isso permite um fluxo como: automação ligada só para PRs que saem de draft (sinal de "pronto para revisão"), com push subsequente sem nova rodada automática, evitando que cada git push --force depois de um rebase dispare uma nova leva de comentários. Quem prefere manter controle manual continua podendo pedir revisão pela aba "Reviewers" do PR e escolher o esforço ali, mesmo que o padrão pessoal seja outro.

Lite vs Balanced: o que muda no esforço

O changelog não detalha os critérios internos de cada nível, mas a distinção nomeada como esforço de revisão indica que o Copilot ajusta profundidade de análise (provavelmente número de arquivos considerados em contexto, ou detalhamento dos comentários) conforme o modo escolhido. Isso é relevante para quem trabalha com PRs grandes: um esforço mais leve tende a produzir menos comentários e resposta mais rápida, útil para revisões de rotina ou hotfixes; um esforço balanceado é mais indicado para mudanças estruturais, onde vale o tempo extra de análise.

O ponto prático é que esse esforço padrão se aplica tanto às revisões manuais quanto às automáticas configuradas, e pode ser sobrescrito PR a PR na hora de solicitar a revisão manualmente. Ou seja, dá para manter Lite como padrão do dia a dia e subir para Balanced apenas quando o PR justificar.

Governança em nível de enterprise

A segunda mudança é para quem administra organizações inteiras: administradores autorizados de enterprise agora podem definir um esforço padrão único (Lite, Balanced, ou o padrão do GitHub) que se aplica, por herança, a todos os repositórios pertencentes às organizações daquele enterprise. Organizações e repositórios individuais continuam podendo sobrescrever esse padrão.

Esse detalhe importa mais do que parece para times de plataforma e DevEx: até aqui, padronizar o comportamento do Copilot code review entre dezenas de repositórios exigia configurar cada um manualmente ou confiar que cada dev ajustaria sua própria conta. Com o padrão de enterprise, dá para estabelecer uma política central (por exemplo, Balanced como piso mínimo em repositórios de produção) sem depender de disciplina individual, mantendo ainda flexibilidade de override onde fizer sentido.

Quando vale ativar automação e quando não

A revisão automática do Copilot compensa em times com volume alto de PRs pequenos e recorrentes, onde ter um primeiro filtro de IA antes do humano acelera o ciclo. Ela tende a atrapalhar em dois cenários:

• Times que já usam ferramentas de lint/SAST agressivas no CI: revisão automática duplicada gera ruído sem adicionar sinal novo, e o dev acaba silenciando as duas.
• Fluxos com PRs em draft de longa duração usados como checkpoint de trabalho (não como "quase pronto"): ativar revisão automática para draft nesse caso é o oposto do que o recurso resolve, porque o comentário chega cedo demais para ser útil.

A granularidade nova resolve exatamente esse segundo caso, já que dá para desligar especificamente a automação em draft sem abrir mão dela para PRs prontos.

O que fica em aberto

O GitHub não publicou, junto deste anúncio, dados de adoção ou métricas de precisão comparando Lite e Balanced, então qualquer decisão sobre qual usar por padrão em um time ainda depende de observação direta durante algumas semanas. Vale registrar também que este anúncio segue outro, de 18 de setembro de 2026, sobre uma "experiência de revisão melhorada" no Copilot code review, o que sugere que o GitHub está iterando rápido nessa frente, e times que adotarem a configuração agora devem revisar os padrões escolhidos daqui a alguns meses, quando a ferramenta provavelmente tiver mudado de novo.

Fonte: GitHub Changelog