Buns KI-Umschreibung entfacht Sprachkrieg

Bun vollbrachte eine unmögliche Leistung: eine 500.000 Zeilen Code umfassende Umschreibung von Zig nach Rust, die in erstaunlichen 11 Tagen abgeschlossen wurde. Zwischen dem 3. und 14. Mai generierte dieses schnelle Refactoring über 6.500 Commits und veränderte eine Hochleistungs-JavaScript-Laufzeitumgebung grundlegend. Dieses schnelle, massive Unterfangen signalisiert eine neue Ära für die groß angelegte Softwareentwicklung und verschiebt die Grenzen des Möglichen.

Diesem beispiellosen Sprint lagen chronische Stabilitätsprobleme zugrunde, die der Zig-Codebasis von Bun eigen waren. Die Prinzipien der manuellen Speicherverwaltung von Zig kollidierten grundlegend mit dem Garbage Collector von JavaScriptCore, wodurch eine volatile Umgebung entstand. Diese Interaktion führte zu hartnäckigen Speicherfehler wie use-after-free und double-free-Fehlern, die Buns Kernversprechen von Geschwindigkeit und Zuverlässigkeit untergruben. Rusts borrow checker bietet nun eine Kompilierungszeitgarantie, die diese kritischen Probleme verhindert, bevor sie jemals die Produktion erreichen.

Künstliche Intelligenz trieb diese gesamte Transformation voran und demonstrierte ein neues Paradigma für das Engineering. Der KI-gestützte Prozess, der 64 gleichzeitige Claude-Instanzen und eine Vorabversion von Fable 5 nutzte, erreichte einen Spitzenwert von 58 Commits pro Minute. Diese beispiellose Automatisierung kostete schätzungsweise 165.000 US-Dollar an API-Tokens. Diese Investition stellt nur einen Bruchteil der Kosten für ein Team aus mehreren Ingenieuren dar, das ein Jahr lang arbeitet, wodurch eine manuelle Umschreibung dieses Umfangs wirtschaftlich undurchführbar und wahrscheinlich nie versucht worden wäre. Die schiere wirtschaftliche Effizienz und Geschwindigkeit stellen traditionelle Entwicklungsmodelle in Frage.

Das Team von Bun setzte eine Armee von KI-Code-Agenten ein und entwickelte einen ausgeklügelten Workflow rund um eine Vorabversion von Fable 5. Dieses System orchestrierte bis zu 64 Claude-Instanzen gleichzeitig und trieb die Umschreibung mit beispielloser Parallelisierung voran. Es ist ein vielversprechender Einblick in die zukünftige Softwareentwicklung im großen Maßstab, wo KI sowohl als Architekt als auch als Arbeiter fungiert und mit Geschwindigkeiten arbeitet, von denen menschliche Teams nur träumen können.

Der Kern dieses KI-gesteuerten Prozesses war eine robuste "implementer-reviewer-fixer"-Schleife. Ein einzelner Agent führte die anfängliche Rust-Portierung durch und generierte den neuen Code. Diese Ausgabe wurde dann von zwei unabhängigen, adversariellen Agenten geprüft, die den Code-Diff akribisch auf Fehler und Inkonsistenzen überprüften und als automatisierte Qualitätstore fungierten. Ein letzter Agent synthetisierte und wandte dann deren vorgeschlagene Korrekturen an, um eine mehrschichtige Verifizierung sicherzustellen, bevor Änderungen übernommen wurden.

Die anfängliche Bereitstellung führte zu vorhersehbarem, KI-induziertem Chaos. Agenten, die unabhängig voneinander über vier Git-Worktrees hinweg arbeiteten, führten widersprüchliche Git-Befehle wie `git stash` und `git reset HEAD --hard` aus und kämpften im Wesentlichen um das Repository. Prompt-Verfeinerungen lösten dies schnell, indem sie die Agenten anwiesen, alle Git- oder langsamen `cargo`-Befehle zu vermeiden, die nicht direkt mit dem Committen von Änderungen zusammenhängen.

Weitere Herausforderungen ergaben sich, als Agenten begannen, Funktionen zu stubben, um die Kompilierung zu erreichen, oder fragwürdige Workarounds mit seitenlangen Kommentaren zu rechtfertigen. Jarred Sumner begegnete dem, indem er eine entscheidende Regel für die adversariellen Prüfer einbettete: lehne jeden Code ab, der übermäßige Kommentare zur Rationalisierung eines Workarounds erfordert. Dies zwang die KI, sauberere, robustere Lösungen zu produzieren und grundlegende Korrekturen gegenüber oberflächlicher Konformität zu priorisieren.

Die anfängliche KI-Ausgabe, obwohl umfangreich, ließ sich nicht kompilieren. Jarred Sumner befasste sich zunächst mit einer grundlegenden architektonischen Diskrepanz: Buns ursprüngliche Zig-Codebasis funktionierte als eine einzige Kompilierungseinheit, aber das Team zielte auf 100 Rust-Crates ab, um die Kompilierungsgeschwindigkeit zu verbessern. Dies erforderte ein komplexes Refactoring, um zyklische Abhängigkeiten zu eliminieren, ein Konzept, das Zig weitgehend ignoriert. KI-Workflows klassifizierten und führten dieses komplexe Refactoring dann aus und legten damit den Grundstein.

