Ein Senior-Ingenieur sitzt vor einer Methode in einer fünfzehn Jahre alten Java-Klasse. Irgendwo zwischen Zeile 47 und Zeile 312 steckt eine Rundungsregel, die ein Großkunde 2014 am Telefon durchgesetzt hat. Niemand hat sie aufgeschrieben. Der Agent neben ihm im Editor sieht den Code. Das Telefonat kennt er nicht.
Das ist die Lage in fast jedem zehn Jahre alten Monolithen, der gerade vom Vorstand die Vorgabe bekommen hat, KI zur Modernisierung einzusetzen. Der Code ist da. Die Entscheidungen, die in ihm stecken, sind es nicht.
KI ist in der Legacy-Arbeit nicht der Refaktorierer. KI ist der Archäologe, der Stenograf und der Übersetzer. Die Refaktorierungsentscheidungen trifft weiterhin ein Mensch, der das Geschäft versteht. Wer diese Arbeitsteilung umdreht, produziert schnell viel Code, der in Produktion leise falsch ist. Wer sie respektiert, verkürzt die Arbeit, die in einem alten Monolithen tatsächlich teuer ist: das Verstehen.
Legacy-Code mit KI zu refaktorieren bedeutet deshalb nicht, dem Agenten das System zu überlassen. Es bedeutet, seine Arbeit auf prüfbare Transformationen zu begrenzen.
Wer diese Frage neben Rollout, Tooling und Compliance einordnen will, findet im Coding-Agents-Leitfaden für Modernisierungsprojekte den breiteren Rahmen.
Was KI in Legacy-Code tatsächlich gut kann
Drei Aufgaben. Jede davon hat eine prüfbare Ausgabe und einen klaren Erfolgsbegriff. Genau dort verdient KI ihren Platz im Werkzeugkasten.
Archäologie. Undokumentierten Code lesen und in lesbare Beschreibungen, Abhängigkeitskarten und Dead-Code-Listen verwandeln. Morgan Stanley hat dafür ein eigenes Werkzeug gebaut, DevGen.AI, trainiert auf der eigenen Codebasis. Vom Rollout im Januar 2025 bis Anfang Juni 2025, also in den ersten fünf Monaten, hat das Tool nach Angaben der Bank rund neun Millionen Zeilen Legacy-Code verarbeitet und etwa 280.000 Entwicklerstunden gespart. Die Berechnungsgrundlage hat die Bank nicht offengelegt, das ist eine Selbstauskunft, kein gemessenes Ergebnis. Aber die operative Logik ist gut belegt und im Wall Street Journal dokumentiert: DevGen.AI schreibt den neuen Code nicht. Das Tool generiert Spezifikationen in englischer Prosa, Ingenieure schreiben den Code. Kommerzielle Werkzeuge reichten dafür nicht aus, weil ältere Sprachen und interne DSLs zu speziell waren.
Die gleiche Arbeitsteilung beschreibt Thoughtworks im Technology Radar Vol. 33 vom November 2025 als eigene Technik: „GenAI for forward engineering". Generative KI extrahiert eine Verhaltensspezifikation aus dem Altsystem, Menschen reimplementieren gegen die Spezifikation. Das ist eine starke Bestätigung aus der Beratungspraxis: Auch dort wird KI nicht als autonomer Refaktorierer beschrieben, sondern als Werkzeug zur Spezifikation des Altsystems.
Charakterisierungstests schreiben. Tests, die das aktuelle Verhalten einfrieren, bevor eine einzige Zeile geändert wird. Michael Feathers hat den Begriff 2004 in den Engineering-Kanon eingeführt. Zwanzig Jahre lang war die Idee ökonomisch zu teuer für die meisten Teams. Mit KI wird sie tragbar, und Feathers selbst hat 2024 öffentlich erklärt, dass Charakterisierungstests genau die Aufgabe sind, bei der KI Schreibarbeit übernehmen darf, solange ein Mensch die Assertions prüft.
Mechanische Übersetzung. Airbnb hat 2025 rund 3.500 React-Komponententests von Enzyme auf React Testing Library migriert. Der eigentliche Migrationssprint dauerte sechs Wochen. Davor lagen Monate Pipeline-Aufbau, die mit einem Hackathon-Prototyp 2023 begannen. Von einem manuellen Achtzehn-Monats-Marathon ist also nicht die Rede, das war Airbnbs eigene Vorab-Schätzung, kein gemessener Vergleich. Trotzdem ist der Fall sauber: 97 Prozent der Dateien gingen automatisiert durch, der Rest manuell auf Basis des LLM-Entwurfs. Die Airbnb-Engineering-Veröffentlichung zeigt klar, was den Unterschied machte: eine State-Machine mit harten Gates (Jest grün, Lint sauber, TypeScript kompiliert) und kompromisslose Iteration, im Long Tail bis zu hundert Versuche pro Datei.
Eine Warnung gehört direkt daneben. Tests sind ein ungewöhnlich KI-freundliches Migrationsziel. Jeder Test validiert sich selbst (laufen lassen, grün sehen). Geschäftslogik in einem Monolithen tut das nicht. Airbnb ist die Obergrenze für saubere Pipeline-Arbeit, nicht der Beleg dafür, dass sich Geschäftsmonolithen genauso automatisieren ließen.
Die drei Aufgaben haben dieselbe Struktur. Das Zielverhalten ist definiert, die Transformation ist mechanisch, der Erfolg ist maschinell prüfbar. Genau dort verdient KI in Legacy-Arbeit ihren Platz.
Zur schnellen Einordnung, wo welche Rolle endet:
| Aufgabe | KI-Rolle | Menschliche Kontrolle | Freigabekriterium |
|---|---|---|---|
| Code verstehen | Zusammenfassen, Abhängigkeiten kartieren | Domänencheck | Erklärung deckt sich mit Produktion und Fachwissen |
| Charakterisierungstests | Testfälle und Assertions vorschlagen | Assertions validieren | Tests bilden gewünschtes Ist-Verhalten ab |
| Mechanische Migration | Änderung ausführen, CI-Fehler iterieren | Review und Ausnahmefälle | Tests, Lint, Typprüfung, fachliche Invarianten grün |
| Geschäftslogik ändern | Keine Entscheidungshoheit | Product, Domain Expert, Engineering | Explizite Regel, dokumentierte Abnahme |
Die Tabelle ist absichtlich knapp gehalten. Wenn eine Zeile in Ihrem Kontext nicht klar funktioniert, sind die Voraussetzungen vor dem Agent-Lauf noch nicht da.
Wo KI in Legacy-Code gefährlich wird
Die Gegenseite. Keine Liste von Ängsten, sondern eine präzise Diagnose der Ausfallmuster.
Geschäftslogik, die niemand aufgeschrieben hat. Jeder fünfzehn Jahre alte Monolith enthält undokumentierte Regeln: die Rundungskonvention eines Versicherers, der Sonderfall einer Aufsichtsbehörde, der Vertrag mit dem Kunden, der 2014 ein Nicht-Standard-Format durchgesetzt hat. Der Code zeigt eine Entscheidung, an die sich niemand mehr erinnert. Die KI liest den Code. Das Telefonat kennt sie nicht. Wenn sie die Rundung „verbessert" oder die Bedingung „vereinfacht", ist das System danach leise falsch. Die akademische Seite dieses Problems heißt „tacit knowledge", und eine arXiv-Vorveröffentlichung vom Oktober 2025 beschreibt sie als strukturelle Lücke, die ein LLM aus Quellcode allein nicht schließen kann.
Selbstbewusste Halluzinationen in unvertrauten Sprachen. COBOL, RPG, ABAP und proprietäre DSLs sind in den Trainingsdaten unterrepräsentiert. Das Modell produziert syntaktisch plausible Ausgaben mit subtil falscher Semantik. IBM hat das im Juli 2025 in einer eigenen Evaluation dokumentiert: Bei COBOL-zu-Java-Übersetzungen kann ein LLM-as-a-Judge subtile semantische Fehler übersehen. Genau deshalb kombinieren die Autoren das Sprachmodell mit analytischen Checks und Benchmarking, statt sich auf die Bewertung des Modells zu verlassen. Wer diesen Schritt überspringt, prüft Übersetzungen mit demselben Werkzeug, das sie produziert hat. In Mainframe-Domänen mit Transaktionsmanagern wie CICS ist das kein Review-Prozess, sondern eine Einladung zu Produktionsfehlern.
Selbstzufriedenheit mit KI-Code. Thoughtworks hat im Radar Vol. 33 einen zweiten Eintrag aufgenommen, der hier direkt zutrifft: „Complacency with AI-generated code" steht auf Hold, der schärfsten Warnstufe des Radars. Begründung: messbarer Rückgang an Refactoring-Aktivität in Commit-Historien, gestiegene Duplikation und gestiegener Code-Churn. Die Stack-Overflow-Entwicklerumfrage 2025 (rund 33.000 Antworten in der KI-Sektion) nennt als häufigste Frustration „AI solutions that are almost right, but not quite", 66 Prozent der Befragten. Fast richtig ist im Legacy-Refactor teurer als offensichtlich falsch, weil offensichtlich falsch beim Review auffällt und fast richtig nicht.
Wer ein Bild von dem braucht, was das auf Pull-Request-Ebene bedeutet, findet die Telemetrie in der Analyse zum Review-Engpass. Die Zahl muss hier nicht wiederholt werden. Das Muster ist das gleiche: Der Agent legt sich auf eine Änderung fest, ohne die Invariante zu verstehen, die der Code schützt. Die Lösung dafür heißt nicht „besseres Prompting". Die Lösung ist, den Agenten diese Entscheidung gar nicht erst treffen zu lassen.
Die Sequenz
Vier Stufen. Jede Tür bleibt zu, bis die vorherige geschlossen ist.
1. Baseline vor dem ersten Eingriff. Beobachtbarkeit am Altsystem. Logs, Metriken, Form des Produktions-Traffics. Sie müssen wissen, was das System heute messbar tut, bevor Sie ein Werkzeug daran lassen. Das ist keine KI-Arbeit. Das ist Disziplin.
2. Charakterisierungstests, von der KI geschrieben, vom Menschen validiert. Der Agent generiert Tests, die das aktuelle Verhalten festhalten. Sie füttern ihn mit repräsentativen Eingaben, lassen ihn Assertions vorschlagen und prüfen sie sorgfältig. Vorsicht: Wo „aktuelles Verhalten" in Wahrheit ein Bug ist, würden die Tests den Fehler nun zementieren. Die Testsuite ist der Vertrag mit der Zukunft. Ohne sie ist alles, was danach kommt, blind.
3. Strangler Fig als Architekturmuster, nicht als Marketingfolie. Martin Fowlers Pattern von 2004 ist operativ noch immer richtig: eine Fassade vor dem Monolithen, ein Bounded Context pro Runde extrahieren, den Monolithen als aktive Rückfallebene halten, jede Extraktion per Canary fahren. Der Agent darf innerhalb des Bounded Context arbeiten, den ein Mensch gewählt hat. Die Wahl der Grenze trifft der Agent nicht. Er weiß nicht, welcher Geschäftsbereich nächstes Quartal expandiert oder welcher Vertrag in sechs Monaten ausläuft. Das ist Architektur, und Architektur in Legacy-Systemen ist Geschäftsentscheidung, kein Codeproblem.
4. Kleine PRs, explizite Invarianten, benannte Reviewer. Das Budget aus den Magic-Words bleibt: drei Dateien, achtzig Zeilen pro Pull Request. Die Invarianten, die der Agent erhalten muss, stehen explizit im Prompt und in der Review-Checkliste: öffentliche Schnittstellen, Auth-Pfade, Datenmigrationen, alles mit Geld- oder Personenbezug. Für jede dieser Spuren ein namentlicher Reviewer. Nicht „das Team prüft", sondern „Maria prüft Auth, Tobias prüft Geldströme".
Die Sequenz ist langweilig. Das ist der Punkt. Spannung in einem Legacy-Refactor bedeutet, dass etwas schiefgeht.
Wo der Agent nicht entscheidet
Zwei Entscheidungen stehen vor jeder Agenten-Arbeit. Beide wirken technisch. Beide sind es nicht.
Wo darf der Code laufen? In vielen regulierten Branchen (Versicherung, Pharma, Energie, Bund) fließt Quellcode nicht an öffentliche Cloud-Endpunkte. Das ist keine Prompting-Frage und kein Modellvergleich. Es ist eine Entscheidung von Security, Legal, Einkauf und Engineering gemeinsam.
Die Werkzeugwahl läuft dann meist auf eine von vier Optionen hinaus: selbst betriebene Open-Weight-Modelle, kommerzielle Modelle mit zugesicherter EU Data Residency, dedizierte Enterprise-Deployments über Hyperscaler oder Infrastrukturpartner. Die technische Sequenz bleibt dieselbe: Baseline, Charakterisierungstests, kleine Extraktionen, enge Reviews. Aber der Ort, an dem der Agent läuft, entscheidet darüber, welche Werkzeuge überhaupt erlaubt sind. Welche Variante im konkreten Fall trägt, ist eine andere Diskussion, die im Mittelstand-Pfad skizziert ist.
Muss der Monolith überhaupt zerlegt werden? Die Strangler-Fig-Sequenz weiter oben beschreibt, wie ein Schnitt in Services kontrolliert aussehen kann, wenn er nötig ist. Die wichtigere Frage steht davor: Ist dieser Schnitt überhaupt die richtige Antwort?
Oft ist die bessere Modernisierung unspektakulärer: den Monolithen intern modularisieren, Tests nachziehen, Abhängigkeiten entwirren und bei einem einzigen Deployment bleiben. Sam Newman, Autor von Building Microservices, hat es 2020 nüchtern formuliert: Der Monolith ist nicht der Feind, verteilte Systeme sollten die letzte Wahl sein, nicht die erste.
KI ändert diese Rechnung nicht. Sie verschiebt nur die Versuchung. Wenn Agenten Code schneller extrahieren können, wirkt eine Zerlegung plötzlich billiger, als sie betrieblich ist. Mehr Services bedeuten mehr Deployments, mehr Schnittstellen, mehr Observability, mehr Incident-Flächen und mehr Abstimmung. Der Agent sieht diese Folgekosten nicht. Er sieht den Codeausschnitt vor sich.
Die erste Frage in jedem Modernisierungsprojekt lautet deshalb nicht: Wie schneiden wir den Monolithen? Sondern: Welches operative Problem löst der Schnitt überhaupt? Lautet die Antwort „keines", modernisiert das Projekt nicht das System, sondern das Selbstbild des Teams.
Zum Schluss
KI ist in der Legacy-Arbeit ein Werkzeug für gut definierte, prüfbare Transformationen. Archäologie, Charakterisierungstests, mechanische Übersetzung. Architekturentscheidungen und Geschäftsinvarianten bleiben beim Menschen, der das Telefonat von 2014 kennt oder zumindest den Kollegen, der sich noch daran erinnert. Wer diese Arbeitsteilung respektiert, verkürzt die Arbeit am Monolithen erheblich. Wer sie aufweicht, baut sich seine eigenen stillen Produktionsfehler.
Wenn Sie eine konkrete Refaktorierung planen, sollte die erste Frage nicht lauten: Welchen Agenten nehmen wir? Sondern: Welche Invarianten darf der Agent niemals verletzen, und welche Tests fehlen heute, um genau das zu beweisen? Genau diese Klärung passt in eine Stunde, bevor der erste Agent produktiv am Monolithen arbeitet.
