O engenheiro do GitHub Stephen Toub publicou, em 16 de setembro, uma retrospectiva de uma reescrita em larga escala conduzida pelo agente Copilot: o runtime do agente Copilot foi totalmente convertido de TypeScript/Node.js para Rust. As cerca de 430 mil linhas originais de TypeScript em produção viraram, ao final, 832.378 linhas de Rust em produção, além de 468 mil linhas de testes unitários em Rust e 174 mil linhas de testes ponta a ponta.
O trabalho foi de 12 de maio a 21 de agosto, cerca de 14,5 semanas. Nesse período, 128 pull requests foram mesclados de forma incremental na branch main, com lançamentos contínuos — ao todo 135 versões (100 pré-lançamentos, 35 versões estáveis), média de cerca de 1,3 por dia.
A maior parte do código foi escrita pelo modelo — e o que cabe ao humano?
O veredito de Toub sobre essa experiência é direto:
"A project that would have taken a whole team of developers a year or two before agents was now completed primarily by a single developer, in only a few months."
Um projeto que, antes dos agentes, exigiria uma equipe inteira de desenvolvedores por um a dois anos foi concluído principalmente por um único desenvolvedor, em apenas alguns meses.
Os modelos principais usados foram Claude Opus 4.8, GPT-5.6 Sol e a série Claude Haiku; os subagentes responsáveis pela otimização de throughput priorizaram Opus 4.8 e GPT-5.6 Sol. Isso revela um sinal interessante: nessa reescrita de nível de produção do próprio GitHub (do grupo Microsoft), o modelo principal usado foi da concorrente Anthropic, e não exclusivamente da OpenAI.
As tarefas humanas ficaram bem delimitadas. Nas interações desse engenheiro líder, 31% do tempo foi gasto em "revisão, testes e CI", 17,4% em "questionar decisões técnicas" e 15% em "garantir que o trabalho fosse concluído por completo". A palavra final sobre arquitetura, escolhas de design e merges finais permaneceu sempre com o humano. O modelo cuidou do volume de código; o humano, da direção e da validação.
Validação com os testes já existentes, cerca de cinquenta tropeços
Essa reescrita não criou um novo conjunto de critérios de aceitação; em vez disso, os testes ponta a ponta já existentes rodaram continuamente sobre o novo código em Rust, com lançamentos incrementais para expor regressões em pequena escala e detectá-las cedo. Alguns números de engenharia do processo também são reveladores: a taxa de acerto do cache de prompts chegou a 96,22%, e a compressão de contexto foi acionada 5.116 vezes ao longo das sessões.
Os tropeços também foram registrados com transparência. Ao longo de todo o processo, houve mais de 50 problemas conhecidos, divididos em cinco categorias: migração incompleta, problemas de estado e ciclo de vida, inconsistências no contrato de comportamento, problemas de fronteira com o host e expectativas de teste escritas incorretamente. A grande maioria foi corrigida antes de chegar à versão estável. A última categoria merece atenção especial de quem faz migrações: ao usar testes antigos para validar uma nova implementação, às vezes o erro está no teste, não no código novo.
O que isso significa para equipes de engenharia
Casos assim, de "usar IA para reformular por completo um componente central próprio", dizem mais sobre os limites reais dos agentes de programação atuais do que qualquer ranking de benchmark. Há três lições diretamente aplicáveis: primeiro, não espere uma reescrita de uma vez só — os 128 pull requests mesclados incrementalmente e os vários lançamentos por dia só funcionam graças à integração contínua, que dilui o risco; segundo, os critérios de aceitação precisam ser definidos antecipadamente — aqui, tudo dependeu dos testes E2E já existentes como régua, e sem essa régua não há como julgar se o modelo "escreveu certo"; terceiro, o esforço humano migrou da escrita de código para a revisão, a tomada de decisões e a busca por lacunas, o que amplia em uma ordem de grandeza a escala de reescrita que uma única pessoa consegue supervisionar.
Um ponto que vale reter: os ganhos de arquitetura (incorporação no mesmo processo, menor consumo de memória, inicialização mais rápida) aparecem no texto original apenas de forma qualitativa, sem números de antes e depois para memória, latência ou throughput. Quanto desempenho real a reescrita trouxe ainda não dá para verificar a partir dessa retrospectiva. O caminho de TypeScript para Rust também não é padrão para a maioria das equipes — ele só faz sentido quando já existe um conjunto de testes robusto e disposição para lançar versões todos os dias.
Fontes: GitHub Blog (Stephen Toub), CocoLoop; números de 832 mil linhas, 128 pull requests, 14,5 semanas, taxa de acerto de cache de 96,22% e cerca de 50 problemas conhecidos conferidos com a retrospectiva oficial.