Code-Migrationen — also eine ganze Codebasis in eine neue Sprache portieren — waren bis vor Kurzem Mehrjahresprojekte. Teuer, riskant, und am Ende oft nur 90 Prozent fertig. Anthropic hat jetzt in einem ausführlichen Blogpost gezeigt, wie das heute aussieht. Und die Zahlen sind schon eine Ansage.
Zwei Beispiele, die hängen bleiben
Jarred Sumner, Bun-Mitgründer und inzwischen bei Anthropic, hat Bun von Zig nach Rust portiert — mit Claude Code. Eine Million Zeilen Code in unter zwei Wochen, 100 Prozent der bestehenden Testsuite grün in der CI, bevor gemergt wurde. Danach kamen noch 19 Regressionen ans Licht — alle behoben. Der Rust-Port ist im Juni live gegangen.
Mike Krieger, Co-Lead von Anthropic Labs, hat an einem Wochenende eine Python-Codebasis nach 165.000 Zeilen TypeScript migriert. Hunderte Agenten, acht Phase-Gates, drei adversariale Review-Runden und ein finaler Parity-Check, der jeden Befehl gegen das Python-Original gediffed hat.
Kostenlos ist das nicht: Die Bun-Migration hat 5,9 Milliarden ungecachte Input-Tokens und 690 Millionen Output-Tokens verbraucht — rund 165.000 Dollar zu API-Preisen. Aber im Vergleich zu drei bis vier Millionen über ein Vierjahresprojekt? Eine andere Rechnung.
Der eine Satz, der alles trägt
Der Kerngedanke steht früh im Text: Du fixt nicht den Code. Du fixt die Schleife (den Loop), die ihn erzeugt.
Große Migrationen passen gut zu Modellen wie Fable 5 und Opus 4.8, weil die Arbeit parallel läuft: tausende unabhängige Dateien, an denen Agenten gleichzeitig arbeiten. Der alte Code ist die perfekte Spezifikation. Die Testsuite ist ein eingebauter Schiedsrichter. Und die Warteschlange schreibt sich selbst — jeder Compiler- oder Testfehler wird zum nächsten To-do.
Sechs Schritte, grob umrissen
Anthropic beschreibt einen Sechs-Schritte-Prozess. Ganz verkürzt: Erst baust du einen Judge — Tests, die gegen alte und neue Codebasis gleichermaßen laufen. Dann kommen Regelbuch, Dependency-Map und Gap-Inventar. Ein Stresstest an ein paar Dateien deckt Fehler auf, bevor sie sich über tausende Dateien fächern. Dann wird alles übersetzt, kompiliert, ausgeführt und das Verhalten abgeglichen.
Spannend im Detail: Kleine Modelle machen die Fleißarbeit, große Modelle die Reviews und alles, was Regeln schreibt, denen andere Agenten folgen. Und wenn ein Reviewer denselben Fehler immer wieder findet, wird nicht die Datei gepatcht — es kommt ein Satz ins Regelbuch, und die betroffene Charge wird neu erzeugt.
Meine Einordnung
Was mich hängen bleibt, ist der Perspektivwechsel. Früher war das Worst-Case-Szenario zwei parallele Codebasen über Quartale und ein Ergebnis mit 90 Prozent Parität. Heute? Du löschst den Branch und probierst es nochmal.
Das senkt nicht nur die Kosten, es senkt das Karriererisiko. Migrationen mussten früher existenziell sein, um sich zu lohnen. Jetzt reicht ein chronischer Bottleneck. Mikes Compile-Schritt fiel von acht Minuten pro Plattform auf zwei Sekunden.
Anthropic hat dazu ein Migration-Starter-Kit auf GitHub gelegt. Wenn du eine Codebasis hast, die du seit Jahren erträgst — vielleicht lohnt sich die Rechnung nochmal.
Quellen: