Em 23 de setembro de 2026, o GitHub publicou em seu blog de engenharia um relato técnico assinado por Alberto Gimeno sobre uma das tarefas menos visíveis e mais difíceis no desenvolvimento de ferramentas: fazer um pull request gigantesco abrir rápido e rolar sem travar. A equipe reconstruiu a superfície de diff do GitHub Copilot app para lidar com um caso extremo, testado em um projeto de código aberto com 2.200 arquivos, mais de um milhão de linhas alteradas e mais de 400 comentários de revisão inline.
O texto parte de uma constatação do dia a dia de times de software. Refatorações amplas e migrações muitas vezes precisam chegar como uma única mudança.
Dividir o trabalho em stacked pull requests ajuda a tornar a revisão mais leve e a reduzir risco. Nem toda alteração pode ser separada de forma limpa.
Quando isso acontece, resta um pull request enorme. Ele ainda cresce por causa da própria conversa de revisão.
O requisito assumido pelo time foi claro: a experiência de revisão precisa continuar rápida e fluida mesmo com diff e discussão em escala extrema.
O problema: comentários quebram a virtualização
Renderizar um diff grande com velocidade é um problema conhecido. A receita padrão é virtualizar as linhas, manter o DOM montado pequeno e explorar o fato de que cada linha é código com altura previsível.
Assim, mesmo em um milhão de linhas, apenas cerca de 100 linhas existem de fato no navegador ao mesmo tempo. A barra de rolagem fica no tamanho correto e o salto direto para a linha N funciona.
Comentários são a parte difícil. A altura de um comentário depende de como o markdown quebra o texto em cada largura, de blocos que o usuário pode expandir ou recolher, de uma caixa de resposta que abre dentro da thread e cresce enquanto se digita, de diffs de sugestão, reações e banners, além de imagens que mudam de tamanho ao terminar de carregar.
Nada disso é conhecido antes da renderização. Isso quebra o contrato que sustenta o desempenho de diffs somente de código.
Esse contrato se apoia em um renderizador imperativo de linhas recicladas sem componente React por linha, geometria em typed arrays para a matemática de offsets, documentos de diff transmitidos com estrutura primeiro pelo backend e uma API de rolagem imperativa com salto exato para uma linha.
Reservar uma altura fixa para cada comentário também não resolve. Uma estimativa correta na média continua errada nos extremos: superestima a maioria e deixa faixas de espaço vazio, ou subestima as peças caras e corta conteúdo.
Pior ainda, medir a altura real depois da pintura e reescrever a tabela compartilhada de offsets desloca tudo o que está abaixo enquanto o usuário já está rolando. Isso produz um salto de rolagem, grande em um pull request grande.
Duas geometrias em vez de uma
A solução foi parar de forçar uma única geometria a servir dois tipos de conteúdo. A altura total do documento passou a ser dividida em dois domínios independentes.
De um lado, a altura determinística do código, exata e conhecida de antemão. De outro, a soma das alturas efetivas dos blocos dinâmicos, primeiro estimadas e depois medidas.
A geometria de código preserva o mundo original. É determinística, baseada em somas de prefixo, exata e nunca reconstruída quando um comentário muda de tamanho.
Já a geometria de blocos dinâmicos cobre tudo cuja altura não pode ser prevista, como as threads de revisão. Para esse conteúdo, o compromisso possível não é ter todas as alturas conhecidas antes da pintura.
É ter alturas limitadas, medidas de forma preguiçosa e com correções pequenas, ancoradas naquilo que o usuário está olhando naquele momento. O ponto central é que nenhum trabalho por frame cresce com o total de linhas do documento.
Como os bugs foram encontrados
Segundo o relato, esses problemas só aparecem sob carga, em um motor de renderização específico e em uma posição de rolagem específica. Isso torna a reprodução difícil.
A resposta do time foi metodológica: definir o que significava "saudável", instrumentar a superfície de diff para responder a essa pergunta e executar o ciclo completo de mudar, medir e melhorar de forma não assistida.
O texto também aponta o pipeline de dados como elo crítico. Uma superfície de diff veloz não serve de nada se a fonte que a alimenta trava ou descarta trabalho já realizado.
Por que isso importa
O assunto pode parecer um detalhe interno de engenharia de interface, mas toca um gargalo real de quem usa assistentes de código no dia a dia. Migrações e refatorações amplas continuam dependendo de revisão humana.
Revisões com centenas de comentários inline são exatamente onde as ferramentas costumam falhar.
Ao tornar viável abrir um pull request com mais de um milhão de linhas e centenas de comentários, o GitHub mostra que o limite desses produtos não está apenas no modelo que gera código. Está na engenharia de dados, medição e renderização que coloca esse código na frente de quem revisa.
A decisão de arquitetura descrita é um lembrete de que desempenho em escala raramente vem de uma otimização única. Vem da separação correta de responsabilidades entre partes determinísticas e imprevisíveis de um sistema.
Fontes e links
- Rendering huge pull requests in the GitHub Copilot app
- GitHub Copilot app
- Stacked pull requests
- Alberto Gimeno
