Viele Unternehmen leben mit internen Anwendungen, die sie sich nicht mehr anzufassen trauen. Der Code läuft zwar, basiert aber auf einer veralteten Technologie, die nicht mehr gewartet wird. Es gibt keine Sicherheitsupdates mehr, und daher sammeln sich die Schwachstellen an (Passwörter werden zum Beispiel mit MD5 ohne Salt gespeichert). Die Frage nach einer technischen Aktualisierung stellte sich zwar regelmässig, der Schritt wurde jedoch nie gewagt und die technische Schuld hat sich angehäuft. Die Codebasis des Unternehmens wird daher beibehalten, ohne gewartet zu werden, mangels besserer Optionen.
Doch am 16. Juli 2026 hat das amerikanische Unternehmen Anthropic
bekannt gegeben vollständig neu geschrieben zu haben
Bun en Rust mithilfe seines Sprachmodells Claude. Im Zeitalter der generativen KI hat sich das Gleichgewicht verschoben. Für Multi-Agenten-Systeme und die neuesten Sprachmodelle ist die Skalierbarkeit der Codebasis erreicht. Die
Migration eines Backends von 100'000 Zeilen Code durch KI-Modelle ist eine Aufgabe
machbar in
zwei Wochen.
Das Ziel der Migration ist vielfältig: Man aktualisiert den technischen Stack, man stellt sicher, dass die Migration nur die Syntax (und nicht das Verhalten) des Codes ändert, und man erkennt dabei Bugs oder Schwachstellen. Die Migration erfolgt wie folgt:
Man kartiert die Endpoints des Legacy-Codes: Dies sind die Einstiegspunkte, von denen aus die Migration erfolgt
Für jeden der Endpoints generieren KI-Agenten Tests, um einen „Golden master“ zu erstellen
Danach erfolgt die eigentliche Code-Migration mit KI-Workflows, die eine Tiefensuche-Logik für jeden Endpoint befolgen
Jeder Agent iteriert, damit der migrierte Code genau den Tests des Golden master entspricht
Die verschiedenen Workflows werden zusammengeführt, um den Code zu faktorisieren und Kompilierungsfehler zu erkennen
Am Ende erhält man einen Bericht, der die von den verschiedenen Agenten erkannten Bugs und die Tests beschreibt, von denen bewusst abgewichen wurde (weil es sich um Bugs handelte, die man nicht reproduzieren wollte)
Ein identisches Verhalten gewährleisten
Wie stellt man sicher,
die Genauigkeit der Migration ? Das ist die Idee hinter der Methode des
Golden master. Damit das Verhalten dasselbe ist, muss jede Anfrage dieselbe Antwort haben, selbst wenn es sich um einen Fehler 500 (internal server error) handelt. Alle Antworten, einschliesslich Bugs und Fehler, müssen vor und nach der Migration im selben Zustand verbleiben. Diese Fehler müssen gemeldet werden, aber die Korrektur jedes einzelnen Fehlers muss kontrolliert werden.
Verhaltensänderungen müssen eine Ausnahme bleiben. Man muss also schreiben
ein Maximum an Tests : Unit-Tests, Integrations-Tests und End-to-End-Tests. Auch die Fehlerbehandlung und pathologische Fälle testen.
Um die Robustheit und Relevanz der Tests zu stärken, wendet man eine „adversarische“ Struktur : einen angreifenden und einen verteidigenden Agenten. Der angreifende Agent hat nur Zugriff auf die Funktionskontrakte (welche Argumente nimmt sie entgegen? was gibt sie zurück? wozu dient sie?). Sein Ziel ist es, Tests zu schreiben: die Happy Paths, aber auch und vor allem die pathologischen Fälle. Im Gegenzug ist der verteidigende Agent für die eigentliche Migration verantwortlich. Der verteidigende Agent muss also bei Bedarf so lange iterieren, bis die Migration die vom angreifenden Agenten generierten Tests erfüllt.
Die Idee hinter dieser Angreifer-/Verteidiger-Struktur ist es, das Phänomen der Gefälligkeit zu verhindern (
sycophancy) der KI-Agenten beim Schreiben von Tests. Indem man dem angreifenden Agenten nur die Kontrakte und nicht den Code der zu testenden Funktionen gibt, verhindert man, dass die Tests tautologisch sind und lediglich eine Wiedergabe des Codes darstellen.
Tests zu schreiben ist auch eine Absicherung für die Zukunft : Im Falle zukünftiger Funktionserweiterungen ermöglichen bereits vorhandene robuste und umfassende Tests, die Kompatibilität der Änderungen mit dem Rest der Anwendung sicherzustellen.
Ihre Codebasis migrieren
Für die Migration ist das Multi-Agenten-System wie folgt aufgebaut: Ein Orchestrator generiert Unter-Agenten, um jeden Endpoint zu migrieren. Er hat auch die Aufgabe, den Code zu faktorisieren und die Ergebnisse am Ende der Migration zusammenzuführen.
Jeder Unter-Agent ist für einen Endpoint verantwortlich. Er muss ihn in die neue Sprache übersetzen. Zum Beispiel wurde bei Galadrim ein View-Controller-Modell (
MVC) in NET 4.8 auf ein Backend in .NET 9 und ein Frontend in React migriert.
Claude Code, vom Unternehmen Anthropic, ist ein effektives Werkzeug für diese Art von Aufgabe: Ein Haupt-Agent (der Orchestrator) generiert automatisch die Unter-Agenten, die für das Schreiben der Tests und die Migration zuständig sind. Wir gehen wellenweise vor: Bei jeder Welle sind 3 Unter-Agenten für die Migration von Endpoints zuständig. Jeder Unter-Agent ist für eine Gruppe von Endpoints verantwortlich (zum Beispiel gehören vier CRUD-Endpoints zu derselben Gruppe, die ein Unter-Agent migrieren muss).
Es kann notwendig sein, um eine alte Codebasis zu betreiben, eine Windows-VM zu verwenden (dies ist zum Beispiel bei .NET 4.8 der Fall), um End-to-End-Tests zu generieren. Die für die Generierung der Tests zuständigen Agenten verbinden sich dann automatisch mit der VM, um die Anfrage zu senden und die Antwort der Legacy-Anwendung abzurufen, um den Golden Master zu erstellen.
Sobald alle Migrationswellen abgeschlossen sind, ist der Orchestrator dafür zuständig, die Teile zusammenzufügen und den Code zu faktorisieren. Dies ist insbesondere der Fall, wenn Funktionen während der Migration dupliziert wurden, weil sie für mehrere Endpoints notwendig waren. Es ist auch die Gelegenheit zu überprüfen, ob es keine Kompilierungsprobleme gibt (die die Vereinfachung verursachen könnte) und ob die migrierte Anwendung korrekt startet.
Bugs und Sicherheitslücken erkennen
Beim Scannen des Testcodes kann man auch gravierende Bugs erkennen die bisher übersehen wurden, und Sicherheitslücken. Zum Beispiel wurde in der Legacy-Anwendung entdeckt, dass ein Endpoint öffentlich exponiert war, ohne Authentifizierungspflicht (im Gegensatz zu allen anderen), und dass die Daten, zu denen er Zugang gewährte, uneingeschränkt gelesen werden konnten. Ein umfassender Durchlauf des Codes ermöglicht es auch, toten Code zu erkennen, der nicht verwendet würde und den Rest «verschmutzen» würde. Dies kann sich insbesondere durch Tabellen in der Datenbank zeigen, die aber für die Anwendung unsichtbar sind, weil sie ungenutzt bleiben.
Zusammenfassend lässt sich sagen, die Migration seiner Codebase mithilfe eines Multi-Agenten-Systems durchzuführen, bedeutet einerseits seinen Code zu aktualisieren um dessen Wartbarkeit und Geschwindigkeit sicherzustellen, aber es bedeutet auch, dabei dieSicherheitsrisiken und die grossen Bugs die in einem Code vorhanden sind, der nicht mehr gewartet wird.
Fazit: Mit KI, zwei Wochen, um seine Codebase zu migrieren
Was würde ein solches Projekt kosten? Die manuelle Migration würde Zehntausende oder gar Hunderttausende von Euro kosten und mehrere Monate in Anspruch nehmen. Das ist der Grund, warum Codebases nicht weiterentwickelt werden und langfristig im gleichen Zustand bleiben.
Der Multi-Agenten-Ansatz hingegen reduziert die Grössenordnungen drastisch. Bei Galadrim konvertieren wir ein Backend von 120 000 Zeilen in zwei Wochen. Mit dem Opus 4.8 Modell von Anthropic sind die Grössenordnungen wie folgt:
2,5 Milliarden Tokens (grösstenteils Cache-Tokens, die günstiger sind als Input- oder Output-Tokens)
1 800 $ an API-Kosten
4 000 Tests generiert
40 Stunden Inferenz etwa, grösstenteils parallelisiert (wenn 3 Agenten 1 Stunde parallel laufen, entspricht dies 3 Stunden Inferenz für 1 Stunde Echtzeit)
