Copilot code review ganha razões de resolução e deixa de ignorar PRs gigantes

O GitHub anunciou no Changelog de 27 de agosto de 2026 três mudanças no Copilot code review, o recurso que faz 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 → comentar automaticamente em pull requests. Nenhuma delas é revolucionária isoladamente, mas juntas atacam três atritos concretos de quem já plugou a ferramenta no fluxo de revisão: PR grande que ficava sem análise, PR aberto por bot que caía num modo capado, e o vácuo de feedback quando o time descartava uma sugestão. Vale entender o que muda por baixo antes de decidir se isso altera sua rotina.

O fim do limite de 300 arquivos

Essa é a mudança de maior impacto operacional. Até agora, o Copilot code review se recusava a revisar PRs acima de 300 arquivos ou 20.000 linhas de código, caindo fora justamente nos casos em que uma segunda leitura seria mais útil. Segundo o changelog, essa limitação simplesmente não se aplica mais.

Na prática, quem trabalha com monorepo, migração de framework ou aquele PR de bump de dependência que arrasta lockfiles inteiros vivia esbarrando nesse teto. O caso clássico: você atualiza uma lib e o package-lock.json ou o Gemfile.lock explode a contagem de arquivos, o PR estoura o limite e a revisão automática nem começa. Agora ela roda.

O trade-off aqui é de sinal versus ruído, não de disponibilidade. PR gigante costuma gerar review gigante, e revisão de IA em cima de 20 mil linhas tende a produzir muito comentário de baixo valor no meio de poucos achados relevantes. A ausência do limite técnico não muda o fato de que PR grande continua sendo má prática de engenharia. O recurso agora cobre o caso, mas isso não é convite para largar a disciplina de fatiar mudança em pedaços revisáveis por humano.

PRs abertos por bots e pelo Copilot cloud agent

Aqui há duas coisas empacotadas. A primeira é de billing e identidade. Quando um PR é aberto por um bot e a revisão é disparada automaticamente, não existe uma conta com licença Copilot para atribuir o consumo. O GitHub resolveu isso amarrando a uma política específica: com a opção "Allow members without a Copilot license to use Copilot code review in GitHub.com" ativada, a revisão roda e o uso é cobrado direto na organização. Ou seja, é uma decisão de administração, não algo que aparece sozinho, e mexe na conta no fim do mês.

A segunda é mais interessante para quem usa o Copilot cloud agent (o agente que abre PRs de forma autônoma). Antes, quando a revisão automática caía em cima de um PR aberto por esse agente, o Copilot entregava uma "limited experience", um modo reduzido. Agora esses PRs recebem revisão agêntica completa.

Isso fecha um ciclo que estava meio quebrado: você tinha um agente escrevendo código e abrindo PR, mas a camada de revisão automática não olhava aquele PR com a mesma profundidade que olharia um PR humano. O ponto de atenção metodológico é óbvio e vale dito em voz alta: IA revisando código de IA não substitui olho humano. Fecha o loop de automação, sim, mas o risco de dois modelos concordarem com o erro um do outro é real. Trate isso como uma primeira passada, não como aprovação.

Razões de resolução: o feedback que faltava

A mudança mais discreta e, do ponto de vista de produto, a mais sagaz. Ao lado do botão "Resolve conversation" de qualquer comentário do Copilot, agora existe um dropdown com três opções ao resolver:

A diferença entre esses três estados é enorme para quem constrói o produto e, indiretamente, para quem usa. Antes, resolver um comentário era um sinal binário: fechado. Um comentário aplicado e um comentário descartado por ser lixo geravam exatamente o mesmo evento. Agora o GitHub distingue "acertou" de "errou", e é isso que alimenta a métrica de qualidade real da revisão automática.

Para o dev, o ganho imediato é pequeno (mais um clique), mas há um efeito colateral bom de gestão: marcar sistematicamente Incorrect cria, ao longo do tempo, um retrato honesto de quanto ruído a ferramenta gera no seu repositório. É o tipo de dado que serve para decidir se o Copilot code review está ajudando ou virando teatro de aprovação no seu time. O changelog é direto ao dizer que a escolha "provides valuable feedback to the product team and helps improve the product", o que deixa claro que o objetivo primário é telemetria.

O que fica em aberto

O anúncio não traz números: não diz como o Copilot lida agora com PRs de 5 mil arquivos em termos de tempo de resposta ou custo, nem quanto a revisão agêntica de um cloud agent consome. Também não detalha se as razões de resolução influenciam o comportamento do modelo naquele repositório específico ou se são só sinal agregado para o time de produto. Pela descrição, parece ser telemetria global, o que significa que marcar Incorrect não vai calibrar o Copilot na hora para o seu código.

Como o próprio changelog lista, essas mudanças vêm coladas a um pacote de ajustes de política e billing anunciado no dia seguinte ("Upcoming changes to GitHub Copilot policies and billing"). Quem administra a organização deveria ler os dois juntos antes de ligar a política que autoriza revisão sem licença: ela abre a porta para cobrança que hoje não existe.

No fim, o recado prático é sóbrio. Se você já usa Copilot code review, o limite removido é ganho líquido e a razão de resolução custa um clique que vale a pena. Se você ainda não usa, nada aqui muda a pergunta de fundo: revisão de IA é uma primeira camada barata para pegar o óbvio, não um substituto do revisor humano que entende o contexto do negócio. As novidades melhoram a ferramenta dentro do papel que ela já tinha, sem expandir esse papel.

Fonte: GitHub Changelog