Refactoring von KI-generiertem Code: Vorgehen, das nichts kaputt macht

Refactoring heißt: die innere Struktur von Code verbessern, ohne sein äußeres Verhalten zu verändern. Bei KI-generiertem Code kommt eine Schwierigkeit hinzu — Sie bauen etwas um, das niemand im Team geschrieben hat. Deshalb steht am Anfang nicht der Umbau, sondern ein Netz aus Tests, das das aktuelle Verhalten festhält.

Was ist Refactoring — und was ist es nicht?

Die Definition ist eng und die Enge ist der Punkt: Struktur ändern, Verhalten nicht. Sobald sich das Verhalten ändert, ist es kein Refactoring mehr, sondern eine Fehlerbehebung oder ein Feature.

Diese Trennung ist keine Begriffspflege. Sie ist der Grund, warum Refactoring sicher sein kann: Wenn das Verhalten unverändert bleiben soll, gibt es einen eindeutigen Prüfmaßstab — die Tests, die vorher grün waren, müssen nachher grün sein. Vermischen Sie beides, verlieren Sie diesen Maßstab.

Warum wird bei KI-gestützter Entwicklung kaum noch refaktoriert?

Weil Refactoring Verständnis des Bestands voraussetzt und generierter Code dieses Verständnis nicht miterzeugt. Die Zahlen sind deutlich: Nach der GitClear-Analyse fiel der Anteil verschobenen Codes — der beste verfügbare Näherungswert für echtes Umbauen — von 21 Prozent im Jahr 2022 über 13 Prozent (2023) auf 3,8 Prozent im laufenden Jahr 2026.

Beides zusammen beschreibt eine Verschiebung: Es wird angebaut statt umgebaut. Für ein Modell ist das der naheliegende Weg — eine neue Funktion daneben zu schreiben ist risikofrei, eine bestehende umzubauen erfordert zu wissen, wer sie sonst noch benutzt.

Wie refaktoriere ich Code, den ich nicht geschrieben habe?

In fünf Schritten, deren Reihenfolge nicht verhandelbar ist.

• 1. Verhalten festschreiben. Bevor Sie irgendetwas ändern: Tests, die das aktuelle Verhalten festhalten — auch das, was Ihnen falsch vorkommt. Diese Tests sind kein Qualitätsurteil, sondern ein Sicherungsnetz. Fällt später einer um, wissen Sie, dass Sie etwas verändert haben.
• 2. Abhängigkeiten kartieren. Wer ruft diesen Code auf? Wer verlässt sich auf sein Verhalten? Bei generiertem Code gibt es häufig mehr Aufrufer als erwartet, weil Muster mehrfach entstanden sind.
• 3. In kleinen Schritten umbauen. Ein Schritt, ein Testlauf, ein Commit. Ein Refactoring-Commit über 40 Dateien ist nicht überprüfbar und im Zweifel nicht rückrollbar.
• 4. Duplikate zuletzt zusammenführen. Erst wenn die Einzelstellen sauber sind, sehen Sie, ob sie wirklich dasselbe tun. Zwei Stellen zusammenzuführen, die sich in einem Detail unterscheiden, erzeugt genau den Fehler, den man vermeiden wollte.
• 5. Zwischenstände liefern. Ein Refactoring, das drei Wochen auf einem Branch liegt, kollidiert mit allem, was in der Zwischenzeit passiert.

Kann ich das Refactoring von einer KI machen lassen?

Für mechanische Umbauten ja, für strukturelle nur unter Aufsicht — und in beiden Fällen nur mit dem Netz aus Schritt 1.

• Gut geeignet: konsistente Umbenennungen, Extraktion einer Funktion, Aufteilung einer überlangen Datei, Ergänzen fehlender Typangaben, Vereinheitlichen von Fehlerbehandlung.
• Nur mit Prüfung: Zusammenführen von Duplikaten. Das Modell muss beurteilen, ob zwei Stellen wirklich dasselbe tun — ein Urteil, das Kenntnis der Fachlogik verlangt.
• Nicht delegieren: Schnitt der Module, Datenmodell, Schnittstellen zwischen Komponenten. Das sind Architekturentscheidungen, keine Umbauten.

Ohne Testabdeckung kehrt sich der Nutzen um: Ein Werkzeug, das schnell viel umbaut, verteilt einen Fehler in derselben Geschwindigkeit über das ganze Projekt. Deshalb ist Schritt 1 keine Formalie — siehe Testabdeckung bei KI-Code.

Wie bekomme ich Zeit für Refactoring bewilligt?

Indem Sie nicht danach fragen. Refactoring als eigenes Vorhaben zu beantragen scheitert zuverlässig, weil es keinen sichtbaren Nutzen liefert, der sich in einem Termin zeigen ließe.

Was funktioniert, ist die Kopplung an Arbeit, die ohnehin stattfindet: Wer ein Feature in einen Bereich baut, räumt diesen Bereich mit auf. Der Aufwand steckt in der Schätzung des Features, das Review findet ohnehin statt, und es wird genau dort aufgeräumt, wo tatsächlich gearbeitet wird — also dort, wo es sich rechnet.

Wo das nicht reicht, hilft die Datenlage aus dem eigenen Repository: Welche fünf Dateien wurden im letzten Quartal am häufigsten geändert, und wie komplex sind sie? Diese Liste ist ein Kostenargument, kein Geschmacksurteil. Mehr dazu unter technische Schulden durch KI-Code.

Häufige Fragen zum Refactoring

Was ist der Unterschied zwischen Refactoring und Rewrite?

Refactoring verändert die Struktur schrittweise bei durchgehend lauffähigem System. Ein Rewrite ersetzt einen Teil vollständig. Refactoring ist risikoärmer und langsamer; ein Rewrite lohnt sich, wenn niemand mehr versteht, was umgebaut werden soll.

Brauche ich für jedes Refactoring Tests?

Für jedes, das Sie nicht rückgängig machen können, ohne es zu merken. Praktisch heißt das: ja. Die Ausnahme sind rein mechanische, werkzeuggestützte Umbenennungen innerhalb einer Datei.

Wie groß darf ein Refactoring-Commit sein?

So groß, dass ein Reviewer ihn in einem Zug lesen kann. Das ist eine handfestere Grenze als jede Zeilenzahl und führt in der Praxis zu kleinen Commits.

Was mache ich, wenn beim Refactoring ein Fehler auffällt?

Notieren, Refactoring zu Ende bringen, Fehler in einem eigenen Commit beheben. Beides zu vermischen kostet Sie den Prüfmaßstab „Tests waren vorher grün und sind es nachher".

Der gefährlichste Moment beim Umbau ist der, in dem sich nebenbei das Verhalten ändert — und niemand es merkt, weil kein Test danach fragt. Code Guardian zieht vor jeder Änderung die Abhängigkeiten nach und prüft danach, ob der Diff nur das angefasst hat, was er anfassen sollte.

Quellen

• Martin Fowler, Refactoring (Definition und Katalog der Umbauschritte).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research (Anteil verschobenen Codes 2022 bis 2026).

Stand: 27. Juli 2026. Allgemeine fachliche Einordnung.