Blog

AI-Agents versprechen eine schnellere und einfachere Modernisierung von Legacy-Systemen. Im Interview erklärt Markus Harrer, warum nachhaltige Softwaremodernisierung trotzdem klare Leitplanken, Architekturwissen und bewährte Methoden wie Characterization Testing oder Seams braucht.

Viele Unternehmen hoffen aktuell auf „Softwaremodernisierung auf Knopfdruck“ durch AI-Agents. Was funktioniert heute tatsächlich schon gut – und wo beginnt die Illusion?

In klar abgesteckten, fachlich überschaubaren Bereichen mit verbreiteten Programmiersprachen ist bereits viel Sinnvolles möglich: Unit Tests generieren, erklärende Dokumentation für kleine, komplexe Code-Abschnitte erstellen, wo es wirklich gebraucht wird, sich beim Refactoring helfen lassen oder auch Funktionalität in gut strukturierten Codebasen erweitern.

Ich persönlich freue mich besonders über das mühelosere Erstellen von ganz spezifischen Analysewerkzeugen für ältere Softwaresysteme. Wo ich früher noch Python-Code tippen musste, erledigt das nun ein Coding Agent mit einem Large Language Model im Hintergrund für mich fast schon von allein. Ich bin auch ein großer Fan von hybriden KI-Ansätzen, wo etwa Coding Agents Refactoring-Skripte für mich bauen, die ich dann anschließend mit Code-Transformationstools deterministisch und sicher auf die Codebasis anwende. Auch das Durchspielen diverser alternativer Varianten im Design eines Systems mit einem Agenten als Sparring-Partner nutze ich immer gerne, um Denkblockaden oder blinde Flecken loszuwerden.

Es gibt aber auch viele Anwendungsfälle, die im Sales-Pitch super plausibel klingen, in der Praxis aber oft nicht sinnvoll sind. Ein Unternehmen wirbt etwa damit, dass seine Modernisierungsplattform dank des Einsatzes von KI hunderttausende Entwicklungsstunden eingespart hat bei der Erstellung von Codedokumentationen für die komplette Codebasis. Anhand eines Open-Source-Projekts auf GitHub zeigt das Unternehmen, wie ein Documentation Agent für eine ca. 100 Zeilen lange COBOL-Routine fast dreißig PDF-Seiten erzeugte. Wirklich beeindruckend, aber nur auf den ersten Blick. Ich frage mich bei so etwas immer, wer diesen ganzen Output validieren und später aktuell halten soll. Für mich fallen diese Art von KI-Anwendungen in die Kategorie „Es gibt nichts Sinnloseres, als das effizient zu tun, was überhaupt nicht getan werden sollte“, wie Peter Drucker es einmal gesagt hatte.

Du sagst, dass ein AI-Agent heute bereits eine Legacy Codebase über Nacht neu strukturieren kann. Warum reicht das allein noch nicht aus, um ein System wirklich erfolgreich zu modernisieren?

Wir sind heute technisch tatsächlich dazu in der Lage, mit der richtigen Orchestrierung und einem entsprechend hohen Budget mehrere Agenten parallel, kontinuierlich und automatisiert Veränderungen an einer Codebasis durchführen zu lassen. Die Firma Cursor hat beispielsweise Agenten fast eine Woche lang laufen lassen, um eine Browser-Engine von Grund auf neu bauen zu lassen. Die Zahlen waren beeindruckend: Billionen verbrauchter Tokens, Millionen generierter Zeilen Code, Tausende erzeugter Dateien. Hört sich großartig an. Aber vieles von dem, was am Ende herauskam, war einfach aus existierenden Implementierungen übernommen oder von den Agents gefaked worden.

Mir wäre das als Firma, die ein unternehmenskritisches System betreibt, viel zu heiß. Der Code der meisten Firmen ist proprietär, oft sehr interessant programmiert, voll implizitem Domänenwissen, das aber nirgendwo dokumentiert ist. Das macht es für Agents extrem schwierig, sinnvolle Ergebnisse zu liefern, da diese Informationen nicht in den Trainingsdaten der Modelle vorhanden sind. Ein Agent müsste sich hier eigentlich schwertun, merkt es aber nicht und generiert einfach munter weiter. Es ist schließlich nur Text, der wahrscheinlichkeitsbasiert weitergesponnen wird.

