GitHub reescreve o runtime do Copilot em Rust e corta tempo de inicialização de 5,25s para 292ms

A GitHub concluiu a migração do runtime que sustenta o Copilot CLI, o Copilot app e o Copilot SDK de TypeScript↳TypeScript23 conteúdosTypeScript: ReadonlyArrayDev (Back & Front) · jun 2019Onde usar ANY no TypeScriptDev (Back & Front) · out 2025Tudo sobre o Node rodar TypeScript nativamente!Dev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → e Node.js para Rust, segundo reportagem da InfoQ publicada em 9 de outubro de 2026 com base em post da própria GitHub. O trabalho substituiu mais de 800 mil linhas de código em produção por uma reescrita assistida por 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 →: ao final, o runtime somava 832.378 linhas de Rust em produção e mais 468.689 linhas de testes unitários em Rust.

A migração levou cerca de 14,5 semanas, entregues em 128 pull requests, enquanto a GitHub continuava lançando versões normalmente: foram 135 releases no período, sendo 35 estáveis e 100 pré-lançamentos. Não houve pausa no desenvolvimento para fazer a troca de motor.

O preço do boundary entre processos

A implementação anterior dependia de Node.js e do V8, e se comunicava com as aplicações host através de uma fronteira entre processos. Segundo a GitHub, esse desenho adicionava aproximadamente 100 MB de working set por cliente só para manter a ponte entre processos funcionando.

A nova implementação em Rust pode ser embutida diretamente na aplicação host através de uma C ABI, eliminando essa fronteira quando o caso de uso permite. Um modo fora de processo continua disponível para quem precisa dele. Em um cenário medido de inicialização de cliente, criação de sessão e uma interação de turno único, o tempo caiu de 5,25 segundos no runtime anterior para 292 milissegundos com o runtime em Rust embutido no processo.

Troca de motor em voo: estratégia incremental

Em vez de reescrever tudo em paralelo e fazer um corte único, a GitHub substituiu componentes individuais de TypeScript por implementações em Rust, um de cada vez. Uma camada temporária de interoperabilidade via N-API conectava as duas pontas durante a transição.

Esse desenho permitiu que os testes end-to-end já existentes continuassem validando o código novo enquanto outras partes do sistema ainda rodavam em TypeScript. A camada de compatibilidade chegou a 2.019 exports internos de N-API e 3.356 pontos de chamada em TypeScript antes de ser removida por completo, já com o runtime majoritariamente em Rust.

IA escreveu, humanos validaram comportamento

Agentes de IA geraram a maior parte da implementação em Rust. O trabalho humano se concentrou em compilação, testes e revisão para identificar regressões em comportamento, tratamento de estado e lifetime, semântica de bibliotecas e otimizações perdidas na tradução automática. A GitHub registrou 4.478 execuções diretas de cargo check, das quais 87,1% terminaram sem erros.

A repercussão na comunidade, citada pela InfoQ, girou em torno dos limites da verificação automatizada em reescritas assistidas por IA. Um comentarista identificado como PLBjt resumiu o ponto central da discussão:

A parte interessante aqui é menos o fato de o Copilot ter escrito Rust e mais se a migração manteve o comportamento do runtime estável nas fronteiras.

The interesting part here is less that Copilot wrote Rust and more whether the migration kept the runtime's behavior stable at the boundaries.PLBjt, comentário na comunidade InfoQ

Francesco Pira, XR Tech Lead↳Liderança técnica5 conteúdosLiderança técnica: a arte de inspirar desenvolvedores e gerar transformações 🚀Gestão Dev & TI · mai 2024Full Cycle lança pós-graduação que capacita devs para cargos de liderança técnicaDev (Back & Front) · mar 2024De Dev a Tech Leader: caminhos para se tornar um Tech Leader excepcionalGestão Dev & TI · ago 2024Ver tudo em Gestão Dev & TI → na Leonardo, destacou mudanças pequenas e revisáveis, camadas de compatibilidade e julgamento humano de engenharia como elementos importantes da abordagem. Côme Redon, Senior Solution Engineer na Microsoft, apontou o desafio de identificar contratos de comportamento não documentados em sistemas legados, que compilação sozinha não revela.

O que muda para quem constrói com o Copilot SDK

O Copilot SDK continua com interfaces específicas por linguagem, hoje disponíveis em TypeScript, Python, Go, .NET, Java e Rust. Para quem integra o SDK em ferramentas próprias, a mudança relevante não é a linguagem do runtime em si, e sim as duas formas de consumi-lo: embutido no processo da aplicação host via C ABI, ou em um modo fora de processo separado, como antes.

Em termos práticos, times que constroem CLIs, extensões de editor ou integrações sensíveis a latência ganham a opção de embutir o runtime e eliminar os ~100 MB de working set por cliente que a ponte entre processos exigia, além do ganho de inicialização medido pela própria GitHub. Quem já usa o Copilot SDK via API de alto nível em TypeScript, Python, Go, .NET, Java ou Rust não deveria precisar mudar código de aplicação: a reescrita foi pensada como substituição de motor por baixo da mesma superfície de integração.

O caso também funciona como referência prática para equipes que avaliam reescritas grandes com ajuda de agentes de IA. A combinação usada pela GitHub, componentes substituídos aos poucos, camada de compatibilidade temporária, testes end-to-end mantidos durante toda a transição e revisão humana focada em comportamento (não só em compilar), é um roteiro concreto para quem pensa em aplicar a mesma estratégia em sistemas legados próprios.

O que ainda fica em aberto

A reportagem da InfoQ não traz dados públicos sobre paridade completa de comportamento em cenários como cancelamento, retentativas e backpressure, justamente os pontos levantados pela comunidade como difíceis de capturar só com compilação e testes automatizados. Também não há, na fonte, um guia de migração voltado a consumidores externos do SDK que detalhe eventuais diferenças sutis de comportamento entre o runtime antigo e o novo.

Fonte: InfoQ