Ce que l’on peut apprendre de la réécriture Zig→Rust de Bun achevée en 11 jours avec l’IA

• Après des fuites et des plantages récurrents dus à l’absence de sûreté mémoire de Zig, Bun a migré 535 496 lignes de code vers Rust avec 64 agents IA, ramenant à 11 jours un travail qui aurait pris 1 à 2 ans
• Le point de départ du succès a été un PORTING.md de 600 lignes ; la conversion parallèle fichier par fichier a été suivie, dans l’ordre, de deux revues contradictoires, de la correction des erreurs de compilation, de tests locaux puis du passage de la CI
• Pour produire 6 500 commits, le coût au tarif API a été de 165 000 dollars, avec 5,9 milliards de tokens d’entrée non mis en cache, 690 millions de tokens de sortie et 72 milliards de lectures de tokens d’entrée en cache
• En manuel, l’équipe estime que 3 ingénieurs connaissant bien la base de code auraient dû interrompre pendant environ un an les améliorations produit, les corrections de bugs et de sécurité, ainsi que le développement de nouvelles fonctionnalités, rendant la réécriture elle-même difficile à justifier
• Pour reproduire la même approche, il faut des ingénieurs qui comprennent profondément la base de code, une suite de tests robuste permettant de faire confiance aux résultats, et la volonté d’assumer le coût en tokens même si le succès est incertain

---

Pourquoi Bun a choisi une réécriture en Rust

• Bun est un projet de production complexe qui va au-delà d’un simple runtime JavaScript
  • Transformation de JavaScript, TypeScript et CSS, bundling, minification
  • Runner de tests et gestionnaire de paquets compatible npm
  • Résolution de modules, client WebSocket, implémentation de Node.js et plusieurs modules
• Il compte 22 millions de téléchargements mensuels ; Claude Code et OpenCode en dépendent, et Vercel, Railway et DigitalOcean le prennent directement en charge
• Zig n’étant pas un langage à sûreté mémoire, même les versions récentes de Bun continuaient de connaître des fuites mémoire, des plantages liés à la mémoire et des écritures hors limites du tas
  • L’équipe Bun a patché le compilateur Zig et introduit des tests de fuite mémoire de bout en bout, sans parvenir à éliminer le problème
  • La gestion conjointe de la durée de vie de valeurs soumises au garbage collector et de valeurs gérées manuellement provoquait de petites fuites et des plantages intermittents
  • Pour chaque allocation mémoire, il fallait vérifier l’endroit de libération, les doubles libérations éventuelles, la gestion des exceptions JavaScript et la visibilité des pointeurs par le scanner de pile conservateur
• En Rust sûr, les use-after-free et double-free deviennent des erreurs de compilation, et les oublis de libération dans les chemins d’erreur peuvent être pris en charge par le nettoyage automatique basé sur Drop
• L’équipe a aussi envisagé d’introduire ses propres pointeurs intelligents à la Rust dans le code de Bun, mais ils auraient été moins ergonomiques que Rust sans offrir les mêmes garanties

Pourquoi les projets de réécriture existants prennent longtemps

• Pendant une réécriture, de nouvelles fonctionnalités continuent d’être ajoutées à la base de code d’origine, ce qui tend à repousser la date d’achèvement à répétition
  • Un travail estimé à 9 mois peut encore nécessiter environ 6 mois supplémentaires au bout de ces 9 mois
  • Après 15 mois, il peut encore rester plusieurs mois de travail pour rattraper les nouvelles fonctionnalités
  • Même avec de la chance, il faut geler les fonctionnalités pendant 2 mois et terminer au bout d’environ 18 mois ; une estimation initiale de 9 mois peut s’étirer à plus de 2 ans
• Le code Zig de Bun, hors commentaires, représente 535 496 lignes ; une petite équipe d’ingénieurs aurait probablement eu besoin d’environ un an pour le porter vers un autre langage
• Comme passer un an sans amélioration visible pour les utilisateurs n’était pas réaliste, l’équipe a décidé de tester avec Fable si un portage vers Rust était vérifiable en moins d’une semaine

Conception et validation préalables du portage

• Dans une première étape, l’équipe a discuté avec Claude pendant environ 3 heures de la façon de faire correspondre les patterns Zig à des équivalents proches de Rust, puis a synthétisé le tout dans un PORTING.md de 600 lignes
• Les consignes de portage contenaient des restrictions précises visant à préserver la structure d’exécution existante de Bun
  • Ne pas utiliser tokio, rayon, hyper, async-trait ni futures
  • Interdire les modules qui accèdent aux E/S, comme std::fs, std::net et std::process
  • Comme Bun possède sa propre boucle d’événements et ses propres appels système, utiliser des callbacks et des machines à états comme dans le Zig existant plutôt que async fn
  • En cas de conflit avec le borrow checker, stocker les valeurs scalaires nécessaires dans des variables locales, mettre fin à l’emprunt, puis emprunter à nouveau
  • Interdire l’utilisation de pointeurs bruts pour contourner le borrow checker, et laisser des notes de portage aux endroits où la structure a été modifiée
