Microsoft transfère agentiellement le runtime Copilot vers Rust pour 120 000 $

Le moteur logiciel qui sous-tend GitHub Copilot et un nombre croissant de produits Microsoft est désormais entièrement écrit en Rust, les agents IA effectuant l’essentiel du travail de portage.

La migration a coûté environ 120 000 dollars en utilisation de jetons IA, plus environ trois semaines de temps de développement. Cependant, les gestionnaires ont également dû faire face à quelques dizaines de régressions dans le code résultant, soulignant les défis persistants de l’IA dans la compréhension de Rust.

L’effort a mis à jour le runtime module par module jusqu’à ce que le travail soit terminé, couvrant plus de 135 versions sur une période de 14,5 semaines. Environ 1,3 demande d’extraction de port ont été ouvertes par jour.

Au total, les agents ont converti 430 000 lignes de TypeScript en 800 000 lignes de production Rust. Pour garder le port aussi simple que possible, le port n’a remplacé les modules TypeScript qu’au cas par cas. Il n’a pas été cherché à optimiser la structure du runtime lui-même. Ce travail est le prochain.

Et Rust, connu pour ses performances allégées, n’a pas déçu.

Un benchmark a mesuré la rapidité avec laquelle le runtime pouvait réaliser 1 000 cycles de vie de session en un tour, en utilisant un client partagé et 100 pipelines simultanés. L’implémentation originale de TypeScript exécutait 7,55 de ces cycles de vie par seconde, tandis que Rust exécuté en cours de processus en gérait 120 par seconde, ce qui représente une accélération de 15,9 fois sur cette charge de travail particulière.

En termes de mémoire, un lot d’agents de 10 clients a consommé 1 383 Mo avec TypeScript tandis que la réécriture de Rust n’a consommé que 126 Mo pour le même essaim. Au sein de Rust, le travail est resté en cours au lieu de générer des processus externes en arrière-plan pour être terminé, une exigence pour TypeScript.

Copilote de VS Code vers Microsoft Office

À première vue, la plupart des utilisateurs ne savent peut-être pas à quel point le runtime Copilot est omniprésent. Il prend en charge l’interface de ligne de commande (CLI) GitHub Copilot, l’application Copilot, le SDK et l’agent cloud GitHub Copilot. Il apparaît dans VS Code, Visual Studio, Excel, Outlook, PowerPoint et d’innombrables autres services cloud Microsoft.

À l’origine, le runtime était écrit en TypeScript et utilisait Node.js comme framework et V8 pour le moteur d’exécution. TypeScript et Node étaient des atouts en matière de développement rapide, mais lorsqu’ils étaient utilisés à grande échelle, ils souffraient en termes de démarrage rapide et de densité de serveur.

« Cela ne veut en aucun cas prétendre que chaque grand programme TypeScript devrait devenir Rust. Nos exigences mettaient l’accent sur l’intégration via un C ABI, une faible surcharge de démarrage et d’état stable, ainsi qu’une utilisation prévisible des ressources. Rust a rendu ces objectifs possibles », a écrit Stephen Toub, ingénieur émérite de Microsoft, dans un article expliquant l’ensemble du processus.

Le projet a utilisé Copilot pour réécrire Copilot, qui à son tour a utilisé plusieurs LLM (GPT-5.6 Sol et Claude Opus 4.8 ont tous deux été vérifiés) pour exécuter différentes parties du travail, en fonction de la force naturelle de chaque LLM.

Agents lettrés mais bavards

Toub a évalué le recours aux agents comme étant largement efficace. En effet, ce projet aurait pris des années et coûté des millions s’il avait été réalisé à la main.

Les agents ont montré plusieurs comportements émergents surprenants, a noté Toub. D’une part, ils ont passé beaucoup plus de temps à collecter des informations qu’à écrire du code.

« L’image populaire de l’IA crachant du code est presque à l’envers ; à cette échelle, le travail ressemblait beaucoup plus à une enquête itérative, inspectant l’état actuel, formant une hypothèse, effectuant un changement ciblé, rinçant et répétant », a-t-il écrit.

Une autre surprise était la fréquence à laquelle les sessions interagissaient avec d’autres sessions, soit celles qu’elles avaient engendrées, soit d’autres entièrement.

L’une des conversions les plus épineuses fut celle session.ts fichier, qui comptait plus de 30 000 lignes de TypeScript qui touchaient tous les aspects du runtime. La session de portage, qui a finalement duré 25 heures, a commencé par passer 56 minutes à lire la documentation et à effectuer 122 appels d’outils pour obtenir des éclaircissements. Il a ensuite généré 15 sessions enfants, chacune créant son propre arbre de travail et son propre agent. Ensuite, ils ont commencé à communiquer entre eux.

Grâce à une compétence d’orchestration intégrée, une session a trouvé toutes les autres sessions actives et a envoyé des messages à ceux dont les missions se chevauchaient, demandant une coordination.

Le compilateur est un enseignant, pas un oracle

Compte tenu de ses avantages en termes de performances, Rust s’est avéré être un langage populaire pour la réécriture d’applications. Le créateur de Bun, Jarred Sumner, par exemple, a récemment porté sur Rust le moteur d’exécution et la boîte à outils JavaScript appartenant à Anthropic, qui contenait environ 535 000 lignes de code Zig, presque entièrement en utilisant les agents Claude. Au 30 juillet, le portage expérimental de Rust réussissait 99,8 % des tests existants de Bun sur la glibc Linux x64, les versions stables étant toujours expédiées à partir de la base de code Zig.

Ce travail a coûté 165 000 $ en jetons.

Mais l’utilisation de Rust comporte également des dangers cachés, comme Toub l’a découvert.

Pour un LLM comme pour un programmeur paresseux, si le code se compile, alors c’est Rust valide.

Mais tout au long du processus, le projet a rencontré des dizaines de régressions au sein du code. Une régression est quelque chose qui fonctionnait auparavant, mais qui ne fonctionne plus après une mise à jour.

Le compilateur n’a aucune idée, par exemple, si les fonctions sont dans le bon ordre, si le travail se termine à un coût acceptable, s’il répond aux exigences non écrites du développeur, ou s’il est cohérent en interne, d’ailleurs.

Lors de la RustConf, qui s’est tenue à Montréal la semaine dernière, la consultante Lisa Crossman a mis en garde contre la pratique consistant à traiter le compilateur comme un « oracle », ou le dernier mot quant à la validité ou non d’un code Rust. « Rust empêche l’agent d’écrire du code non sécurisé pour la mémoire ; cela n’empêche pas l’agent d’écrire correctement le mauvais programme », a-t-elle déclaré.

S’il est sage, un développeur humain traite le compilateur comme un enseignant, décodant les erreurs comme un chemin vers une meilleure compréhension du domaine du langage. Un LLM, en revanche, utilise simplement le compilateur comme une boîte noire, qu’il peut utiliser avec des solutions de contournement brutales et inefficaces jusqu’à ce que l’une d’elles réussisse (c’est peut-être ce que le créateur de Zig, Andrew Kelley, voulait dire lorsqu’il a appelé le code Rust de Bun « slop non révisé »).

Dans le cas de Toub, il avait découvert que les régressions approuvées par le compilateur pouvaient provenir d’une sémantique et de comportements ambigus, d’une dérive de branche, de fonctionnalités manquantes qui n’avaient pas été portées et de comportements différents du code de remplacement.

« Ce n’est en aucun cas un argument contre le compilateur de Rust », a écrit Toub. « Mais ‘si ça compile, c’est correct’ n’est utile qu’en plaisantant. » ®