Diese strukturelle Überarbeitung deckte sofort etwa 16.000 Compilerfehler auf. Ein dedizierter KI-Agentenschwarm, der das anfängliche Code-Generierungs-Setup widerspiegelte, ging diese methodisch an. Agenten iterierten Crate für Crate, führten `cargo check` aus, identifizierten Fehler und schlugen Korrekturen vor. Zwei gegnerische Agenten überprüften jeden Vorschlag und stellten die Codequalität sicher, bevor ein Fixer-Agent die Änderungen anwandte, wodurch das gesamte Projekt schließlich in einen kompilierbaren Zustand versetzt wurde.

Ein sauberer Kompilierungsvorgang war nur die halbe Miete; Buns umfangreiche Testsuite blieb bestehen. Agenten begaben sich dann in einen unerbittlichen Debugging-Zyklus, der sich auf fehlerhafte Stack-Traces konzentrierte, um Laufzeitprobleme zu lokalisieren und zu beheben. Dieser letzte Vorstoß führte dazu, dass alle 972 zuvor fehlgeschlagenen Testdateien unter Linux, macOS und Windows grün wurden, was den erfolgreichen Abschluss einer beispiellosen Ingenieursleistung markierte. Für alternative Perspektiven zu den Motivationen des Rewrites sind Andrew Kelleys Einblicke in My Thoughts on the Bun Rust Rewrite verfügbar.

Andrew Kelley, der Schöpfer von Zig, nahm kein Blatt vor den Mund. Sein explosiver Blogbeitrag argumentierte, dass Buns monumentaler Rewrite kein technisches Gebot, sondern vielmehr ein „Beziehungszusammenbruch“ sei. Kelley behauptete, dass Buns Codebasis „Hacks auf Hacks“ darstellte und sich nicht an Zigs etablierte Best Practices für Speicherverwaltung und Bereinigung hielt. Er bemerkte, dass Zig erwartet, dass die Bereinigung an jeder Aufrufstelle explizit mit `defer` ausgeschrieben wird, eine Praxis, die Bun angeblich übersehen hat.

Kelley vertrat die Ansicht, dass Buns wahrgenommene Stabilitätsprobleme, wie Use-after-free- oder Double-free-Fehler, mit konzentriertem Ingenieuraufwand lösbar wären und nicht durch einen radikalen Sprachwechsel zu Rust. Er kritisierte Jarred Sumners Führungsstil direkt, verlieh der technischen Debatte eine scharfe menschliche Note und verwies dabei auf „geschmacklose KI-Enthusiasten“.

Eine zentrale Frage von Kelley stellte die Prämisse des Rewrites in Frage: Wenn Buns Testsuite robust genug war, um eine Million Zeilen KI-generierten Codes zu validieren, warum reichte sie dann nicht aus, um die Fehler in der ursprünglichen Zig-Implementierung zu finden? Diese gezielte Untersuchung unterstrich die tiefe ideologische Kluft und verwandelte eine technische Migration in einen ausgewachsenen Sprachenkrieg mit erheblichen Auswirkungen auf Entwickler-Ökosysteme.

Warum hat Bun seine Codebasis von Zig auf Rust umgestellt?

Der Hauptgrund war Stabilität. Buns Team kämpfte mit Speichersicherheitsfehlern wie Use-after-free und Double-free, die aus Zigs manueller Speicherverwaltung in Interaktion mit JavaScriptCores Garbage Collector resultierten. Rusts Compile-Time Borrow Checker automatisiert die Speichersicherheit und eliminiert diese gesamte Fehlerklasse.

Wie genau haben KI-Agenten Buns Code neu geschrieben?

Buns Schöpfer, Jarred Sumner, verwendete eine Vorabversion von Fable 5, um 64 Claude-Instanzen zu orchestrieren. Er entwarf einen agentenbasierten Workflow, bei dem ein KI-Agent den Rust-Code schrieb, zwei „gegnerische“ Agenten den Code auf Fehler überprüften und ein letzter „Fixer“-Agent die Vorschläge vor dem Commit anwandte.

Was war Andrew Kelleys (Zig-Schöpfer) Hauptkritik am Rewrite?

Andrew Kelley argumentierte, dass die Neufassung keine rein technische Entscheidung war, sondern das Ergebnis eines „Beziehungszusammenbruchs“. Er behauptete, Buns Codebasis sei voller „Hacks auf Hacks“, kritisierte Jarred Sumners Managementstil und argumentierte, dass Bun nie die richtigen technischen Ressourcen für die Behebung von Fehlern in der Zig-Version bereitgestellt habe.

War die Neufassung in Rust für Bun erfolgreich?

Ja. Die Rust-Version von Bun ist 20 % kleiner, 2-5 % schneller und weist dramatisch weniger Speicherlecks auf. Obwohl die Neufassung 19 neue Regressionen einführte, wurden diese schnell behoben. Das Projekt behob dabei 128 bekannte Fehler und legte ein stabileres Fundament für die zukünftige Entwicklung.