Noch gravierender vermisse ich die Betrachtung außerhalb des Quelltextes: Wer blind auf Codeebene modernisiert, bindet sich schnell „moderne Legacy“ ans Bein. Damit meine ich Code, der durch einen Agenten zwar technisch frisch aufgehübscht wurde, dessen implementierte Geschäftsabläufe aber längst überholt sind. Beim reinen Fokus auf den Code fehlt mir der unternehmerische Hebel. Eine echte Modernisierung muss immer auch die umgesetzten Prozesse hinterfragen.

Für mich gilt vor dem Einsatz von KI zur Modernisierung der gute alte Spruch von Scott Hanselman: „The less you do, the more you can do of it.“ Also alles, was ich gar nicht erst mit KI modernisieren muss, macht die Modernisierung von vornherein massiv schneller.

In deiner Session greifst du auf klassische Techniken der Legacy-Modernisierung zurück. Warum werden Methoden wie Characterization Testing oder Seams gerade im Zeitalter von AI-Agents wieder besonders relevant?

Characterization Testing oder Golden Master Testing hilft uns dabei, in einer bisher ungetesteten Codebasis zumindest ein grobes Sicherheitsnetz aufzubauen, bevor Agenten loslaufen und Veränderungen vornehmen. Das Prinzip ist ein Klassiker in der Software-Modernisierung: Man nimmt repräsentative Eingabedaten, lässt das aktuelle System sie verarbeiten, und schreibt die Ausgaben mit. Nach einem Refactoring oder einer Migration werden dieselben Eingabedaten vom erneuerten System verarbeitet, in der Hoffnung, dieselben Ausgaben wie zuvor herauszubekommen. Warum ist das im Zeitalter von KI-gestützten Migrationsprojekten wieder relevant? Weil ich so ein verlässliches, maschinenlesbares Feedback erzeugen kann, das den Agenten zurückmelden kann, ob sie das Verhalten des Systems erhalten haben oder nicht. Und dieses Feedback kann ich direkt zurückspiegeln, um eigenständiges Fehlerfinden und Korrigieren durch Agenten zu ermöglichen.

Aber wir brauchen auch präzisere Eingriffspunkte direkt im Code. Hier helfen Seams: Nahtstellen, an denen man das Verhalten eines Systems ändern kann, ohne den Code genau an dieser Stelle anzufassen. Das sind etwa bestehende Interfaces oder abstrakte Klassen. Der entscheidende Vorteil für Agenten: Gebe ich dem Agenten einen klar definierten Seam vor, muss er nicht das gesamte System verstehen. Er kennt den Zugangspunkt und den dahinterliegenden Codebereich. Damit stecken wir ihm einen eigenen kleinen Sandkasten. Ungewollte Änderungen quer durch die gesamte Codebasis werden damit erheblich unwahrscheinlicher. Das ist der entscheidende Unterschied zu einem Agenten, der ohne Scope quer durch das gesamte System navigiert, und einem, der in klar abgesteckten Bereichen agiert.

Du sprichst vom „Agent Blast Radius“. Welche Risiken entstehen, wenn AI-Agents ohne klare Leitplanken auf bestehende Systeme losgelassen werden?

Ohne klare Steuerung und Hilfsmittel greifen Coding Agents auf einfache textbasierte Suchwerkzeuge wie etwa grep und glob zurück. Sie verändern damit Stellen im Code rein nach Textmuster, also auf Zeichenkettenebene, nicht auf semantischer Ebene. In großen Codebasen mit vielen Abhängigkeiten führt das schnell dazu, dass verwandte Stellen wie Implementierungen, Überschreibungen, Referenzen schlicht übersehen werden und leise in die Brüche gehen.

Es braucht daher Orientierungshilfen auf verschiedenen Ebenen und zu verschiedenen Zeitpunkten. Ich unterscheide dabei zwischen einer Phase, bevor das Sprachmodell zum Einsatz kommt, und einer Phase, nachdem der Agent das Ergebnis umgesetzt hat.

