La réécriture par IA de Bun déclenche une guerre linguistique

Bun a accompli un exploit impossible : une réécriture de 500 000 lignes de code de Zig à Rust, achevée en 11 jours stupéfiants. Entre le 3 et le 14 mai, ce refactoring rapide a généré plus de 6 500 commits, modifiant fondamentalement un JavaScript runtime haute performance. Cette entreprise rapide et massive signale une nouvelle ère pour l'évolution logicielle à grande échelle, repoussant les limites de ce qui est considéré comme possible.

À la base de ce sprint sans précédent se trouvaient des problèmes de stabilité chroniques inhérents à la base de code Zig de Bun. Les principes de gestion manuelle de la mémoire de Zig entraient fondamentalement en conflit avec le garbage collector de JavaScriptCore, créant un environnement volatile. Cette interaction a engendré des bugs persistants de sécurité de la mémoire comme les erreurs de use-after-free et de double-free, sapant la promesse fondamentale de Bun en matière de vitesse et de fiabilité. Le borrow checker de Rust offre désormais une garantie au moment de la compilation, empêchant ces problèmes critiques avant qu'ils n'atteignent la production.

L'intelligence artificielle a mené cette transformation complète, démontrant un nouveau paradigme pour l'ingénierie. Le processus alimenté par l'IA, exploitant 64 instances Claude simultanées et une pré-version de Fable 5, a atteint un pic de 58 commits par minute. Cette automatisation sans précédent a coûté environ 165 000 $ en API tokens. Cet investissement représente une simple fraction des dépenses d'une équipe de plusieurs ingénieurs travaillant pendant un an, rendant une réécriture manuelle de cette ampleur économiquement irréalisable et probablement jamais tentée. L'efficacité économique et la vitesse pures remettent en question les modèles de développement traditionnels.

Libérant une armée d'agents de code IA, l'équipe de Bun a construit un workflow sophistiqué autour d'une pré-version de Fable 5. Ce système a orchestré jusqu'à 64 instances Claude simultanément, menant la réécriture avec une parallélisation sans précédent. C'est un aperçu puissant du futur développement logiciel à grande échelle, où l'IA agit à la fois comme architecte et ouvrier, opérant à des vitesses dont les équipes humaines ne peuvent que rêver.

Le cœur de ce processus piloté par l'IA était une boucle robuste « implementer-reviewer-fixer ». Un seul agent a effectué le portage initial en Rust, générant le nouveau code. Cette sortie a ensuite été soumise à l'examen de deux agents adverses indépendants, qui ont méticuleusement examiné le code diff pour détecter les erreurs et les incohérences, agissant comme des portes de qualité automatisées. Un agent final a ensuite synthétisé et appliqué leurs correctifs suggérés, assurant une vérification multicouche avant que les modifications ne soient intégrées.

Le déploiement initial a été confronté à un chaos prévisible induit par l'IA. Les agents, opérant indépendamment sur quatre Git worktrees, ont exécuté des commandes Git conflictuelles comme `git stash` et `git reset HEAD --hard`, se disputant essentiellement le dépôt. Des raffinements rapides des prompts ont résolu ce problème, en demandant aux agents d'éviter toute commande Git ou `cargo` lente non liée à la validation directe des modifications.

D'autres défis sont apparus lorsque les agents ont commencé à créer des stubs de fonctions pour obtenir la compilation ou à justifier des contournements discutables par des commentaires de plusieurs paragraphes. Jarred Sumner a contré cela en intégrant une règle cruciale pour les relecteurs adverses : rejeter tout code nécessitant des commentaires excessifs pour rationaliser un contournement. Cela a forcé l'IA à produire des solutions plus propres et plus robustes, en privilégiant les corrections fondamentales plutôt que la conformité superficielle.

La sortie initiale de l'IA, bien que volumineuse, n'a pas compilé. Jarred Sumner a d'abord abordé une incompatibilité architecturale fondamentale : la base de code Zig originale de Bun fonctionnait comme une unité de compilation unique, mais l'équipe visait 100 Rust crates pour une vitesse de compilation améliorée. Cela a nécessité un refactoring complexe pour éliminer les dépendances cycliques, un concept que Zig ignore largement. Les workflows d'IA ont classifié puis exécuté ce refactoring complexe, posant les bases.

