GitHub reescreveu o motor do Copilot com agentes de IA: 832 mil linhas de código em 14 semanas

No dia 16 de setembro, o GitHub publicou um relato técnico incomum pelo nível de detalhe: o motor que roda por trás do Copilot foi reescrito de uma linguagem para outra, e a maior parte do código foi produzida por agentes de inteligência artificial — usando o próprio Copilot.

Os números do relato:

• 430 mil linhas de código em produção na linguagem original foram portadas;
• o resultado tem 832.378 linhas na nova linguagem, mais 468 mil linhas de testes automatizados;
• o trabalho saiu em 128 entregas separadas, integradas continuamente ao produto em funcionamento;
• a janela foi de 12 de maio a 21 de agosto de 2026 — cerca de 14 semanas e meia;
• foram registradas 1,13 milhão de chamadas de ferramentas pelos agentes, 61% delas feitas por subagentes.

O que chama atenção não é o volume

Reescrever software de uma linguagem para outra é um dos projetos que mais fracassam em tecnologia. O padrão conhecido é: a equipe cria uma ramificação paralela para a nova versão, o produto antigo continua evoluindo do lado, e depois de um ano as duas versões estão tão distantes que a migração é abandonada.

O relato do GitHub descreve o caminho oposto. Nada foi feito em uma grande ramificação paralela. Cada pedaço foi convertido, testado e entregue enquanto o produto seguia recebendo mudanças normais — daí as 128 entregas e as mais de cem versões publicadas no período. É uma decisão de gestão, não de ferramenta: o projeto foi fatiado em entregas que cabem em uma revisão.

Onde a IA ajudou de verdade

Duas coisas ficam evidentes na leitura, e as duas contrariam um pouco o marketing habitual:

Primeiro, a tradução é o trabalho ideal para um agente. Converter código de uma linguagem para outra tem um gabarito — o comportamento precisa ser idêntico ao que existia. O agente não está inventando regra de negócio; está reescrevendo algo que já funciona, com um teste dizendo se acertou. É exatamente o cenário em que a IA rende mais e erra de forma detectável.

Segundo, o volume de testes é quase tão grande quanto o de código. Quase meio milhão de linhas de teste automatizado não é detalhe: é o que tornou possível aceitar código gerado em escala. Sem essa rede, ninguém integraria 128 entregas em um produto vivo.

O relato também é honesto sobre o que não mede. Ele fala em ganhos qualitativos de desempenho e de consumo de memória, mas não publica percentuais — e vale desconfiar de qualquer resumo por aí que apresente números precisos de ganho como se fossem oficiais.

O que um gestor tira disso

• Projetos antes considerados inviáveis mudaram de categoria. Migração de sistema antigo, reescrita de módulo legado, atualização de tecnologia parada há uma década: o custo desse tipo de trabalho caiu de forma relevante. Vale reabrir a lista do “um dia a gente faz”.
• O gargalo virou a revisão, não a escrita. Se o código passa a sair mais rápido do que a equipe consegue revisar, o projeto empaca do mesmo jeito. Vale planejar capacidade de revisão e de teste antes de planejar volume de geração.
• Cobertura de testes deixou de ser tema técnico. Passou a ser o que define se a empresa pode ou não usar geração de código em escala. Quem não tem testes automatizados não tem como aproveitar isso com segurança.
• Fatias pequenas, sempre. A lição mais transferível do relato não tem nada de inteligência artificial: entregar em pedaços integrados é o que faz migrações grandes chegarem ao fim.

É um resultado impressionante e ao mesmo tempo bastante comum, no sentido mais elogioso do termo: uma equipe com teste automatizado, revisão disciplinada e entregas pequenas usou uma ferramenta nova para acelerar o que já sabia fazer. Ferramenta boa em processo bom multiplica. Em processo ruim, só acelera o problema.

Fontes

• The GitHub Blog — Stephen Toub, “Migrating the GitHub Copilot runtime to Rust, using Copilot” (16/09/2026): github.blog

• Imagem de capa: logotipo da linguagem Rust — Rust Foundation, CC BY 4.0, via Wikimedia Commons

• Segunda imagem: reunião diária de uma equipe de desenvolvimento — Improve It, CC BY-SA 2.0, via Wikimedia Commons