In der Vorphase geht es vor allem darum, den eigentlichen Intent, also die Modernisierungsabsicht, über Kontext-Dateien wie CLAUDE.md oder AGENTS.md sauber zu formulieren und die Codebasis KI-tauglicher zu machen. Techniken wie Domain-Driven Refactoring oder die Einführung einer Mustersprache im Code helfen dabei, Struktur und Semantik des Quellcodes navigierbarer und gezielter veränderbar zu machen. Und das zahlt sich konkret aus: Wenn ein Klassenname „KundenMaskeController“ heißt und sich im Modul „bestandsfuehrung.partnerstamm“ befindet, statt nur „AKN002“ zu heißen, dann hat das Sprachmodell sofort mehr Orientierung, versteht den fachlichen Kontext und kann präziser arbeiten, statt planlos im System herumzuwühlen.

In der Post-Gen-Phase gibt es mehrere Wege, eine agentische Modernisierung in die richtigen Bahnen zu lenken. Der heute schon klassische Weg sind Feedback-Mechanismen wie Compiler-Rückmeldungen, Linter-Regeln und Fitness Functions. Diese decken bereits sehr viel ab und lassen sich inkrementell verfeinern, je nachdem, was Agent Critics oder menschliche Reviewer noch an Unschönheiten im Nachgang finden. Ein alternativer Weg ist, gar nicht erst in die Situation zu kommen, alles selbst validieren zu müssen. Dafür setze ich auf zwei Ansätze: Guided AI, bei dem das Sprachmodell nur das ändert, was zuvor deterministisch ein Analyse-Script identifiziert hat, und Code-Transformationsrezepte, erzeugt von KI. So bekomme ich je nach Problem das Beste aus beiden Welten: nicht-deterministische Intelligenz dort, wo sie hilft, und deterministische Verlässlichkeit bei den kritischen Stellen. Agenten bringen Geschwindigkeit, Leitplanken bringen Genauigkeit.

Besteht die Gefahr, dass Unternehmen durch den Einsatz von AI-Agents zwar schneller Code verändern, aber gleichzeitig immer weniger verstehen, was eigentlich im System passiert?

Ja, auf jeden Fall! Margaret-Anne Storey hat dafür einen sehr passenden Begriff geprägt: Cognitive Debt, also die kognitive Schuld, die entsteht, wenn das gemeinsame Verständnis eines Teams über das eigene System schleichend erodiert. Man denkt sich: ja, passt schon irgendwie und funktioniert ja auch alles. Aber wenn man doch mal einen Bug fixen muss, stellt man fest, dass niemand mehr wirklich erklären kann, warum das System so gebaut wurde wie es ist. Das Problem ist aber nicht neu.

Eng damit verknüpft ist die Intent Debt, die Margaret-Anne Storey ebenfalls beschrieben hat. Intent Debt entsteht, wenn Ziele, Constraints und Entscheidungsrationale gar nicht erst niedergeschrieben werden oder wenn einmal vorhandene Artefakte veralten und niemand sie pflegt. Hier blüht mein Herz für die Erkenntnistheorie aus meinem Informatikstudium regelrecht wieder auf: Was können wir überhaupt wissen, und was bleibt immer implizit? AI Agents arbeiten ausschließlich auf externalisiertem Wissen. Ein Agent kennt nur die Artefakte, die ihm vorliegen, aber nicht die Umstände und Überlegungen, die zu diesen Artefakten geführt haben.

Oder anders ausgedrückt: Es fehlt bei der Generierung von Code oft am Sinn und Zweck des Ganzen, also wozu und wofür Code generiert werden soll. Irgendwann weiß niemand mehr, warum ein Agent etwas in die Codebasis eingebracht hat. Dem Agenten ist das nämlich auch völlig egal. Er generiert einfach drauflos, völlig emotionslos und das auch noch superschnell, ohne die Vision durchdrungen zu haben und Leute um ihn herum mitzunehmen in die eigenen Überlegungen. Cognitive Debt und Intent Debt schaukeln sich dabei gegenseitig hoch: Wer die Ziele nicht kennt, kann kein gutes mentales Modell aufbauen und wer kein gutes mentales Modell hat, kann die Ziele nicht mehr sauber formulieren.