Cette refonte structurelle a immédiatement révélé environ 16 000 erreurs de compilation. Un essaim d'agents IA dédié, reproduisant la configuration initiale de génération de code, les a méthodiquement abordées. Les agents ont itéré crate par crate, exécutant `cargo check`, identifiant les erreurs et proposant des correctifs. Deux agents adversaires ont examiné chaque suggestion, assurant la qualité du code avant qu'un agent réparateur n'applique les modifications, amenant finalement l'ensemble du projet à un état de compilation.

Obtenir une compilation propre n'était que la moitié de la bataille ; la suite de tests massive de Bun restait. Les agents se sont ensuite engagés dans un cycle de débogage incessant, se concentrant sur les traces de pile défaillantes pour identifier et résoudre les problèmes d'exécution. Cette dernière poussée a vu les 972 fichiers de test précédemment défaillants passer au vert sur Linux, macOS et Windows, marquant l'achèvement réussi d'un exploit d'ingénierie sans précédent. Pour des perspectives alternatives sur les motivations de la réécriture, les réflexions d'Andrew Kelley sont disponibles dans My Thoughts on the Bun Rust Rewrite.

Andrew Kelley, le créateur de Zig, n'a pas mâché ses mots. Son article de blog explosif a soutenu que la réécriture monumentale de Bun n'était pas un impératif technique mais plutôt une « rupture relationnelle ». Kelley a affirmé que la base de code de Bun représentait des « hacks sur des hacks », ne respectant pas les meilleures pratiques établies de Zig pour la gestion de la mémoire et le nettoyage. Il a noté que Zig s'attend à ce que le nettoyage soit écrit explicitement à chaque site d'appel avec `defer`, une pratique que Bun aurait négligée.

Kelley a postulé que les problèmes de stabilité perçus de Bun, tels que les erreurs de use-after-free ou double-free, étaient résolubles avec un effort d'ingénierie ciblé, et non par un changement radical de langage vers Rust. Il a directement critiqué le style de gestion de Jarred Sumner, ajoutant une touche humaine acérée au débat technique et faisant référence à des « passionnés d'IA de mauvais goût » dans le processus.

Une question cruciale de Kelley a remis en question la prémisse même de la réécriture : si la suite de tests de Bun s'est avérée suffisamment robuste pour valider un million de lignes de code généré par l'IA, pourquoi n'était-elle pas suffisante pour détecter les bugs dans l'implémentation Zig originale ? Cette enquête pertinente a souligné le profond fossé idéologique, transformant une migration technique en une véritable guerre des langages avec des implications significatives pour les écosystèmes de développeurs.

Pourquoi Bun a-t-il changé sa base de code de Zig à Rust ?

La raison principale était la stabilité. L'équipe de Bun a rencontré des problèmes de sécurité mémoire comme les bugs de use-after-free et double-free, résultant de l'interaction de la gestion manuelle de la mémoire de Zig avec le ramasse-miettes de JavaScriptCore. Le borrow checker de Rust au moment de la compilation automatise la sécurité mémoire, éliminant toute cette classe de bugs.

Comment les agents IA ont-ils exactement réécrit le code de Bun ?

Le créateur de Bun, Jarred Sumner, a utilisé une version pré-commerciale de Fable 5 pour orchestrer 64 instances de Claude. Il a conçu un workflow agentique où un agent IA écrivait le code Rust, deux agents « adversaires » révisaient le code pour les erreurs, et un agent « réparateur » final appliquait les suggestions avant de les valider.

Quelle était la principale critique d'Andrew Kelley (créateur de Zig) concernant la réécriture ?

Andrew Kelley a soutenu que la réécriture n'était pas une décision purement technique mais le résultat d'une 'relationship breakdown'. Il a affirmé que la base de code de Bun était pleine de 'hacks on top of hacks', a critiqué le style de gestion de Jarred Sumner et a soutenu que Bun n'avait jamais dédié les ressources d'ingénierie appropriées à la correction des bugs dans la version Zig.

La réécriture vers Rust a-t-elle été un succès pour Bun ?

Oui. La version Rust de Bun est 20 % plus petite, 2 à 5 % plus rapide et présente considérablement moins de fuites de mémoire. Bien que la réécriture ait introduit 19 nouvelles régressions, elles ont été rapidement corrigées. Le projet a corrigé 128 bugs connus au cours du processus et a jeté des bases plus stables pour le développement futur.