Wie Claude Code Bun in Rust umschrieb: Ein sechsstufiger Leitfaden für die groß angelegte Code-Migration
Früher gehörten groß angelegte Programmiersprachen-Migrationen zu den Projekten, die Ingenieursteams jahrelang aufschoben. Solche Migrationen sind teuer, disruptiv und risikoreich. Ein Unternehmen konnte mehrere Quartale damit verbringen, zwei Implementierungen parallel zu warten, nur um am Ende einen Ersatz zu erhalten, der sich anders verhielt als das Original. Claude Code ändert das. Anthropic hat kürzlich seinen Prozess für groß angelegte Code-Migrationen mit KI-Agenten vorgestellt. Das bemerkenswerteste Beispiel ist Jarred Sumner, der Schöpfer von Bun, der den Kern von Bun von Zig nach Rust migrierte. In weniger als zwei Wochen generierte der Claude Code-Workflow über eine Million Codezeilen, und die bestehende Testsuite von Bun bestand die CI-Tests vor dem Merge. Dieses Projekt wurde nicht abgeschlossen, indem man das Modell bat, "Bun in Rust umzuschreiben", und auf eine perfekte Antwort wartete. Es beruhte auf einem sorgfältig entwickelten System mit Regelwerken, Abhängigkeitszu
Wie Claude Code Bun in Rust umschrieb: Ein sechsstufiger Leitfaden für die groß angelegte Code-Migration
Einleitung
Früher gehörten groß angelegte Programmiersprachen-Migrationen zu den Projekten, die Ingenieursteams jahrelang aufschoben. Solche Migrationen sind teuer, disruptiv und risikoreich. Ein Unternehmen konnte mehrere Quartale damit verbringen, zwei Implementierungen parallel zu warten, nur um am Ende einen Ersatz zu erhalten, der sich anders verhielt als das Original.
Claude Code ändert das.
Anthropic hat kürzlich seinen Prozess für groß angelegte Code-Migrationen mit KI-Agenten vorgestellt. Das bemerkenswerteste Beispiel ist Jarred Sumner, der Schöpfer von Bun, der den Kern von Bun von Zig nach Rust migrierte. In weniger als zwei Wochen generierte der Claude Code-Workflow über eine Million Codezeilen, und die bestehende Testsuite von Bun bestand die CI-Tests vor dem Merge.
Dieses Projekt wurde nicht abgeschlossen, indem man das Modell bat, "Bun in Rust umzuschreiben", und auf eine perfekte Antwort wartete. Es beruhte auf einem sorgfältig entwickelten System mit Regelwerken, Abhängigkeitszuordnungen, maschinellen Warteschlangen, adversarialen Prüfern, Compilern, Smoke-Tests und Verhaltenskonsistenzprüfungen.
Die wichtigste Erkenntnis ist direkt: Bei einer so großen Migration sollten Entwickler die meiste Zeit nicht damit verbringen, einzelne Dateien zu reparieren. Sie sollten die Prozesse verbessern, die diese Dateien generieren, prüfen und validieren.
Bun-Schöpfer schreibt mit KI über eine Million Codezeilen um
Jarred Sumner baute Bun ursprünglich mit Zig. Diese Sprache ermöglichte es einem einzelnen Entwickler, sowohl Low-Level-Kontrolle und C-ähnliche Leistung zu erhalten, ohne sich der vollen Komplexität eines großen Systemsprach-Ökosystems stellen zu müssen.
Diese Wahl half Bun, sich früh schnell zu entwickeln. Sumner sagte, er habe die erste Version in etwa einem Jahr in einer kleinen Wohnung in Oakland geschrieben, noch vor modernen Codierungsmodellen.
Bis 2026 war Bun zu einem weit verbreiteten JavaScript- und TypeScript-Laufzeitsystem, Paketmanager, Testrunner und Build-Tool geworden. Sein CLI-Tool erzielt zig Millionen Downloads pro Monat, und Produkte wie Claude Code sind stark auf Bun angewiesen.
Das Wachstum machte auch alte Engineering-Kompromisse schwer zu ignorieren.
Bun kombiniert eine JavaScript-Engine mit Garbage Collection mit manuell verwaltetem nativen Speicher. In Zig müssen Entwickler explizit über Allokation, Bereinigung, Fehlerpfade und Objektlebenszyklen nachdenken. Buns Team investierte viel in Sanitizer, Fuzzing, Security-Builds und Speicherleck-Tests, aber Use-after-free-Fehler, Double-Free-Fehler, Lecks und Lebenszyklusfehler traten dennoch auf.
Rust bietet eine andere Grundlage. Sein Ownership-System, der Borrow-Checker und die automatische Bereinigung können viele Laufzeitspeicherprobleme in Compile-Time-Fehler umwandeln.
Historisch gesehen war dieser Vorteil nicht ausreichend, um eine vollständige Neuschreibung zu rechtfertigen. Bun enthält Hunderttausende von Zeilen Zig-Code, plus eine Vielzahl nativer Integrationen. Eine traditionelle Neuschreibung hätte ein kleines Ingenieursteam ein Jahr oder länger beansprucht, während gleichzeitig die Funktionsentwicklung und Sicherheitsfixes verlangsamt worden wären.
Claude Code machte eine vollständig maschinelle Migration machbar.
11 Tage von Zig nach Rust
Sumner verwendete eine Vorabversion von Claude Fable 5 und den dynamischen Workflow von Claude Code, um die Migration durchzuführen.
Das Hauptschreiben und die Prüfung
Der Prozess lief 11 Tage lang. Etwa 50 dynamische Workflows bearbeiteten verschiedene Phasen, darunter:
- Erstellung eines Leitfadens für die Portierung von Zig nach Rust
- Abbildung des Speicherlebenszyklus
- Konvertierung von
.zig-Dateien in.rs-Dateien - Prüfung jeder generierten Datei
- Behebung von Compiler-Fehlern
- Wiederherstellung einzelner Bun-Befehle
- Ausführung der vollständigen Testsuite
- Refaktorisierung und Bereinigung des generierten Codes
Bei Spitzendurchsatz produzierte der Workflow etwa 1300 Codezeilen pro Minute. Jede generierte Codeeinheit wurde von zwei unabhängigen adversarialen Prüfern überprüft, gefolgt von einem Fixer, der die bestätigten Änderungen anwendete.
Der endgültige Pull-Request fügte in über 2000 geänderten Dateien mehr als eine Million Codezeilen hinzu.
Vor dem Merge bestand die bestehende Testsuite von Bun in CI. Nach dem Merge traten 19 Regressionsprobleme auf, die laut Anthropic anschließend alle behoben wurden. Die Rust-Portierung wurde im Juni 2026 mit Claude Code veröffentlicht.
Dieses Ergebnis beweist nicht, dass die ursprünglich generierte Million Codezeilen korrekt war. Sumner stellte klar, dass die früheste Übersetzungsausgabe nicht lauffähig war. Der Schlüssel zum Erfolg lag im Feedback-System, das schrittweise nicht lauffähige Ausgaben in kompilierten, getesteten, verhaltenskompatiblen Code umwandelte.
Migrationskosten: etwa 165.000 US-Dollar (nach API-Preisen)
Die Migration von Bun verbrauchte etwa:
- 5,9 Milliarden ungecachete Eingabe-Token
- 690 Millionen Ausgabe-Token
- Etwa 165.000 US-Dollar nach API-Preisen
Das ist eine beträchtliche Summe, aber immer noch weit weniger als die Kosten einer traditionellen Migration, die mehrere Vollzeit-Ingenieure über Jahre hinweg erfordert hätte.
Anthropic schätzte, dass eine frühere Migration im Millionen-Zeilen-Bereich vier Jahre gedauert und etwa 3–4 Millionen US-Dollar an Engineering-Ressourcen gekostet hätte. KI verändert die Geschäftslogik, weil eine Migration nicht mehr eine Existenzkrise lösen muss, um ihre Kosten zu rechtfertigen.
Anhaltende Speicherfehler, alternde Sprachökosysteme, teure Build-Prozesse oder wiederkehrende Wartungsengpässe können jetzt ausreichen, um eine Migration in Betracht zu ziehen.
Allerdings sind Vergleiche mit Vorsicht zu genießen. Die Token-Kosten sind nicht die Gesamtkosten des Projekts. Das Team benötigt auch manuelle Planung, Infrastruktur, Tests, Code-Reviews, Sicherheitsarbeit und Wartung nach dem Merge.
Warum Bun von Zig nach Rust migriert
Diese Migration erfolgte hauptsächlich aus Gründen der Zuverlässigkeit, nicht der Rohgeschwindigkeit.
Bun war in Zig bereits leistungsfähig. Das Problem bestand darin, manuell verwalteten nativen Speicher sicher mit der Garbage-Collection-JavaScript-Laufzeit zu koordinieren.
Häufige Fehlerkategorien waren:
- Use-after-free-Fehler
- Double-Free-Fehler
- Speicherlecks auf Ausnahmepfaden
- Ungültige Zeiger durch reentrante Callbacks
- Übersprungene Bereinigungscode
- Lebenszyklusannahmen, die schwer konsistent durchzusetzen waren
In sicherem Rust können viele dieser Fehler nicht kompiliert werden. Werte haben eindeutiges Ownership, die Ressourcenbereinigung ist an den Objektlebenszyklus gebunden, und der Compiler prüft Referenzen, bevor das Programm ausgeführt wird.
Das Ziel dieser Migration war es, die bestehende Architektur, Datenstrukturen, das Verhalten und die Leistung von Bun zu erhalten. Es war bewusst eher eine maschinelle Portierung als eine vollständige Neugestaltung.
Diese Entscheidung war entscheidend. Wenn das System gleichzeitig neu gestaltet und die Sprache gewechselt worden wäre, wäre ein Verhaltensvergleich extrem schwierig geworden.
Zweites Fallbeispiel: 165.000 Zeilen Python-Code in TypeScript
Jarred Sumner war nicht der einzige Anthropic-Ingenieur, der Claude Code für eine bedeutende Migration nutzte.
Mike Krieger, Co-Leiter des Anthropic Labs und Mitbegründer von Instagram, migrierte an einem Wochenende eine interne Python-Codebasis in etwa 165.000 Zeilen TypeScript-Code.
Der Hauptmigrationsprozess verbrauchte etwa 27 Millionen Token und umfasste:
- Hunderte intelligente Agenten
- Acht Phasen
- Drei Runden adversarialer Prüfung
- Eine abschließende Konsistenzprüfung
- Befehlsweisen Ausgabevergleich mit der Python-Version
- KI-generierte End-to-End-Tests
Das ursprüngliche Tool musste als einzelne Binärdatei ausgeliefert werden. Mit der Python-Toolchain dauerte die Kompilierung pro Plattform etwa acht Minuten, und die vollständige Build-Matrix verzögerte jede Veröffentlichung um etwa 30 Minuten.
Nach der TypeScript-Migration:
- Die Kompilierungszeit sank auf etwa zwei Sekunden
- Die Startgeschwindigkeit der Binärdatei verbesserte sich um etwa das Sechsfache
- Eine separate Bereitstellungspipeline konnte eingestellt werden
Krieger verließ sich nicht auf eine bestehende umfassende sprachübergreifende Testsuite. Stattdessen ließ Claude
Ein Testframework mit Abdeckung von sieben realen Szenarien wurde erstellt, dann wurden die Ausgaben der alten und neuen Implementierung verglichen.
Claude entwarf außerdem zusätzliche End-to-End-Tests, führte diese vier Nächte lang aus und wiederholte den Prozess nach der Behebung fehlgeschlagener Tests. Dabei traten subtile Verhaltensunterschiede zutage, die in den ursprünglichen Szenarien nicht vorhergesehen worden waren.
Warum große Code-Migrationen für KI-Agenten geeignet sind
Große Migrationen wirken einschüchternd, weil sie eine immense Anzahl sich wiederholender Änderungen umfassen. Genau diese Eigenschaften machen sie jedoch für den Einsatz intelligenter Agenten-Workflows geeignet.
Arbeit ist parallelisierbar
Große Codebasen lassen sich typischerweise in Dateien, Pakete, Crates, Module oder Abhängigkeitsgruppen unterteilen. Unabhängige intelligente Agenten können gleichzeitig an voneinander unabhängigen Einheiten arbeiten.
Der Abhängigkeitsgraph bestimmt, welche Einheiten parallel vorangetrieben werden können und welche warten müssen.
Vorhandener Code als Spezifikation
Die ursprüngliche Implementierung enthält bereits das gewünschte Verhalten, Randfälle, Datenstrukturen und Integrationsdetails.
Das Modell muss keine Produktfunktionen erfinden; seine Aufgabe ist es, das bestehende System in einer neuen Sprache oder einem neuen Framework zu erhalten.
Tests als objektive Bewertung
Intelligente Agenten arbeiten besser, wenn sie ihre eigenen Ergebnisse mechanisch bewerten können.
Compiler, Testsuiten, Ausgaben-Diffs, Benchmarks oder Konsistenz-Testframeworks liefern dem System konkrete Signale. Der Agent kann sich daraufhin kontinuierlich verbessern, ohne dass menschliche Beurteilungen für jeden einzelnen Zwischenschritt erforderlich sind.
Aufgabenwarteschlangen können automatisch generiert werden
Kompilierungsfehler werden zur nächsten Aufgabe, fehlgeschlagene Tests zur nächsten Aufgabe, Programmabstürze ebenfalls.
So wird die
große Migrationsaufgabe zu einer Warteschlange, die sich nach und nach reduziert.
Wiederholte Fehler treiben Regelverbesserungen voran
Wenn ein Prüfer dasselbe Problem in mehreren Dateien entdeckt, ist die beste Lösung nicht, jede Datei manuell einzeln zu reparieren.
Man sollte stattdessen das Regelwerk aktualisieren und die betroffenen Stapel neu generieren. Dadurch wird verhindert, dass derselbe Fehler in der weiteren Arbeit erneut auftritt.
Kernprinzip: Den Prozess reparieren, nicht einzelne Dateien
Der wichtigste Gedanke im Anthropic-Prozess ist: Den generierten Code als Produkt des System-Outputs betrachten.
Angenommen, 200 übersetzte Dateien enthalten denselben Eigentumsfehler. Die manuelle Reparatur dieser Dateien mag die sichtbaren Fehler beheben, aber der Workflow könnte denselben Fehler erneut produzieren.
Effektiver ist folgendes Vorgehen:
- Das Muster wiederholter Fehlschläge identifizieren.
- Bestimmen, welche Migrationsregel die Ursache ist.
- Das Regelwerk aktualisieren.
- Nur die betroffenen Dateien neu generieren.
- Den Prüf- und Validierungszyklus erneut durchlaufen.
Der Code verbessert sich, weil der Produktionsprozess optimiert wird.
Dies ähnelt der normalen Softwareentwicklung. Ein wiederkehrender Produktionsfehler sollte zur Verbesserung von Tests, Typprüfungen, statischen Checks oder Prozessen führen – nicht nur zu einem weiteren isolierten Patch.
Voraussetzung: Eine zuverlässige Bewertungsinstanz schaffen
Bevor eine groß angelegte Migration beginnt, muss definiert werden, wie das Team die Korrektheit der neuen Implementierung nachweist.
Ohne Bewertungsinstanz gibt es kein verlässliches Kriterium für die Fertigstellung.
Die Bewertungsinstanz muss die ursprüngliche und die Zielimplementierung unter gleichen Bedingungen bewerten. Vorhandene Tests könnten auf privaten Funktionen oder sprachspezifischen Interna basieren, die bei der Portierung wegfallen.
Anthropic empfiehlt drei Vorbereitungsschritte:
- Vorhandene Tests klassifizieren. Tests, die öffentliches Verhalten prüfen, von Tests trennen, die auf interner Implementierung beruhen.
- Tests für die Portierbarkeit umschreiben. Extern beobachtbares Verhalten in Assertionen übersetzen, die auf beiden Systemen laufen.
- Bewertungsinstanz validieren. Sicherstellen, dass die ursprüngliche Implementierung die Tests besteht, dann das Programm absichtlich beschädigen und prüfen, ob die Bewertungsinstanz dies erkennt.
Eine Testsammlung, die bekannte Fehler nicht erkennt, taugt nicht als effektive Migrationsbewertung.
Bun hat einen klaren Vorteil: Der Großteil seiner Testsammlung ist in TypeScript statt Zig geschrieben, sodass dieselbe Suite die Rust-Implementierung testen kann.
Für Projekte ohne diesen Vorteil lassen sich mit Hilfe von Vergleichstools die tatsächlichen Ein- und Ausgaben der beiden Versionen vergleichen.
Anthropics sechsstufiger Code-Migrationsrahmen
Anthropic hat die Erfahrungen aus diesen Projekten in den folgenden sechsstufigen Prozess zusammengefasst.
Schritt 1: Regelbuch, Abhängigkeitsgraph und Lückenliste erstellen
In dieser Phase werden die gemeinsamen Dokumente erstellt, denen alle nachfolgenden Agenten folgen.
Regelbuch erstellen
Das Regelbuch definiert, wie Konzepte der Quellsprache auf die Zielsprache abgebildet werden.
Für Migrationen, die die Struktur beibehalten, kann das Regelbuch Folgendes enthalten:
- Typzuordnungen
- Fehlerbehandlung
Regelkonventionen
- Namenskonventionen
- Speicher- und Eigentumsregeln
- Standardbibliotheksersetzungen
- Nebenläufigkeitsmuster
- Datei- und Modulanordnung
- Externe Funktionsschnittstellenregeln
- Muster, die manuelle Prüfung erfordern
Bei Refactoring-Entwürfen ähnelt das Regelbuch eher einem Architekturdokument.
Jarred Sumner erstellte die Portierungsrichtlinien für Bun durch Dialoge mit Claude und manuelle Prüfung. Das Endergebnis war mehrere hundert Zeilen lang.
Abhängigkeitszuordnung erstellen
Das Repository muss in der Reihenfolge der Abhängigkeiten aufgeteilt werden.
Ein deterministisches Skript kann durch Überprüfung von Importen, Manifesten, Build-Dateien und Symbolbeziehungen eine Abhängigkeitszuordnung erstellen. Dieses Ergebnis hilft dem Orchestrator zu entscheiden, welche Dateien unabhängig konvertiert werden können und welche gemeinsam bearbeitet werden müssen.
Lückenliste erstellen
Quell- und Zielsprache folgen unterschiedlichen Regeln.
Bei der Migration von Zig zu Rust ist der Speicherbesitz die Hauptlücke. Bei der Migration von Python zu TypeScript müssen implizite Objektformen und Schnittstellen in explizite Verträge umgewandelt werden.
Die Lückenliste muss Punkte erfassen, die durch reine Übersetzung nicht gelöst werden können, einschließlich:
- Verborgene Annahmen der Quellsprache
- Fehlende Abstraktionen der Zielsprache
- Explizit zu machendes Laufzeitverhalten
- Nicht unterstützte Bibliotheken
- Plattformspezifischer Code
- Unsichere Grenzen
- Bereiche, die Neugestaltung oder menschliche Entscheidung erfordern
Das Regelbuch sollte vor der Lückenliste erstellt werden, da die Lückenliste teilweise davon abhängt, was die regulären Regeln nicht bewältigen können.
Schritt 2: Regeln unter Druck testen
Nicht sofort Tausende von Dateien übersetzen.
Zunächst einen kleinen, repräsentativen Satz komplexer Dateien in einem einmaligen Testlauf bearbeiten. Ziel ist es, Regeldefizite aufzudecken, bevor sie sich auf das gesamte Repository ausbreiten.
Beim Testlauf für Bun:
- Der erste Agent übersetzt drei Dateien gemäß Regelbuch.
- Ein anderer Agent übersetzt dieselben Dateien aus der Perspektive eines erfahrenen Rust-Ingenieurs.
- Der Vergleichsagent prüft die Unterschiede.
- Prüfer markieren fehlende oder fehlerhafte Migrationsregeln.
- Die übersetzten Dateien werden verworfen.
Das Ergebnis dieser Phase ist ein optimiertes Regelbuch – kein Produktionscode.
Für Refactoring-Migrationen besteht der äquivalente Test darin, einen gegnerischen Prüfer das Entwurfsdokument attackieren zu lassen und dann einen einmaligen End-to-End-Lauf durchzuführen.
Schritt 3: Vollständige Übersetzung
Sobald die Regeln durch den Testlauf validiert sind, kann das Repository über eine parallele Warteschlange verarbeitet werden.
Eine typische Einheit umfasst:
- Einen Implementierer
- Zwei unabhängige gegnerische Prüfer
- Einen Reparierer
- Eine mechanische Warteschlange
- Ein gemeinsames Regelbuch
- Eine gemeinsame Lückenliste
Die Warteschlange muss einen Wiederaufnahme-Mechanismus unterstützen. Der Arbeitsfortschritt sollte durch Dateiprüfung oder Aufzeichnung der Ergebnisse (nicht durch das Gedächtnis eines einzelnen Agenten) festgestellt werden können.
Agenten sollten unerledigte Arbeiten stets einheitlich markieren, z. B.:
TODO(Portierung): Erläutern, warum dieser Teil nicht sicher übersetzt werden kann
Nicht für jede Einheit muss das teuerste Modell verwendet werden. Modelle mit geringerer Leistung können die Übersetzung in großem Umfang übernehmen, während stärkere Modelle für Prüfer, Architekturentscheidungen und Regeländerungen reserviert werden können.
Schritt 4: Kompilieren
Der erste vollständige Build wandelt Compiler-Fehler in eine strukturierte Aufgabenliste um.
Abhängig von den Build-Kosten kann der
Compiler entweder innerhalb jeder Agenten-Schleife oder über einen separaten Orchestrator ausgeführt werden.
Bei Bun ist das Kompilieren des gesamten Workspace teuer, daher führen Claude-Agenten während der Dateiübersetzung nicht willkürlich cargo-Befehle aus. Der Ablauf ist stattdessen:
- Der Orchestrator führt den Compiler aus.
- Fehlermeldungen werden in eine gemeinsame Liste geschrieben.
- Die Liste wird nach Modul oder Grundursache kategorisiert.
- Reparatur-Agenten bearbeiten die Fehlergruppen parallel.
- Prüfer kontrollieren die Reparaturen.
- Der Orchestrator baut das Projekt erneut.
Dies verhindert, dass Dutzende Agenten gleichzeitig denselben teuren Build anstoßen.
Systematische Compilerfehler sollten zu Regelaktualisierungen führen. Beispielsweise könnte die Zielsprache zyklische Abhängigkeiten ablehnen, die der Quellcompiler im Lazy-Loading-Modus toleriert. Dies ist ein Problem auf Prozessebene und nicht nur eine einfache Ansammlung isolierter Dateifehler.
Schritt 5: Programm ausführen
Eine erfolgreiche Kompilierung beweist lediglich, dass die Zielsprache den Code akzeptiert.
In der nächsten Phase werden durch grundlegende Ausführung und Rauchtests Abstürze, Initialisierungsfehler, fehlende Ressourcen, ungültige Annahmen und Integrationsfehler aufgedeckt.
Fehlerfälle sollten weiterhin nach Ursache kategorisiert werden.
Wenn 40 Rauchtests aufgrund desselben fehlerhaften Initialisierungsmusters fehlschlagen, sollte die Migrationsregel korrigiert und der betroffene Code neu generiert werden, anstatt 40 separate Fehlerbehebungen zu vergeben.
Schritt 6: Ursprüngliches Verhalten abgleichen
Die letzte Stufe ist die Verhaltenskonsistenz.
Führen Sie gleichzeitig portable Testsuiten, Konsistenzprüfungstools, Ausgabevergleiche und einschlägige Benchmarks für beide Codebasen aus.
Gehen Sie bei jedem Fehlerfall wie folgt vor:
- Liefern Sie dem Reparatur-Agenten den Fehlernachweis sowie zwei Implementierungsvorschläge.
- Fordern Sie den Reparatur-Agenten auf, die Verhaltensunterschiede zu identifizieren.
- Lassen Sie die vorgeschlagenen Änderungen von einem adversarischen Prüfer überprüfen.
- Führen Sie kostenintensive Builds über einen einzigen Build-Prozess in Batches aus.
- Führen Sie die betroffenen Tests erneut aus.
- Stufen Sie wiederkehrende Fehler zu einer Regeländerung hoch.
Die ursprüngliche Codebasis ist stets die maßgebliche Referenz, es sei denn, das Projekt beabsichtigt ausdrücklich eine Verhaltensänderung.
Das Fehlen einer Testsuite entbindet nicht von diesem Schritt. Das Team kann mithilfe von Claude auf Basis realer Szenarien externe Konsistenzprüfungstools erstellen und die Gültigkeit dieser Tools durch bewusst fehlerhaftes Verhalten bestätigen.
Kurzanleitung zum Anthropic-Migrationskit
Anthropic hat ein öffentliches Einstiegskit veröffentlicht, das allgemeine Prompts, Vorlagen und Skripte basierend auf dem Migrationsprozess enthält.
Dieses Repository ist Referenzmaterial und kein vollständig verwaltetes Migrationsprodukt. Die Prompts sind Umstrukturierungsvorlagen und keine exakte Prozessdokumentation für Bun-Projekte.
1. Claude Code installieren
Auf macOS- oder Linux-Systemen:
curl -fsSL https://claude.ai/install.sh | bash
Auf Windows PowerShell-Systemen:
irm https://claude.ai/install.ps1 | iex
Überprüfen Sie vor der Ausführung des Remote-Installationsskripts dessen Inhalt und die Sicherheitsrichtlinien Ihrer Organisation.
2. Migrationskit klonen
Führen Sie im zu migrierenden Repository Folgendes aus:
git clone https://github.com/anthropics/code-migration-kit-with-claude-code.git ./migration-kit
3. Migrations-Skill hinzufügen
Dieser optionale Schritt kopiert den Migrations-Skill in das lokale Claude Code-Skill-Verzeichnis:
cp -r migration-kit/skill ~/.claude/skills/code-migration
Aktualisieren Sie den Toolkit-Pfad in der installierten SKILL.md gemäß der Anleitung.
Repository.
4. Machbarkeitsbewertung durchführen
Verwenden Sie zunächst den schreibgeschützten Machbarkeits-Prompt des Toolkits:
prompts/00-feasibility.md
Das Ergebnis sollte drei Fragen beantworten:
- Sollte das Projekt migriert werden?
- Bleibt die Struktur bei der Migration erhalten oder wird sie neu gestaltet?
- Können die ursprüngliche und die Zielimplementierung fair bewertet werden?
"Keine Migration" ist ein gültiges Ergebnis.
5. Bewertungstools und Sicherheitsregeln vorbereiten
Bevor Sie mit der Übersetzung beginnen:
- Erstellen oder validieren Sie sprachübergreifende Bewertungstools.
- Kopieren Sie die empfohlenen Claude-Einstellungen in das Ziel-Repository.
- Verbieten Sie bei Bedarf destruktive oder kostspielige Befehle.
- Stellen Sie sicher, dass das Quell-Repository über eine wiederherstellbare Sicherung verfügt.
- Verwenden Sie isolierte Branches, kontrollierte Arbeitsverzeichnisse und minimale Berechtigungen für Anmeldeinformationen.
Führen Sie dann die Migrations-Prompts der Reihe nach aus, anstatt direkt zur groß angelegten Übersetzung überzugehen.
Probleme bei Buns frühen Versuchen
Buns Migration verlief von Anfang an nicht reibungslos.
Als viele Agenten gleichzeitig in einem Repository arbeiteten, interferierten ihre Git-Operationen. Ein Agent führte git stash aus, ein anderer verwendete git stash pop, und ein weiterer setzte den Arbeitsbaum zurück.
Sumner änderte den Arbeitsablauf, sodass Agenten keine destruktiven Git-Befehle mehr uneingeschränkt ausführen konnten. Später teilte er die Arbeit in vier Workflow-Segmente auf, jedes mit einem eigenen Arbeitsbaum, die jeweils mehrere Agenten koordinierten.
Dieses Beispiel verdeutlicht einen entscheidenden Punkt: Agentenberechtigungen müssen zum Workflow-Design passen.
Coding-Agenten mit umfassendem Shell-Zugriff können:
- Arbeit löschen oder überschreiben
- nicht committete Änderungen zurücksetzen
- kostspielige Builds wiederholt auslösen
- nicht zugehörige Dateien modifizieren
- Geheimnisse über Befehle oder Logs preisgeben
- andere Agenten stören
Die Orchestrierungsebene muss Befehle einschränken, Dateieigentümerschaften definieren, kostspielige Operationen serialisieren und die Wiederherstellung einfach gestalten.
Best Practices für KI-gestützte Code-Migration
Die von Anthropic veröffentlichten Lehren lassen sich auf einige praktische Regeln reduzieren.
Allgemeine Leitfäden nicht blind befolgen
Jede Codebasis hat unterschiedliche Build-Systeme, Testabdeckung, Laufzeitverhalten, Bereitstellungsbeschränkungen und Risikotoleranz.
Nutzen Sie das Sechs-Schritte-Framework als Ausgangspunkt und lassen Sie Claude dann basierend auf dem tatsächlichen Repository Anpassungen vornehmen.
Auf Muster achten, nicht auf Einzelfehler
Reparatur-Agenten können sich um einzelne Fehler kümmern. Der menschliche Einsatz ist wertvoller, wenn er sich auf die Identifizierung wiederkehrender Muster, fehlender Regeln, unsicherer Annahmen und architektonischer Probleme konzentriert.
Prüfungen adversarisch gestalten
Der implementierende Agent sollte nicht sein eigener einziger Prüfer sein.
Geben Sie dem Prüfer unabhängigen Kontext und teilen Sie ihm mit, dass vom generierten Code angenommen wird, dass er fehlerhaft ist. Seine Aufgabe ist es, herauszufinden, warum der Code fehlschlägt, abweicht oder gegen das Regelwerk verstößt.
Validierung mechanisieren
Verwenden Sie Compiler, Tests, Linter, Ausgabedifferenzen, Benchmarks und deterministische Skripte als Bewertungstools.
Subjektive "sieht richtig aus"-Prüfungen können Änderungen im Millionen-Zeilen-Bereich nicht sicher validieren.
Unterschiedliche Modelle für unterschiedliche Rollen verwenden
Aufgaben mit hohem Übersetzungsvolumen können kleineren oder günstigeren Modellen übertragen werden. Die stärksten Modelle sollten für Regelerstellung, Architektur, unklare Fehler und Prüfungen zuständig sein.
Frühzeitig menschliche Ressourcen einsetzen
Die wertvollste menschliche Arbeit sollte vor der Massengenerierung erledigt werden:
Geschäftsfall definieren
- Prüfmechanismus aufbauen
- Regelwerk erstellen
- Abhängigkeiten kartieren
- Pilotprojekt prüfen
- Berechtigungen und Grenzen festlegen
Sobald diese Grundlagen solide und zuverlässig sind, wird der Großteil der verbleibenden Arbeit zu einer mechanischen Warteschlangenaufgabe.
Warteschlange wiederherstellbar halten
Migrationsaufgaben, die mehrere Tage laufen müssen, sollten Abstürze, Neustarts, Modellfehler und Infrastrukturausfälle verkraften.
Der Fertigstellungsstatus sollte auf persistenten Artefakten auf der Festplatte, Commits, Testergebnissen und dem Warteschlangenstatus basieren und nicht auf einer einzigen langen Konversation.
Ergebnisse nach der Bun-Migration
Anthropic berichtet, dass der in Rust geschriebene Bun-Code in der Produktion verwendet wird.
Die Migration hat nicht alle Zielkonflikte beseitigt. Etwa 4 % des Rust-Codes befinden sich weiterhin in unsafe-Blöcken, hauptsächlich bei kleinen Zeigeroperationen an den Schnittstellen zu C und C++.
Die neue Implementierung brachte jedoch erhebliche Verbesserungen:
- Erkennbare Speicherlecks wurden behoben
- Der Speicherverbrauch bei einem bestimmten Build-Benchmark sank von 6.745 MB auf 609 MB
- Die Binärgröße verringerte sich unter Linux und Windows um 19 %
- Sprachübergreifende Optimierungen führten bei bestimmten Workloads zu einer Leistungssteigerung von etwa 2 % bis 5 %
Diese Ergebnisse zeigen deutlich den Sinn der Migration. Das Ziel ist nicht die Generierung großer Mengen KI-geschriebenen Codes, sondern die Schaffung eines sichereren, schlankeren und besser wartbaren Systems unter Beibehaltung des ursprünglichen Verhaltens.
Anwendungsszenarien für KI-Migration
Groß angelegte Migrationen eignen sich für Agenten-Workflows, wenn folgende Bedingungen erfüllt sind:
- Die ursprüngliche Codebasis kann als vollständige Spezifikation dienen
- Das Verhalten kann über externe Mittel überprüft werden
- Es können Tests oder Paritätsszenarien erstellt werden
- Die Arbeit kann in wiederholbare Einheiten zerlegt werden
- Die Zielsprache bietet klare Vorteile
- Die Organisation kann mit großen experimentellen Branches umgehen
- Menschliche Experten können Architektur und Grenzfälle prüfen
- Die Tool-Umgebung kann eingeschränkt und auditierbar sein
Migrationen sind möglicherweise weniger geeignet, wenn:
- Das ursprüngliche Verhalten nicht ausreichend verstanden wird
- Die Korrektheit nicht verifiziert werden kann
- Das Projekt Migration mit einer vollständigen Produktneugestaltung vermischt
- Regulierungsgenehmigungen eine manuelle Überprüfung jeder Änderung erfordern
- Der Code Geheimnisse oder Systeme enthält, die nicht sicher offengelegt werden können
- Das Team nach der Zusammenführung von KI-generiertem Code keine Eigentümerschaft übernimmt
Die Fähigkeit, schnell Millionen von Codezeilen zu generieren, rechtfertigt nicht automatisch eine Migration.
Häufig gestellte Fragen
Hat Claude Code Bun wirklich von Zig
Wurde es nach Rust umgeschrieben?
Ja. Jarred Sumner nutzte Claude Code mit dynamischen Workflows und einer Vorabversion des Claude-Modells, um den Kern von Bun von Zig nach Rust zu migrieren. Der Prozess generierte in weniger als zwei Wochen über eine Million Codezeilen, die anschließend kompiliert, getestet, überprüft und nach dem Merge korrigiert wurden.
Wie hoch waren die Kosten für die Migration von Bun?
Ein Bericht von Anthropic zeigt, dass etwa 5,9 Milliarden ungecachte Eingabe-Tokens und 690 Millionen Ausgabe-Tokens verbraucht wurden. Basierend auf den API-Preisen belaufen sich die Modellkosten auf schätzungsweise 165.000 US-Dollar, ohne Berücksichtigung von Personal- und Infrastrukturkosten.
Hat die Migration vor dem Merge alle Tests bestanden?
Anthropic gibt an, dass die bestehende Testsuite von Bun vor dem Merge in der CI bestanden wurde. Nach dem Merge wurden 19 Regressionen festgestellt, die anschließend behoben wurden.
Warum wurde Bun von Zig nach Rust migriert?
Das Hauptziel war die Verbesserung der Speichersicherheit und die Reduzierung wiederkehrender Lebenszyklusprobleme wie Bereinigung, Use-after-free, Double-Free und Speicherlecks. Das Eigentümer- und Typsystem von Rust kann viele dieser Probleme bereits zur Kompilierzeit abfangen.
Kann Claude Code automatisch jede Codebasis migrieren?
Nein. Eine erfolgreiche Migration erfordert strenge Prüfer, klare Regeln, Abhängigkeitsanalysen, kontrollierte Berechtigungen, wiederholbare Warteschlangen, adversarielle Überprüfungen und menschliche Aufsicht. Manche Projekte sollten gar nicht migriert werden.
Was ist eine adversarielle Codeüberprüfung?
Adversarielle Prüfer erhalten die generierten Änderungen in einer isolierten Umgebung und haben die Aufgabe, Fehler zu finden, nicht die Änderungen zu genehmigen. Die Rollen von Implementierer und Prüfer sind getrennt, was das Risiko verringert, dass der Autor seine eigenen Ergebnisse verteidigt.
Benötige ich eine bestehende Testsuite?
Idealerweise sollte eine umfassende Testsuite vorhanden sein, insbesondere wenn sie das öffentliche Verhalten unabhängig von der Implementierungssprache testet. Ist dies nicht der Fall, kann das Team ein Validierungsframework aufbauen, um Unterschiede in Szenarien und Ausgaben zwischen Alt- und Neusystem zu vergleichen.
Ist das Migrationskit von Anthropic der vollständige Workflow, den Bun verwendet hat?
Nein. Anthropic beschreibt das Repository als generalisiertes und umgestaltetes Starterkit. Die tatsächliche Migration von Bun verwendete spezifischere Komponenten, darunter ein umfangreiches Projektregelbuch und benutzerdefinierte dynamische Arbeitsabläufe.
Verwandte Tools
- Claude Code: Das intelligente Codierungstool von Anthropic für Repository-, Terminal-, Test- und Entwicklungs-Workflow-Management.
- Bun: JavaScript- und TypeScript-Laufzeit, Paketmanager, Bundler und Testrunner.
- Rust: Systemprogrammiersprache mit Fokus auf Leistung, Typsicherheit und Speichersicherheit.
- Zig: Low-Level-Programmiersprache mit Betonung auf expliziter Kontrolle und klarer Sprachsemantik.
- GitHub: Quellcodeverwaltungs- und Kollaborationsplattform zur Verwaltung des Bun-Migrations-Pull-Requests und des Anthropic-Migrationskits.
- Claude Code Modernisierungs-Plugin: Offizielles Plugin von Anthropic zur Bewertung und Modernisierung von Legacy-Systemen.
Verwandte Links
- Anthropic Leitfaden zur groß angelegten Code-Migration: Offizielle sechsstufige Vorgehensweise und zwei Migrationsfallstudien.
- Bun in Rust umschreiben: Jarred Sumners detaillierter Bericht über Architektur, Workflow, Überprüfung, Fehlschläge und Ergebnisse.
- Bun Rust Rewrite Pull Request: Der gemergte Pull-Request mit der massiven Zig-zu-Rust-Migration.
- Claude Code Migrationskit: Offizielle Eingabeaufforderungen, Vorlagen, Skripte und Referenz-Workflows für Sprachmigrationen.
- Claude Code Dokumentation: Offizielle Installations-, Konfigurations-, Sicherheits- und Workflow-Dokumentation.
- Code-Modernisierungs-Plugin: Offizielles Claude Code Plugin zur Bewertung und Transformation von Legacy-Systemen.
Verhaltensequivalenztests.
- Rust Offizieller Leitfaden: Offizielle Dokumentation zu Rusts Ownership, Borrowing, Typen, Nebenläufigkeit und Anwendungsentwicklung.
Zusammenfassung
Der Erfolg der Bun-Migration mit Claude Code lag nicht darin, dass auf Anhieb eine perfekte Million-Zeilen-Neuschreibung generiert wurde. Der Schlüssel zum Projekterfolg war ein rigoroses Produktionssystem, das das Team um das Modell herum aufbaute: Regelbuch, Abhängigkeitskartierung, Lückenliste, Pilotprojekt, parallele Übersetzungswarteschlange, adversarielle Überprüfung, Compiler-Schleife, Rauchtests und Verhaltenskonformitätsprüfungen.
Dieselbe Methode half Anthropic, an einem Wochenende eine große Python-Codebasis nach TypeScript zu migrieren. In beiden Fällen war die objektive Validierung weitaus wichtiger als die rohe Generierungsgeschwindigkeit.
KI kann die Kosten und den Zeitaufwand für groß angelegte Migrationen erheblich senken – vorausgesetzt, der Prozess ist unterbrechbar, die Berechtigungen sind kontrolliert, und wiederkehrende Mängel verbessern kontinuierlich die Regeln für den generierten Code.
Der wahre Durchbruch liegt nicht darin, dass KI eine Million Zeilen Code schreiben kann – sondern darin, dass ein sorgfältig gestalteter Kreislauf diesen Code immer wieder erzeugt, hinterfragt, testet und korrigiert, bis das Verhalten des neuen Systems exakt mit dem des alten übereinstimmt.