Bun 1.4 bringt den KI-getriebenen Rust-Rewrite in Produktion

Bun hat am 20. August 2026 Version 1.4 seiner JavaScript-Laufzeitumgebung veröffentlicht - das erste Produktionsrelease, seit das Projekt seinen Kern von Zig nach Rust umgeschrieben hat. Für Entwickler, die über ein Upgrade entscheiden, erzählen die Release Notes eine Geschichte - durchweg schneller und schlanker -, während zwei unabhängige Analysen der neuen Codebasis eine andere erzählen: Der Großteil dieses Rust-Codes wurde von KI-Agenten geschrieben und geprüft, und er stützt sich weit häufiger auf unsafe als vergleichbare Rust-Projekte.

Was im Release steckt

Die Schlagzahlen im Bun-Blog betreffen Start und Ressourcenverbrauch. Die Startzeit sinkt auf 5,1 ms unter Linux und 15,5 ms unter Windows - unter Windows eine 2,5-fache Verbesserung -, die CPU-Last im Leerlauf fällt um das Fünffache, HTTP-Server brauchen 13-48% weniger Speicher, das Server-Side-Rendering von Next.js bleibt nun bei 238 MB stabil, wo es zuvor unbegrenzt wuchs, und die Binärdatei ist unter Linux und Windows 17% kleiner.

Das Release integriert außerdem mehrere verbreitete Abhängigkeiten direkt in die Runtime, so das Bun-Blog:

Neue API	Was das Bun-Blog verspricht
Bun.Image	Eingebaute Bildverarbeitung, 1,38-mal schneller als sharp
Bun.WebView	Headless-Browser-Automatisierung, schneller als Puppeteer
Bun.markdown	Eingebautes Markdown-Parsing
Bun.cron()	Zeitplanung auf OS-Ebene direkt aus der Runtime
Bun.Terminal	Native PTY-Unterstützung

Zur Kompatibilität heißt es im Beitrag, 1.517 zusätzliche Tests aus Node.js' eigener Suite liefen nun durch, was Module wie Playwright, Next.js 16 und vitest freischalte, und Buns React-Compiler-Implementierung sei 19-mal schneller als die Babel-Plugin-Variante.

Der Rewrite dahinter

Das Bun-Blog beschreibt den Wechsel in einem Satz: Die Runtime "wurde von Zig nach Rust umgeschrieben; dies ist das erste Produktionsrelease dieses Rewrites nach monatelangen Tests in Claude Code und Prisma Compute". Wer - oder was - den Code umgeschrieben hat, sagt der Beitrag nicht.

Eine auf grigio.org veröffentlichte Analyse füllt diese Lücke: Die Portierung übersetzte in sechs Tagen rund 570.000 Zeilen Zig in 682.000 Zeilen Rust, erledigt von KI-Agenten, wobei 99,8% der Testsuite bereits mit der ersten generierten Fassung bestanden. Das Code-Review übernahmen derselben Analyse zufolge KI-Reviewer - claude[bot] und coderabbitai[bot] -, ein menschliches Review der gesamten Codebasis gab es nicht, und einige fehlschlagende Tests wurden passend gemacht, statt die Implementierung zu korrigieren.

Der Gegenwind

Der Entwickler Tero Piirainen hat die Zahlen zusammengetragen, die die Skepsis befeuern: Über 15.800 Commits im Bun-Repository stammen von robobun, einem Claude-getriebenen Automatisierungskonto, gegenüber 790 vom menschlichen Lead-Entwickler, und mehr als 5.000 Pull Requests stehen offen. Die drei Monate bis zu diesem stabilen Release waren die längste Pause des Projekts seit 2022.

Die schärfste Kritik betrifft die Speichersicherheit - die erklärte Begründung für den Abschied von Zig. Die Analyse auf grigio.org zählte 13.044 unsafe-Blöcke in der neuen Codebasis, gegenüber etwa 73 in vergleichbaren Rust-Projekten, dazu über 999 Verwendungen von static mut für globalen veränderlichen Zustand und einzelne Dateien mit mehr als 9.700 Zeilen. Zig-Schöpfer Andrew Kelley beschrieb beim Blick in den Code "Hacks über Hacks. Missbrauch von Assertions" - Praktiken, die laut Piirainen älter sind als der KI-Einsatz.

Was das für Entwickler bedeutet

Läuft Bun bei Ihnen in Produktion, behandeln Sie 1.4 wie ein Major-Release, auch wenn es keines heißt. Ein kompletter Rewrite des Kerns setzt die Fehlerverteilung zurück, egal wie viele Tests bestehen: Pinnen Sie Ihr aktuelles 1.3.x, lassen Sie 1.4 im Staging gegen Ihre echte Last laufen und messen Sie die Start- und Speicherversprechen selbst nach - jede Performance-Zahl oben stammt vom Hersteller.

Der praktische Gewinn sind die neuen eingebauten APIs: Halten Bun.Image, Bun.WebView, Bun.cron() oder Bun.Terminal, was sie versprechen, verschwinden Abhängigkeiten vom Schlage sharp, Puppeteer, cron und PTY aus dem Lockfile - um den Preis, diese Fähigkeiten an eine einzige Runtime zu binden.

Die größere Frage, die 1.4 erstmals im Livebetrieb testet, lautet: Kann KI-Codegenerierung, abgesichert durch eine Testsuite, das menschliche Review einer Systemcodebasis ersetzen? Die 13.044 unsafe-Blöcke und die über 5.000 offenen Pull Requests sind die Zähler, auf die man schauen sollte: Sinken sie über die nächsten Releases, geht die Wette auf. Bis dahin ist der Issue-Tracker das eigentliche Changelog.