L'ingénieur de GitHub Stephen Toub a publié, le 16 septembre, un retour d'expérience sur une réécriture à grande échelle menée par l'agent Copilot : le runtime de l'agent Copilot a été entièrement converti de TypeScript/Node.js vers Rust. Les quelque 430 000 lignes initiales de TypeScript en production se sont transformées, au final, en 832 378 lignes de Rust en production, auxquelles s'ajoutent 468 000 lignes de tests unitaires Rust et 174 000 lignes de tests de bout en bout.
Le projet s'est déroulé du 12 mai au 21 août, soit environ 14,5 semaines. Durant cette période, 128 pull requests ont été fusionnées de manière incrémentale sur la branche main, avec des publications continues : au total 135 versions (100 pré-versions, 35 versions stables), soit une moyenne d'environ 1,3 par jour.
L'essentiel du code a été écrit par le modèle — que reste-t-il à l'humain ?
Le jugement de Toub sur cette expérience est sans détour :
"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."
Un projet qui, avant l'ère des agents, aurait nécessité toute une équipe de développeurs pendant un à deux ans a désormais été mené à bien principalement par un seul développeur, en quelques mois seulement.
Les modèles principaux utilisés étaient Claude Opus 4.8, GPT-5.6 Sol ainsi que la série Claude Haiku ; les sous-agents chargés de l'optimisation du débit privilégiaient Opus 4.8 et GPT-5.6 Sol. On y voit un signal révélateur : pour cette réécriture de niveau production de son propre composant, GitHub (filiale de Microsoft) a principalement fait appel aux modèles de son concurrent Anthropic, et non exclusivement à ceux d'OpenAI.
Le rôle de l'humain a été clairement délimité. Dans les interactions de cet ingénieur principal, 31 % du temps a été consacré à « la relecture, les tests et l'intégration continue », 17,4 % à « remettre en question les décisions techniques » et 15 % à « pousser pour que le travail soit vraiment terminé ». Le dernier mot sur l'architecture, les arbitrages de conception et les fusions finales est toujours resté entre les mains de l'humain. Le modèle s'est chargé du volume de code, l'humain de la direction et de la validation.
Validation via les tests existants, une cinquantaine d'accrocs
Cette réécriture n'a pas mis en place de nouveaux critères d'acceptation ; elle s'est appuyée sur les tests de bout en bout déjà existants, exécutés en continu sur le nouveau code Rust, avec une mise en production incrémentale afin que les régressions apparaissent sur un périmètre restreint et soient détectées tôt. Quelques chiffres techniques du processus sont également éclairants : le taux de succès du cache de prompts a atteint 96,22 %, et la compression de contexte a été déclenchée 5 116 fois sur l'ensemble des sessions.
Les accrocs ont eux aussi été consignés honnêtement. Sur l'ensemble du projet, on dénombre une cinquantaine de problèmes connus, répartis en cinq catégories : migration incomplète, problèmes d'état et de cycle de vie, incohérences du contrat comportemental, problèmes aux frontières avec l'hôte, et attentes de tests mal formulées dès le départ. La grande majorité a été corrigée avant le passage en version stable. Cette dernière catégorie mérite une attention particulière pour quiconque mène une migration : lorsqu'on utilise d'anciens tests pour valider une nouvelle implémentation, c'est parfois le test qui est en tort, pas le nouveau code.
Ce que cela signifie pour les équipes d'ingénierie
Des cas concrets comme celui-ci, où une entreprise utilise l'IA pour refondre entièrement l'un de ses propres composants centraux, en disent plus sur les limites réelles des agents de programmation actuels que n'importe quel classement de benchmarks. Trois enseignements sont directement transposables : d'abord, ne pas s'attendre à une réécriture en une seule fois — les 128 pull requests fusionnées de façon incrémentale et les multiples publications quotidiennes ne fonctionnent que grâce à l'intégration continue, qui répartit le risque ; ensuite, les critères d'acceptation doivent être fixés à l'avance — ici, tout reposait sur les tests E2E existants comme référence, et sans cette référence, impossible de juger si le modèle a « bien écrit » le code ; enfin, l'effort humain s'est déplacé de l'écriture de code vers la relecture, la prise de décision et la détection des manques, ce qui multiplie d'un ordre de grandeur l'échelle de réécriture qu'une seule personne peut superviser.
Un bémol à retenir : les gains d'architecture (intégration dans le même processus, empreinte mémoire réduite, démarrage plus rapide) ne sont décrits que qualitativement dans le texte original, sans chiffres avant/après sur la mémoire, la latence ou le débit. Le gain de performance réel apporté par la réécriture ne peut, pour l'instant, pas être vérifié à partir de ce retour d'expérience. Le passage de TypeScript à Rust n'est pas non plus la norme pour la plupart des équipes : il ne fonctionne que si l'on dispose déjà d'une suite de tests solide et d'une volonté de publier chaque jour.
Sources: GitHub Blog (Stephen Toub), CocoLoop ; les chiffres de 832 000 lignes, 128 pull requests, 14,5 semaines, taux de succès de cache de 96,22 % et une cinquantaine de problèmes connus ont été vérifiés à partir du retour d'expérience officiel.