Future{hacks}: Der Code läuft noch. Das Wissen ist weg.
Trending Topics auf Google als bevorzugte Nachrichtenquelle festlegen.
Viele Unternehmen betreiben alte Kernsysteme, die kaum noch jemand versteht. AI kann dieses Wissen wieder zugänglich machen, jedoch nicht mit einem Prompt.
„Das greifen wir lieber nicht an.“
In den meisten dieser Unternehmen reicht dieser Satz, und alle wissen, welches System gemeint ist. Es läuft seit Jahren, hat Sonderregeln, schnelle Fixes und Übergangslösungen überlebt. Manche Schnittstelle war nur für ein Quartal gedacht und läuft noch heute. Und gerade weil es läuft, wurde es nie sauber erklärt!
Die ursprünglichen Entwickler:innen sind weg. Die Dokumentation passt nicht mehr zur Realität, aber der Fachbereich kennt die Anforderungen. Der Betrieb weiß, wann es kracht. Jedoch sieht niemand mehr das ganze Bild.
Genau das ist der eigentliche Legacy-Moment: der Punkt, an dem ein Unternehmen nicht mehr sicher erklären kann, warum ein geschäftskritisches System tut, was es tut.
Nur weil ein System läuft, heißt das noch lange nicht, dass es verstanden wird.
„Läuft doch“ ist kein Systemverständnis
Viele Unternehmen haben ihre Geschäftslogik nicht dokumentiert. Sie haben sie deployt.
In alten Codebasen stecken Preislogiken, kundenspezifische Ausnahmen, Prozessregeln, regulatorische Anpassungen, Schnittstellen zu Drittsystemen und Workarounds, die irgendwann unter Zeitdruck entstanden sind. Manche davon sind Altlast. Andere sind geschäftskritisch. Nach zehn oder zwanzig Jahren sieht beides im Code oft gleich aus.
In einem Logistikprojekt stand ein rund 20 Jahre gewachsenes System im Zentrum, das nicht nur Daten verarbeitet, sondern auch physische Prozesse mitsteuert. Die Basissoftware wurde seit Jahren kaum weiterentwickelt. Im Laufe der Zeit hatten viele Menschen an einzelnen Teilen gearbeitet, doch die ursprünglichen Wissensträger waren nicht mehr verfügbar.
Das Unternehmen wusste, dass der Prozess im Alltag läuft. Es wusste aber nicht mehr verlässlich, warum er läuft, welche Sonderfälle existieren und welche Abhängigkeiten von einer Änderung betroffen wären.
Genau dort beginnt das Risiko.
Für das Management ist das besonders unangenehm: Solange das System läuft, ist es schwer, Budget dafür zu bekommen. Sobald es ausfällt, ist es zu spät für eine saubere Analyse. Viele Legacy-Probleme entstehen nicht, weil jemand schlechte Software bauen wollte. Sie entstehen, weil Unternehmen über Jahre akzeptiert haben, dass „läuft“ als Qualitätsnachweis genügt.
Eine Migration ersetzt dann nicht einfach alte Technologie durch neue. Sie greift in ein System ein, das über Jahre zum unausgesprochenen Gedächtnis des Unternehmens geworden ist.
Der alte Code ist oft die letzte ehrliche Dokumentation.
Ein Prompt ist keine Migrationsstrategie
Ich habe darüber mit Simon gesprochen, Solution Architect bei LEAN-CODERS. Er arbeitet seit Jahren an der Schnittstelle zwischen gewachsenen Altsystemen und modernen Entwicklungsansätzen. Seine wichtigste Warnung betrifft nicht die Leistungsfähigkeit von AI, sondern den Umgang mit ihren Ergebnissen.
„Ein Prompt kann eine plausible Erklärung liefern. Aber bei Legacy-Systemen reicht plausibel nicht. Wir müssen wissen, welche Aussage durch Code, Daten, Logs oder Fachwissen belegt ist.“
Genau hier trennt sich AI-Hilfe von AI-Theater.
Bei Legacy-Systemen ist eine gut klingende Erklärung noch keine belastbare Dokumentation. Ein Modell kann Code zusammenfassen, Funktionen beschreiben und Zusammenhänge vermuten. Aber bei einem geschäftskritischen System muss klar sein, worauf eine Aussage basiert.
Deshalb beginnt ein sinnvoller AI-gestützter Analyseprozess nicht mit einer einzelnen Frage an ein Modell. Er beginnt mit einem kontrollierten Intake: Code, Datenmodelle, Logs, Batch-Jobs, alte Dokumente, Tickets, Deployment-Skripte und Gespräche mit Menschen, die einzelne Bereiche noch kennen.
Danach wird das System in kleinere Einheiten zerlegt. Kein Team versteht eine große Legacy-Codebasis auf einmal. AI auch nicht. Stattdessen arbeiten spezialisierte Agenten auf klar abgegrenzten Bereichen. Agenten sind in diesem Kontext AI-Komponenten mit einer definierten Aufgabe. Einige sammeln Kontext, andere analysieren Verhalten oder strukturieren Dokumentation. Wieder andere prüfen Ergebnisse gegeneinander.
Auch verschiedene Modelle können bewusst gegeneinander arbeiten, weil sie unterschiedliche Stärken und Schwächen haben. Der Punkt ist nicht Bestätigung, sondern Widerspruch. Das System soll Annahmen hinterfragen, Lücken markieren und erklären, warum es an bestimmten Stellen nicht sicher ist.
Bevor überhaupt analysiert wird, kommt eine Frage, die in AI-Demos gern übersprungen wird: Wohin darf dieser Code?
Alte Systeme können Zugangsdaten, interne Pfade, Datenbankverbindungen, Kundennummern, Geschäftsregeln oder Infrastrukturdetails enthalten. Wer nicht genau weiß, was im System steckt, weiß auch nicht genau, was an externe Dienste weitergegeben wird.
Aus diesem Grund sind in solchen Szenarien häufig souveräne LLM-Provider oder gut orchestrierte Open-Weight-Modelle die sinnvollere Wahl als Frontier-Modelle. In über Jahre gewachsenen Codebasen können sich schließlich persönliche Daten, Geschäftsgeheimnisse oder sogar aktive Zugangsdaten befinden. Diese sensiblen Informationen möchte verständlicherweise kein Unternehmen nach außen geben oder unkontrolliert verarbeiten lassen.
Das ist keine Ideologie. Das ist Risikomanagement.
AI muss Zweifel markieren, nicht Sicherheit vorspielen.
Ein guter Analyseprozess erzeugt am Ende nicht einfach „AI-Dokumentation“. Das wäre zu wenig.
Erstens braucht es eine verständliche Beschreibung des Systems: Module, Workflows, Datenflüsse, Schnittstellen, Sonderregeln und Risiken. Nicht als PDF, das nach dem Kick-off niemand mehr öffnet. Sondern so, dass Entwicklung und Fachbereich damit arbeiten können.
Zweitens braucht es eine verknüpfte Wissensbasis. Funktionen, Datenfelder, Prozesse, Schnittstellen und Geschäftsregeln sollten nicht isoliert nebeneinanderstehen, sondern miteinander in Beziehung gesetzt werden. Die vorhandenen Informationen werden dabei gebündelt und übersichtlich strukturiert. So können sie von einer anderen LLM nicht nur effizient verarbeitet, sondern auch gezielt durchsucht, sortiert, analysiert und abgefragt werden. Auf diese Weise entsteht eine zentrale Wissensgrundlage, die Zusammenhänge sichtbar macht und die weitere Nutzung der Informationen erheblich erleichtert.
Darauf kann später ein interner Assistent aufsetzen, der Fragen beantwortet wie: Wo wird diese Regel verwendet? Welche Prozesse hängen an diesem Feld? Was passiert, wenn wir diesen Teil ändern?
Drittens braucht es Tests für das heutige Verhalten. Das ist oft der härteste und wichtigste Teil. Ein Sprachmodell kann erklären, warum etwas vermutlich passiert. Ein Test zeigt, ob es bei denselben Eingaben tatsächlich passiert.
AI sortiert, Menschen verifizieren und Tests schaffen die nötige Sicherheit.
Simon beschreibt den Mehrwert folgendermaßen: „Der Mehrwert entsteht nicht, weil AI alles entscheidet. Der Mehrwert entsteht, weil sie zeigt, wo wir sicher sind und wo nicht. Genau dort müssen Entwickler:innen gezielt hinsehen.“
Das ist die eigentliche Effizienz! AI nimmt nicht die Verantwortung aus dem Prozess, sie verschiebt die menschliche Arbeit von breiter Spurensuche hin zu gezielter Prüfung.
Entwickler:innen müssen nicht mehr überall gleichzeitig graben. Sie sehen, welche Bereiche gut belegt sind, wo Widersprüche auftauchen und welche Stellen fachlich oder technisch kritisch bleiben. In großen Legacy-Systemen ist das ein massiver Unterschied. Nicht, weil AI fehlerfrei wäre, sondern weil der Prozess systematischer wird.
Im Logistikprojekt wurde dadurch nicht einfach Dokumentation erzeugt. Es wurden doppelte Abläufe, undokumentierte Nutzungen, unnötige Aktionen und fehleranfällige Stellen in der Steuerung sichtbar.
Ebenso wichtig: Die Analyse machte operative und wirtschaftliche Effekte sichtbar, die im alten System kaum erkennbar waren. Manche Abläufe verursachten vermeidbare Laufzeitkosten. Andere Leistungen waren im bestehenden Prozess nicht sauber abgebildet.
Das ist der Moment, in dem Legacy-Analyse für das Management interessant wird. Ein gutes System sagt nicht nur, was es weiß. Es zeigt auch, wo es zweifelt.
Unser Future{hacks} Fazit
Viele Entscheider:innen stellen sich bei Migrationen verständlicherweise die Frage: Warum sollen wir viel Geld ausgeben, damit danach scheinbar dasselbe passiert wie vorher?
Die unbequemere Antwort lautet: Weil zunächst bewiesen werden muss, dass dieses “Dasselbe” tatsächlich verstanden wurde, bevor man es verbessern kann.
Legacy-Modernisierung beginnt nicht mit der neuen Architektur. Sie beginnt mit der Frage, ob ein Unternehmen sein bestehendes Verhalten noch erklären und beweisen kann. Erst dann kann es entscheiden, was bleiben soll, was ersetzt wird und was längst abgeschaltet gehört.
AI kann dabei helfen, aber nur, wenn sie nicht als Abkürzung missverstanden wird. Gute AI liefert nicht nur Antworten. Sie markiert Unsicherheit, verbindet Wissen und lenkt menschliche Prüfung dorthin, wo sie zählt.
Die Frage ist daher nicht, ob ein altes System noch läuft. Die Frage ist, ob das Unternehmen noch erklären kann, warum es läuft.
Denn irgendwann wird aus „never touch a running system“ kein Sicherheitsprinzip mehr, sondern eine Ausrede.
Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.