Gerade deswegen finde ich die unüberlegte Nutzung von Coding Agents in bestehenden Systemen sehr gefährlich. Hier können sich Unternehmen wirklich sehr schnell ins eigene Knie schießen. Daher werbe ich in meinem Vortrag für den verantwortungsvollen Umgang und für ergänzende bzw. alternative Herangehensweisen bei der Softwaremodernisierung.

Wie wird sich Softwaremodernisierung in den nächsten Jahren durch agentische Ansätze verändern? Werden AI-Agents langfristig eher Werkzeuge für Architekt:innen bleiben oder entwickeln sie sich zu eigenständigen Modernisierungspartnern?

AGI wird kommen und ein für alle Mal das Legacy-Modernisierungsproblem lösen! Nein, natürlich nicht. Viele kennen meine Ansichten hierzu bereits: Selbst AGI wird uns nicht die Arbeit abnehmen, denn bei AGI wären Agenten dann bereits so schlau, dass sie unseren Legacy-Code lieber nicht anfassen.

Aber ernsthaft: Ich finde es wichtig, entspannt auf den ganzen Hype da draußen zu schauen. Klar kann ich mir die tausendste Todo-Listen-App in TypeScript mit Claude Code in ein paar Minuten generieren lassen. Aber daraufhin zu erwarten, dass sich damit auch einfach eine 30 Jahre alte Lohnabrechnungssoftware in Assembler auf dem Mainframe mal eben umstellen lässt, ist leider naiv.

Es gilt vielmehr, im Bereich der KI-gestützten Werkzeuge zur Modernisierung auf dem Boden zu bleiben und gut nachzudenken, wo nicht-deterministische Vorgehensweisen einen Vorteil gegenüber den deterministischen haben oder wie beide Seiten sinnvoll miteinander kombiniert werden können. Unternehmen sollten sich zudem Gedanken machen, was außerhalb der Codebasis möglich ist: Kann man Teile durch Standardsoftware ersetzen? Kann man ungeliebte Fachlichkeiten auslagern? Braucht man überhaupt noch all die Sonderlösungen für Kunden, die es längst nicht mehr gibt? Das und noch viel mehr sind die Fragen, die unbedingt vorher gestellt werden müssen.

Aber als Modernisierungspartner? In bestimmten Bereichen nutze ich Agents oder auch einfach nur einen Chat als Modernisierungsbuddy zum Verbessern von Bezeichnern, für das Ad-hoc-Reverse-Engineering und als ständigen Sparring-Partner. Aber ja, eigenständige Modernisierungspartner kann ich mir auch durchaus vorstellen. Ich denke gerade über Counselor-Agents nach, die wie Commander Deanna Troi auf der Enterprise arbeiten: die aktuelle Situation bewerten, Widersprüche entlarven und auf blinde Flecken hinweisen. Aber das ist vielleicht doch noch etwas zu stark Science Fiction.

Aber auch egal, was ich mache. Im Grunde muss jedes Entwicklungsteam selbst herausfinden, was in der eigenen Situation am besten passt. „Es kommt drauf an!“ ist nicht umsonst der Lieblingsspruch aller Softwarearchitektinnen und Softwarearchitekten.

Mehr zum Thema gibt es beim Software Architecture Forum 2026. In seiner Session zeigt Markus Harrer, wie sich AI-Agents verantwortungsvoll in der Modernisierung von Legacy-Systemen einsetzen lassen und warum bewährte Techniken wie Seams, Characterization Testing und Fitness Functions dabei wichtiger denn je sind.

Über den Sprecher:

Markus Harrer arbeitet seit mehreren Jahren in der Softwareentwicklung und ist vor allem in konservativen Branchen tätig. Als Senior Consultant hilft er, Software nachhaltig und wirtschaftlich sinnvoll zu entwickeln und zu verbessern. Er ist aktiver Mitgestalter in Communities zu den Themen Software Analytics, Softwarearchitektur, Softwaresanierung und Wardley Maps. Zudem ist er akkreditierter Trainer für den iSAQB Foundation Level und dem Advanced-Level-Modul IMPROVE.