• Sur les 1 448 fichiers au total, 3 fichiers ont d’abord été réécrits, puis Claude les a examinés deux fois de manière contradictoire dans des sessions séparées des modifications

Travail parallèle de 64 agents IA

• Le travail a été découpé pour que les fichiers puissent être traités indépendamment, avec 64 agents IA exécutés en parallèle
• Au début, plusieurs agents modifiaient le même état du dépôt, ce qui provoquait des conflits
  • Un agent exécutait git stash, puis un autre exécutait git stash pop et git reset HEAD --hard
  • Attribuer un worktree distinct à chaque agent saturait l’espace disque en raison de la taille du dépôt Bun, et il fallait de toute façon compiler les changements ensemble
• Le workflow a été corrigé en interdisant les commandes Git comme git stash et git reset, sauf la commande qui committait immédiatement un fichier précis, ainsi que cargo et les commandes longues à exécuter
• Au final, le travail a été réparti sur 4 worktrees, chacun configuré pour que 16 instances de Claude committent et poussent les fichiers
• En deux jours, les agents ont porté 535 496 lignes de code Zig, et chaque commit a fait l’objet de deux revues contradictoires avant d’être intégré

Correction des erreurs de compilation et des tests

• La conversion initiale était terminée, mais le code ne compilait pas ; Claude a donc corrigé les erreurs crate par crate, l’unité de compilation de plus haut niveau en Rust
• Le titre de l’étape mentionne environ 1 600 erreurs de compilation, mais la citation indique qu’environ 16 000 erreurs sont apparues lors de la résolution des dépendances cycliques
• Le processus de correction a lui aussi été parallélisé
  • Exécuter cargo check dans chaque crate
  • Regrouper la sortie par fichier et enregistrer les fichiers d’erreurs
  • Corriger toutes les erreurs de compilation de la crate concernée
  • Faire vérifier les changements par deux relecteurs contradictoires
  • Faire intégrer les résultats de la revue par un agent chargé des corrections
• Les agents ont corrigé les erreurs de compilation sans intervention humaine de minuit à 11 h 30
• Ensuite, il a fallu environ deux jours supplémentaires pour pouvoir exécuter localement la vaste suite de tests sans erreur de compilation, puis plusieurs jours de plus pour corriger les tests en échec et faire passer la CI
• Une fois tous les tests passés et le comportement vérifié, les changements ont été fusionnés ; 11 jours se sont écoulés entre la planification et l’achèvement
  • Environ 550 000 lignes de code portées
  • 6 500 commits
  • 64 agents utilisés

Coûts et comparaison avec un travail manuel

• Au tarif de l’API Fable, le coût total de la réécriture a été de 165 000 dollars
  • 5,9 milliards de tokens d’entrée non mis en cache
  • 690 millions de tokens de sortie
  • 72 milliards de lectures de tokens d’entrée en cache
• Anthropic vend les tokens API avec une marge, donc son coût interne réel est inférieur
• Le coût API est comparable au salaire de base annuel d’un ingénieur logiciel intermédiaire dans une entreprise américaine, mais l’équipe estime qu’un ingénieur à ce niveau de rémunération n’aurait pas pu produire le même résultat en 11 jours
• Cela rejoint l’évaluation de Mitchell Hashimoto selon laquelle Fable excelle particulièrement dans les tâches difficiles et très ciblées avec une fonction de récompense claire
• En manuel, l’équipe estime qu’il aurait fallu 3 ingénieurs connaissant parfaitement la base de code pendant environ un an
  • Pendant ce temps, il aurait été difficile d’améliorer la compatibilité Node.js, de corriger les bugs et problèmes de sécurité, et d’implémenter de nouvelles fonctionnalités
  • L’alternative réaliste aurait été de ne pas réécrire et de continuer à corriger les bugs mémoire existants

Conditions pour l’appliquer à d’autres projets

• Si l’IA ramène au niveau d’une semaine une réécriture ou une migration qui aurait pris un an, des projets auparavant difficiles à envisager deviennent exécutables
• Pour réutiliser le workflow de Bun, trois conditions sont nécessaires
  • Des ingénieurs qui connaissent très bien la base de code et sont fortement motivés pour faire le travail
  • Une suite de tests assez robuste pour que le passage des tests soit une preuve fiable du bon fonctionnement réel
  • La volonté d’investir un coût important en tokens sans savoir à l’avance si l’opération réussira
• Les tâches répétitives comme les migrations de code sont relativement bien prises en charge par les LLM ; avec de bons tests et des ingénieurs capables de structurer le problème, les chances de succès sont élevées
• Tous les projets n’ont pas besoin de 165 000 dollars
  • Un projet plus simple peut coûter moins cher
  • Les modèles les plus chers peuvent être réservés à la planification de haut niveau, tandis que des modèles moins coûteux peuvent être affectés au codage et à la revue
• Les migrations fondées sur l’IA deviennent plus rapides, mais une telle vitesse n’est atteignable que dans des projets bien conçus comme Bun