Engineering-Disziplin 20. Juli 2026 4 Min. Lesezeit

Legacy Code mit KI retten: der Praxis-Leitfaden

Die Rescue-Welle ist da: KI-gebaute Apps, die nach drei Monaten kippen, und Legacy-Systeme, die niemand mehr versteht. Wie du eine solche Codebase übernimmst — Triage, Tests, Agenten-Regeln — statt sie tiefer zu vergraben.

von Nicolas Schmid

Die Rettungswelle, vor der die alte Garde gewarnt hat, ist keine Prognose mehr. Branchenauswertungen sprechen davon, dass ein Grossteil der Startup-Apps, die 2025 im Vibe-Coding-Tempo entstanden sind, inzwischen Umbau- oder Rettungsarbeit braucht — manche Analysten haben 2026 schlicht zum „Jahr der Tech-Schulden" erklärt. Ich sehe es in Anfragen: „Wir haben da etwas bauen lassen. Es lief super. Jetzt traut sich niemand mehr, etwas anzufassen."

Legacy Code mit KI retten ist deshalb gerade die vielleicht wertvollste Engineering-Disziplin überhaupt. Und sie wird fast überall falsch angegangen — mit demselben Werkzeug und derselben Hast, die das Problem erzeugt haben.

Warum KI-Schulden anders sind als klassische

Klassische Tech-Schulden entstehen bewusst: Jemand kannte die Abkürzung und hat sie genommen. KI-Schulden entstehen unsichtbar: Der Code wurde generiert, nie wirklich gelesen, und sah von aussen korrekt aus. Es gibt niemanden im Team, der die Entscheidung erinnert, weil nie jemand eine getroffen hat.

Das Muster ist inzwischen so verbreitet, dass es einen Namen hat: der Spaghetti-Punkt. Wochen eins bis vier fühlen sich phantastisch an. Um Monat drei herum beginnt jedes neue Feature, zwei alte zu brechen. Fehlerbehandlung fehlt, Logik ist dupliziert, und die Datenbank vertraut jedem, der freundlich fragt — Sicherheits-Audits von KI-gebauten Apps finden regelmässig komplett deaktivierte Zugriffskontrollen, nicht falsch konfigurierte.

Wenn du so ein System übernimmst, ist dein Feind nicht der Code. Es ist der Reflex, sofort zu bauen.

Woche 1: Triage, nicht Therapie

Bevor irgendetwas verbessert wird, brauchst du Antworten auf fünf Fragen. Das ist die Checkliste, mit der ich jedes Rescue-Projekt beginne:

Läuft es reproduzierbar? Frische Maschine, Build, Deploy, ein Ende-zu-Ende-Durchlauf. Wenn das nicht geht, ist das Baustelle Nummer eins — nicht das Refactoring.
Wo ist der Blast-Radius? Was ist produktiv, wer hängt dran, wo fliessen Geld und persönliche Daten? Rettung priorisiert nach Schadenspotenzial, nicht nach Code-Hässlichkeit.
Security-Quickscan. Secrets im Repo, offene Endpoints, Zugriffskontrollen auf Datenbank-Ebene, Abhängigkeiten mit bekannten Lücken. Eine Stunde, die Existenzen retten kann.
Was behauptet das System zu tun? Nicht die Doku lesen (es gibt keine) — das Verhalten festhalten. Dazu gleich mehr.
Retten oder neu bauen? Erst jetzt entscheidbar. Faustregel: Ist das Datenmodell im Kern brauchbar und das Produkt validiert, wird gerettet. Ist beides kaputt, ist der ehrlichste Rat ein kontrollierter Neubau — mit Disziplin diesmal.

Charakterisierungs-Tests: das Sicherheitsnetz zuerst

Der wichtigste Schritt, und der am häufigsten übersprungene: Bevor du Code änderst, schreibst du Tests, die das Ist-Verhalten einfrieren — inklusive der Bugs. Nicht „was sollte es tun", sondern „was tut es heute". Michael Feathers nannte sie Charakterisierungs-Tests, und sie sind der Unterschied zwischen Refactoring und Roulette.

Hier ist die KI zum ersten Mal wirklich nützlich: Agenten sind hervorragend darin, aus bestehendem Code Testfälle für die goldenen Pfade zu erzeugen und Geschäftslogik in Prosa zu extrahieren. Lass den Agenten beschreiben und absichern, bevor er irgendetwas verbessert. Lesen vor Schreiben — dieselbe Reihenfolge, die beim Review von KI-Code über Leben und Tod entscheidet.

Mit dem Agenten retten, ohne tiefer zu graben

Ja, KI hilft beim Retten — mit denselben Werkzeugen, die das Chaos angerichtet haben. Der Unterschied liegt in vier Regeln:

Erklär-Pass zuerst. Der Agent liest Modul für Modul und dokumentiert, was er vorfindet — Annahmen, Datenflüsse, tote Pfade. Du korrigierst die Prosa, nicht den Code. Das Ergebnis ist die Landkarte fürs ganze Projekt.
Keine Änderung ohne Netz. Jeder Umbau-Schritt setzt einen bestehenden (Charakterisierungs-)Test voraus. Kein Test, kein Umbau — der Agent schreibt erst den Test.
Kleine, reviewbare Schritte. Ein Modul, eine Grenze, ein Pull Request. Grosse „Ich hab mal alles aufgeräumt"-Diffs sind bei einer fremden Codebase ein Kündigungsgrund — auch für Agenten.
Grenzen einziehen, dann aufräumen. Erst Schichten trennen (I/O, Logik, Persistenz), dann innerhalb der Grenzen modernisieren. Ohne Grenzen verschiebt Refactoring das Chaos nur örtlich.

So wird aus dem Tool, das die letzten 20 % übersprungen hat, das Werkzeug, das sie nachliefert.

Was du diese Woche tun kannst

Nimm ein Projekt, dem du nicht traust — ein geerbtes, ein KI-gebautes, ein eigenes von vor einem Jahr — und geh nur Schritt 1 bis 3 der Triage durch: reproduzierbarer Lauf, Blast-Radius, Security-Quickscan. Drei Stunden, und du weisst, ob du ein Wartungsproblem hast oder eine tickende Uhr.

Und wenn die Uhr tickt und intern niemand Kapazität hat: Genau solche Rettungen sind eine der wenigen Auftragsarten, die wir pro Jahr annehmen — von der Triage bis zur übergebbaren, getesteten Codebase. Schreib uns an hire@halvic.ch.