Früher gehörten groß angelegte Programmiersprachen-Migrationen zu den Projekten, die Ingenieursteams jahrelang aufschoben. Solche Migratione...
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.
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.
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:
.zig-Dateien in .rs-DateienBei 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.
Die Migration von Bun verbrauchte etwa:
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.
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:
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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:
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.
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:
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.
Anthropic hat die Erfahrungen aus diesen Projekten in den folgenden sechsstufigen Prozess zusammengefasst.
In dieser Phase werden die gemeinsamen Dokumente erstellt, denen alle nachfolgenden Agenten folgen.
Das Regelbuch definiert, wie Konzepte der Quellsprache auf die Zielsprache abgebildet werden.
Für Migrationen, die die Struktur beibehalten, kann das Regelbuch Folgendes enthalten:
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.
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.
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:
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.
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:
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.
Sobald die Regeln durch den Testlauf validiert sind, kann das Repository über eine parallele Warteschlange verarbeitet werden.
Eine typische Einheit umfasst:
Beschreibe deine Idee einmal, und We0 AI erstellt eine Showcase-Website, Seiten und ein CMS und hilft nach dem Launch bei Kunden und Traffic.
Eine komplette Projektgeneration zur kostenlosen Registrierung
Am besten geeignet, um einen vollständigen Generierungsablauf auszuprobieren und schnell einen ersten Projektentwurf zu sehen.
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.
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:
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.
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.
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:
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.
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.
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.
Führen Sie im zu migrierenden Repository Folgendes aus:
git clone https://github.com/anthropics/code-migration-kit-with-claude-code.git ./migration-kit
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.
Verwenden Sie zunächst den schreibgeschützten Machbarkeits-Prompt des Toolkits:
prompts/00-feasibility.md
Das Ergebnis sollte drei Fragen beantworten:
"Keine Migration" ist ein gültiges Ergebnis.
Bevor Sie mit der Übersetzung beginnen:
Führen Sie dann die Migrations-Prompts der Reihe nach aus, anstatt direkt zur groß angelegten Übersetzung überzugehen.
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:
Die Orchestrierungsebene muss Befehle einschränken, Dateieigentümerschaften definieren, kostspielige Operationen serialisieren und die Wiederherstellung einfach gestalten.
Die von Anthropic veröffentlichten Lehren lassen sich auf einige praktische Regeln reduzieren.
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.
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.
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.
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.
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.
Die wertvollste menschliche Arbeit sollte vor der Massengenerierung erledigt werden:
Geschäftsfall definieren
Sobald diese Grundlagen solide und zuverlässig sind, wird der Großteil der verbleibenden Arbeit zu einer mechanischen Warteschlangenaufgabe.
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.
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:
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.
Groß angelegte Migrationen eignen sich für Agenten-Workflows, wenn folgende Bedingungen erfüllt sind:
Migrationen sind möglicherweise weniger geeignet, wenn:
Die Fähigkeit, schnell Millionen von Codezeilen zu generieren, rechtfertigt nicht automatisch eine Migration.
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.
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.
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.
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.
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.
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.
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.
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.
Verhaltensequivalenztests.
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.
Starte mit einem Satz und erhalte in wenigen Minuten eine vollständige Website.
