„Nur eine kleine Änderung.“ Eine Artikel-Kategorie in einer Anwendung sollte in zwei aufgeteilt werden. Das klingt nach einer Zeile in einer Konfigurationsdatei. In Wirklichkeit waren es 83 Änderungen in sieben Dateien. Der Fall zeigt, was Refactoring mit KI leisten kann, und woran man erkennt, dass sich ein Eingriff in den Code lohnt.
Eine Änderung, 83 Stellen
Jede Artikel-Kategorie hatte ihre eigenen Variablen, ihre eigenen Methoden und ihre eigenen Fallunterscheidungen. Der Code war an vielen Stellen kopiert und leicht angepasst worden. Was als Aufgabe für fünf Minuten geplant war, wurde zu einer Wanderung quer durch die gesamte Codebasis.
Das ist ein typisches Warnsignal. Wenn eine kleine fachliche Änderung viele technische Stellen berührt, ist die Struktur des Codes nicht mehr passend zum Geschäft. Jede künftige Kategorie würde wieder denselben Aufwand erzeugen, und bei jeder Anpassung steigt das Risiko, eine der Stellen zu vergessen. Wie solche Altlasten entstehen und warum sie so selten aufgeräumt werden, beschreibt der Beitrag Technische Schulden.
Die Erkenntnis kam auf dem Heimweg: Das kann so nicht bleiben. Und wie der ursprüngliche Code durch das Review gekommen ist, ist eine Frage für sich.
Refactoring mit KI: das Ziel statt der Anweisung
Am nächsten Morgen bekam Claude Code die Aufgabe, den Code so umzubauen, dass neue Artikel-Kategorien mit minimalem Aufwand hinzugefügt werden können. Es gab keine Schritt-für-Schritt-Anleitung, sondern ein Ziel, das sich an der Zahl der nötigen Änderungen messen lässt.
Nach rund 15 Minuten lag das Ergebnis vor:
- ein eigener Aufzählungstyp für die Kategorien statt fest eingetragener Textwerte
- eine Zuordnungstabelle statt fünf mal kopierter Felder
- Schleifen über alle Kategorien statt kopierter Codeblöcke
- über 300 Zeilen weniger Code
Eine Stelle blieb offen. Für jede neue Kategorie brauchte es dort noch eine Zeile Code. Ich habe das angemerkt, und Claude hat die Schlüssel in der Konfigurationsdatei daraufhin automatisch aus den Namen des Aufzählungstyps abgeleitet. Für eine neue Kategorie braucht es jetzt genau zwei Änderungen: einen neuen Wert im Aufzählungstyp und einen neuen Eintrag in der Konfiguration. Aus 83 Änderungen sind zwei geworden.
Was der Mensch dabei geleistet hat
Die KI hat den Umbau geschrieben. Die Arbeit des Menschen lag an anderen Stellen. Er hat erkannt, dass der Zustand des Codes das eigentliche Problem war und nicht die einzelne Änderung. Er hat ein messbares Ziel formuliert. Und er hat gesehen, dass der erste Entwurf noch eine Restarbeit pro Kategorie enthielt, die das Ziel verfehlte.
Das passt zu dem, was wir in anderen Beiträgen beschrieben haben. Wer KI ohne Blick auf das Ergebnis einsetzt, bekommt Code, der läuft, aber nicht unbedingt der beste ist. Wie das Verhältnis von Tempo und Urteilsvermögen aussieht, zeigt der Beitrag Vibe Coding oder Agentic Coding. In diesem Fall hat die Prüfung des Ergebnisses den Unterschied zwischen „gut“ und „fertig“ gemacht.
Warum sich solche Aufräumarbeit jetzt eher lohnt
Solche Umbauten blieben bisher oft liegen, weil neue Funktionen im Backlog Vorrang hatten. Dauert die Arbeit nur eine Viertelstunde, verschiebt sich die Rechnung. Aufräumen, das lange unwirtschaftlich war, kann zum Normalfall werden.
Das ist ein Gegengewicht zu dem Effekt, den der Beitrag Vibe Coding: Vom Hype zur Realität beschreibt: KI kann technische Schulden im Zeitraffer erzeugen, sie kann sie aber auch im Zeitraffer abbauen. Welche der beiden Richtungen eintritt, hängt davon ab, ob jemand das Ziel vorgibt und das Ergebnis prüft.
Was Verantwortliche daraus mitnehmen
Aus dem Fall lassen sich drei Hinweise ableiten:
- Den Änderungsaufwand als Kennzahl beobachten. Wenn eine kleine fachliche Änderung viele Dateien berührt, ist das ein Hinweis auf Handlungsbedarf, lange bevor die Anwendung Probleme macht.
- Ein Refactoring mit KI als Ziel formulieren, das sich prüfen lässt, etwa „neue Kategorien mit zwei Änderungen“. Dann lässt sich auch ein Ergebnis beurteilen, das beim ersten Versuch noch nicht stimmt.
- Den Umbau wie jede andere Änderung durch Review und bestehende Tests absichern. Die Geschwindigkeit der KI ersetzt diese Prüfung nicht.
Eine Einschränkung gibt es auch. Claude Code ist nicht für jede Aufgabe geeignet. Je häufiger man es nutzt, desto mehr Anwendungsfälle findet man, aber das entscheidet sich im Einzelfall.
Fazit
Aus einer kleinen Änderung, die in 83 Stellen mündete, wurde ein Refactoring, das in rund 15 Minuten den Aufwand für künftige Kategorien auf zwei Änderungen senkte und über 300 Zeilen Code entfernte. Entscheidend waren ein messbares Ziel und eine kritische Prüfung des ersten Ergebnisses. Wer mit KI aufräumt, sollte klein anfangen, das Ziel genau benennen und das Ergebnis selbst beurteilen.
