Ich bin 2025 in ein Unternehmen eingestiegen, eine sehr junge Modemarke, und habe dort ein Projekt übernommen, das der bisherige alleinige Entwickler anderthalb Jahre vorher begonnen hatte. Die Übergabe dauerte 15 Minuten. Danach war das System meins.
Auf dem Papier war das kein Legacy-Fall. Symfony mit API Platform, Container-Orchestrierung, eine Message-Queue, eine verwaltete Datenbank, CI-Pipeline. Alles keine zwei Jahre alt. In der Praxis hatte es jedes Merkmal, das ich sonst in Systemen aus 2008 finde, und ich schreibe das hier auf, weil ich glaube, dass diese Fälle in den nächsten Jahren häufiger werden als die klassischen.
Was ich vorgefunden habe
Der Code war zu einem großen Teil mit KI-Werkzeugen generiert worden, und zwar ohne das Review, das solchen Code brauchbar macht. Man sieht das an Details, die für sich harmlos wirken: Emojis in den Skripten der CI-Pipeline. Man sieht es an Entscheidungen, die für sich nicht falsch sind, aber niemand getroffen hat: eine Container-Orchestrierung, die auf gemieteten virtuellen Maschinen läuft und beim ersten echten Lastanstieg nicht mitwächst, eine extern gehostete Message-Queue, deren Rolle im System niemand erklären konnte.
Und man sieht es an der Vorausschau. Features waren konfigurierbar gemacht worden für Anforderungen, die es nicht gab. Jede dieser Konfigurationsmöglichkeiten war Code, der gepflegt, getestet und verstanden werden musste, und niemand wusste mehr, ob eine davon jemals gebraucht würde. Das ist derselbe Effekt wie die „für später“ eingebauten Verzweigungen in einem alten Warenwirtschaftssystem. Nur dass hier keine zehn Jahre vergangen waren, sondern 18 Monate.
Warum das Legacy ist
Legacy heißt nicht alt. Legacy heißt: Das System trägt das Geschäft, und niemand kann es mehr mit Sicherheit ändern. Die Merkmale sind immer dieselben, unabhängig vom Baujahr:
- Das Wissen steckt in einem Kopf, und der Kopf ist weg. Hier: 15 Minuten Übergabe.
- Entscheidungen im Code haben keinen erkennbaren Grund. Hier: von der KI vorgeschlagen, vom Menschen durchgewunken.
- Es gibt mehr Code, als das Geschäft braucht. Hier: die vorauseilende Konfigurierbarkeit.
- Die Infrastruktur passt zu dem Tag, an dem sie gebaut wurde, nicht zu dem, an dem sie skalieren muss.
KI-generierter Code ohne Review erzeugt diesen Zustand in Monaten, wofür Code von Hand Jahre braucht. Nicht weil die Werkzeuge schlecht wären, sondern weil sie Code produzieren, den niemand im Team je gelesen hat. Ein Entwickler, der eine Verzweigung selbst geschrieben hat, erinnert sich zwei Jahre später noch ungefähr, warum. Bei generiertem Code gibt es dieses Warum nicht, es gab nur einen Prompt.
Was zuerst
Es gab einen festen Messetermin, und die bestehende App musste bis dahin mit einem Backend laufen, das den Termin überlebt. Also kein Umbau. Zuerst Stabilisieren:
- Das System lesen, bis ich es erklären konnte. Welche Anfrage läuft wo durch, welche Queue-Nachricht bewirkt was, welche Konfiguration ist tatsächlich aktiv.
- Die Pipeline entrümpeln, damit ein Deployment wieder eine wiederholbare Sache war, nicht ein Ritual.
- Neue Kollegen ins Backend-Team holen und einarbeiten. Ein System mit Bus-Faktor 1 bleibt Legacy, egal wie sauber der Code wird. Das Wissen musste auf mehrere Köpfe, und zwar bevor ich anfing, Dinge zu ändern.
- Nur die Änderungen, die der Messetermin brauchte. Alles andere auf die Liste.
Danach: Rewrite in Etappen
Nach der Messe haben wir App und Backend neu aufgebaut, das Backend im Wesentlichen unter meiner Hand: Ich habe dort die Mehrheit der Commits und der geänderten Zeilen. „Neu aufgebaut“ heißt hier nicht Big Bang, sondern Modul für Modul, während das alte weiterlief, mit dem alten System als Spezifikation dafür, was es tatsächlich tut, statt dafür, wie es gebaut war.
Was rausgeflogen ist: die Konfigurierbarkeit ohne Bedarf, Infrastrukturteile, die niemand erklären konnte, die Abstraktionen, die nur existierten, weil ein Werkzeug sie vorgeschlagen hatte. Was geblieben ist: das Framework, die API-Schicht, die Geschäftsregeln, die sich im Betrieb bewährt hatten.
Das Backend-Team hat in dieser Zeit rotiert. Dass das den Rewrite nicht gestoppt hat, lag daran, dass das Wissen inzwischen im System steckte, in Struktur, Tests und Dokumentation, und nicht mehr in einer Person. Das war das Ergebnis von Schritt 3, nicht Glück.
Das Ergebnis
Nach vier Monaten Entwicklung war die E-Commerce-App live und erfolgreich. Eine Zahl dazu darf ich nicht nennen, und ich erfinde keine.
Was davon für Ihre Anwendung gilt
Wenn in Ihrem Unternehmen in den letzten zwei Jahren eine Anwendung überwiegend mit KI-Werkzeugen entstanden ist, stellen Sie drei Fragen, bevor jemand darauf weiterbaut:
- Kann jemand außer dem Autor erklären, warum die Infrastruktur so aussieht, wie sie aussieht?
- Wie viel des Codes wurde je von einem Menschen gelesen, nicht nur ausgeführt?
- Was passiert, wenn der Autor morgen nicht mehr da ist? Wenn die Antwort „15 Minuten Übergabe“ ist, haben Sie ein Legacy-System, und das Baujahr spielt keine Rolle.
Ich setze KI-Werkzeuge selbst ein, bei jeder Modernisierung, für Inventur, Mustersuche und repetitive Umbauten. Der Unterschied ist das Review: Jede generierte Änderung geht durch dieselben Tests und dieselbe Prüfung wie meine eigene. Ohne diesen Schritt entsteht kein Zeitgewinn, sondern Legacy im Schnellverfahren.
