"Das hat die KI gebaut" – ein Satz, der inzwischen ähnlich oft fällt wie "das war schon so, als ich hier angefangen habe". Dahinter steckt meistens eine ehrliche Geschichte: Ein Gründer, ein kleines Team oder ein einzelner Entwickler wollte schnell etwas in Produktion bringen. Mit Cursor, Copilot oder Claude wurden Features in Stunden statt Wochen gebaut. Es hat funktioniert – bis es nicht mehr funktioniert hat. Und jetzt sitzt du hier und liest diesen Artikel.

Was Vibe Coding hinterlässt

Vibe Coding ist kein Vorwurf. Es ist eine rationale Entscheidung unter Zeitdruck. Das Problem ist nicht, dass KI Code generiert – das Problem ist, was dabei strukturell entsteht: Logik ohne Schichten, Abhängigkeiten ohne Richtung, Funktionen, die zu viel wissen, und keine Tests, weil die KI nie gefragt wurde, ob der Code korrekt ist, sondern nur, ob er läuft.

Das Ergebnis ist eine neue Art von Legacy-Code. Kein gewachsener Monolith aus den Neunzigern – sondern ein Geflecht aus KI-Iterationen, das von niemandem im Team vollständig durchdrungen wurde. Hochmodern und trotzdem unwartbar. Das schafft nicht jeder.

Wo ich starte: Verstehen vor Verändern

Der erste Schritt ist derselbe wie bei klassischem Legacy-Code: Ich versuche zu verstehen, was das System tatsächlich tut – nicht was es tun soll. Bei vibe-coded Projekten ist dieser Schritt besonders wichtig, weil Intention und Implementierung oft auseinanderdriften. Eine Funktion heißt calculateDiscount, hat aber auch Datenbankzugriffe und schreibt in den Session-Store. Weil die KI das damals irgendwie sinnvoll fand.

Statische Analyse mit psalm oder phpstan liefert einen ersten Überblick. Danach schaue ich mir die Hotspots an – Dateien mit vielen Abhängigkeiten, hoher Komplexität und ohne Test-Abdeckung.

Charakterisierungstests als Sicherheitsnetz

Bevor ich eine Zeile anfasse, schreibe ich Charakterisierungstests. Keine Unit-Tests nach klassischem Verständnis – sondern Tests, die das aktuelle Verhalten dokumentieren, egal ob es korrekt ist oder nicht. Das klingt seltsam, ist aber entscheidend: Ich brauche ein Netz, das mir sagt, wenn mein Refactoring etwas verändert, das ich nicht verändern wollte.

Das Ziel von Charakterisierungstests ist nicht Korrektheit – es ist Stabilität während der Transformation.

Refactoring in kleinen, sicheren Schritten

KI-generierter Code hat eine Eigenheit: Er ist oft lokal kohärent, aber global inkonsistent. Dieselbe Logik taucht an drei verschiedenen Stellen auf, leicht abgewandelt – weil bei jedem Prompt der Kontext ein bisschen anders war. Deshalb ist Extrahieren die wichtigste Refactoring-Technik: Duplizierung zusammenführen, benennen, testen.

Ich arbeite mich von außen nach innen: zuerst die Einstiegspunkte (Controller, API-Endpoints, CLI-Commands), dann die Serviceschicht, zuletzt die Datenzugriffslogik. Jeder Schritt ist ein eigener Commit, jede Änderung wird durch bestehende Tests abgesichert.

KI als Refactoring-Partner – aber mit Verstand

Interessanterweise lässt sich KI auch beim Refactoring einsetzen – aber mit einer anderen Haltung. Statt "Baue mir das Feature" lautet die Frage: "Was macht dieser Code? Welche Abhängigkeiten hat er? Wie könnte ich diese Funktion isolieren, ohne das Verhalten zu ändern?" KI als Gesprächspartner, nicht als Autopilot. Der Unterschied ist ungefähr so groß wie zwischen einem Navigationssystem und einem Fahrer, dem man einfach die Schlüssel überlässt.

Fazit

Vibe Coding ist kein Qualitätsproblem per se – es ist ein Prozess ohne Qualitätsstufe. Was fehlt, ist die Phase nach der Entstehung: das Verstehen, Benennen und Strukturieren. Genau da setzt gutes Refactoring an. Nicht um die KI rückgängig zu machen, sondern um das Ergebnis wartungsfähig zu machen – für Menschen, die damit noch Jahre arbeiten werden.