Die Anfrage klingt neu, und sie wird häufiger: „Unser Backend hat ein Entwickler in anderthalb Jahren allein gebaut, größtenteils mit KI. Er ist weg. Es läuft, aber niemand traut sich ran, und die Infrastruktur versteht keiner.“ Das Framework ist aktuell, die PHP-Version ist aktuell, es gibt eine Pipeline. Nichts daran sieht nach 2008 aus.
Trotzdem ist es dieselbe Situation wie beim Entwickler, der in Rente geht. Nur schneller entstanden.
Was junges Legacy konkret heißt
- Das Wissen ist weg. Wer den Code generiert hat, hat ihn selten gelesen. Wer ihn übernimmt, hat niemanden, der ihn erklären kann. Die Übergabe dauert 15 Minuten, weil es nicht mehr zu übergeben gibt.
- Entscheidungen ohne Grund. Infrastruktur, Abstraktionen, Konfigurationen wurden vorgeschlagen und durchgewunken. Sie sind nicht falsch, sie sind unbegründet, und das ist beim ersten Problem dasselbe.
- Mehr Code als Geschäft. Vorauseilende Konfigurierbarkeit, generische Schichten, Features „für später“. Jede Zeile davon muss verstanden werden, bevor jemand etwas ändern kann.
- Infrastruktur für den Tag der Entstehung. Was auf einer VM für zehn Nutzer lief, wächst nicht mit, und das fällt genau dann auf, wenn das Geschäft wächst.
- Sicherheit, die plausibel aussieht. Auth, Secrets, Zugriffe: generiert, nie geprüft. Das ist der Punkt, den ich in solchen Systemen zuerst anschaue.
Was passiert, wenn Sie nichts tun
Jemand baut weiter, meist mit demselben Werkzeug, weil das schnell geht. Das Werkzeug kennt den Grund für den bestehenden Aufbau nicht und verstärkt ihn. Nach einem weiteren Jahr hat das System doppelt so viel Code, dieselbe Infrastruktur und immer noch niemanden, der es erklären kann. Der Auslöser, der dann alles dringend macht, ist erfahrungsgemäß Last: eine Kampagne, ein Messetermin, ein Saisongeschäft. Unter Last zeigt sich, was die Infrastruktur nicht kann, und dann ist keine Zeit für einen Befund.
Die drei realistischen Optionen
Option A: Weiterbauen mit demselben Werkzeug
Schnell, günstig, vertraut. Für ein Wochenend-Projekt richtig.
Woran es scheitert: An der Verstärkung. Ohne jemanden, der das System gelesen hat, baut das Werkzeug konsistent in die Richtung weiter, die schon unbegründet war. Jede Woche Weiterbauen macht den späteren Befund größer und den Umbau teurer.
Option B: Neubau
Alles neu, diesmal richtig, mit oder ohne KI.
Woran es scheitert: Ohne Review entsteht dasselbe Ergebnis mit neuem Datum. Mit Review dauert es Monate, in denen das alte System weiterlaufen und gepflegt werden muss, und die Regeln, die im Betrieb inzwischen gelten, stehen nur im alten Code. Ein Neubau ohne Befund des Alten wirft genau die weg.
Option C: Geordnete Übernahme
Befund: Ich lese das System, bis ich es erklären kann. Was trägt, was ist gefährlich, was existiert ohne Grund. Dann Sofortmaßnahmen, dann Wissen auf mehrere Köpfe verteilen, dann Umbau Modul für Modul, während das Alte weiterläuft, mit dem Alten als Spezifikation für das, was es tatsächlich tut.
Woran es scheitert: An der Erwartung, dass es schnell geht. Die erste Etappe ist Lesen, nicht Bauen, und das fühlt sich für ein Unternehmen, das gewohnt ist, dass Features in Tagen entstehen, langsam an. Sie ist der Grund, warum die folgenden Etappen halten.
Die Reihenfolge, die ich empfehle
- Heute: Zugänge und Backups. Dieselbe Liste wie bei jedem verwaisten System: Hosting, Registrar, Datenbank, API-Schlüssel, Deploy-Keys, CI-Variablen. Bei KI-gebauten Systemen zusätzlich: Welche Werkzeuge hatten Zugriff auf den Code, und mit welchen Schlüsseln.
- Diese Woche: Befund. Zwei bis drei Werktage. Ergebnis: Systembeschreibung, die jemand außer dem Autor versteht, Risiko-Karte mit Sicherheit und Infrastruktur an erster Stelle, Liste dessen, was ohne Bedarf existiert, Aufwandsband für Umbau in Etappen.
- Sofort danach: Sofortmaßnahmen und Bus-Faktor. Sicherheitspunkte schließen. Mindestens eine zweite Person einarbeiten, bevor irgendetwas umgebaut wird.
- Dann Umbau in Etappen oder Werkstatt-Bereitschaft, je nach Befund. Wenn ein fester Termin ansteht, zuerst nur das, was der Termin braucht, der Rest danach.
Wie ich KI dabei einsetze
Für die Inventur ist KI in solchen Systemen das beste Werkzeug, das ich habe: Abhängigkeiten kartieren, Muster finden, tote Konfiguration aufspüren. Der Unterschied zum Zustand, den Sie geerbt haben, ist das Review. Jede generierte Änderung geht durch Tests und Prüfung, und ich verantworte das Ergebnis. Mehr dazu unter KI-gestützte Modernisierung.
Für wen dieser Weg nicht passt
Ein Prototyp ohne Umsatz, ohne Kundendaten und ohne Termin braucht keinen Befund. Er braucht jemanden, der ihn einmal liest und sagt, ob es sich lohnt, ihn zu behalten. Das ist der kostenlose Kurz-Check, und häufiger als man denkt ist die Antwort: neu, klein, diesmal mit Review.
