KI-Refactoring von 10.000 Zeilen Legacy-Code: Echte Retrospektive – ein Monatsaufkommen in 2 Wochen

Anfang Oktober kam ein dringendes Projekt auf den Tisch: ein Vue-2.x-Bestellverwaltungssystem mit rund 10.000 Zeilen Kerngeschäftslogik, Testabdeckung unter 10 %, State-Management so verworren, dass der Datenfluss kaum nachvollziehbar war – und seit drei Jahren hatte sich niemand mehr getraut, groß einzugreifen. Die Vorgabe vom Lead: in zwei Wochen refaktorieren und live gehen.

Zwei Wochen – refaktorieren und deployen.

Mein erster Gedanke: Das ist unmöglich. Klassisch per Hand bräuchte man allein eine Woche, um die Fachlogik zu verstehen, dann vorsichtiges Umbauen, Tests, Validierung – 30 bis 40 Tage reichen oft nicht. Die Fachseite konnte nicht warten; das System war so langsam, dass Nutzer sich beschwerten.

Dann fiel mir Claude Code ein – ein Kollege hatte es für große Refactorings empfohlen. Ehrlich gesagt war ich skeptisch: Ist KI-Refactoring verlässlich? Was, wenn etwas in Produktion bricht?

Alternativen gab es kaum. Ich habe es versucht.

Zwei Wochen später, als ich auf Deploy drückte und im Monitoring alles grün blieb, war die Erleichterung groß. Vierzehn Tage, null Vorfälle in Produktion, API-Latenz etwa 20 % besser, Bug-Rate rund 40 % niedriger.

In diesem Artikel geht es um diese 14 Tage: Ablauf, Stolpersteine und übernehmbare Erfahrungen. Wenn Sie ähnliche Tech Debt abbauen oder KI-gestütztes Refactoring prüfen wollen, sollte das hier helfen.

Projekthintergrund: Wie chaotisch es wirklich war

Kurz zum Ausgangslage.

Es ist das zentrale Bestellsystem des Unternehmens – täglich etwa 5.000 Bestellungen, mit Erstellung, Zahlung, Logistik, After-Sales und mehr als zehn Prozessen. Der Code stammt von Anfang 2022 (Vue 2.x); der ursprüngliche Frontend-Entwickler war weg, danach vier weitere Maintainer mit unterschiedlichen Stilen und vielen Patches.

Wie schlimm? Zwei Tage Diagnose, dann die Bilanz:

1. 10.000 Zeilen Kerngeschäftslogik – einzelne Dateien bis 1.800 Zeilen; OrderService.js mit 47 Methoden
2. Testabdeckung unter 10 % – wenige einfache Unit-Tests, kritische Pfade unabgedeckt
3. Chaotisches State-Management: Vuex, LocalStorage, SessionStorage, globaler Event-Bus – vier Wege parallel, Datenfluss unklar
4. Massive Duplikate: dieselbe Bestellstatus-Logik 23-mal kopiert
5. Performance: Bestellliste 3–4 Sekunden Ladezeit, viele Beschwerden

Das System lief trotzdem täglich für Tausende Nutzer. Große Eingriffe ohne Netz waren riskant – ein Fehler und der Betrieb steht.

Wie lange klassisch?

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Am Whiteboard die Schritte:

1. Fachlogik verstehen (5–7 Tage)
2. Tests ergänzen (7–10 Tage)
3. Module zerlegen (10–15 Tage)
4. Schrittweise refaktorieren und prüfen (8–12 Tage)
5. Integrationstests + Canary (5 Tage)

Minimum 35 Tage, ohne Rückschläge.

Ich hatte 14.

Warum Claude Code

Vor der Wahl war ich unsicher.

Es gibt viele KI-Coding-Tools: GitHub Copilot nutze ich regelmäßig, Cursor hat gute Reviews, Claude Code war neu. Warum am Ende Claude Code?

Kleiner Vergleich

Einen halben Tag investiert: die komplexeste Funktion – Bestellstatus-Update, 200+ Zeilen mit Grenzfällen, Async, Fehlerbehandlung – an Copilot, Cursor und Claude Code.

Ergebnis:

• GitHub Copilot: eher fragmentierte Vorschläge, wie Completion – bei großem Refactoring schwach.
• Cursor: solide, versteht Absicht – bei komplexer Fachlogik manchmal Kontextverlust, mehr Erklärungsaufwand.
• Claude Code: Refactoring plus drei potenzielle Bugs, Empfehlung „erst Tests“, klare Schritte – das hat überzeugt.

Entscheidend: Kontext. 200K Token – grob 150.000 Wörter Code – genug für die Kernmodule eines mittleren Projekts und ihre Beziehungen, nicht nur eine Datei.

"Das 200K-Token-Kontextfenster von Claude Code fasst genug Code für Kerngeschäftslogik und Modulverknüpfungen in einem mittelgroßen Projekt."

Refactoring in der Praxis: die 14 Tage

Hier der konkrete Ablauf inkl. Stolpersteine.

Vorbereitung: Sicherheitsnetz (Tag 1–2)

Beim Refactoring ist das größte Risiko Regression – deshalb zuerst das Sicherheitsnetz, nicht sofort umbauen.

Aufgabe 1: Tests ergänzen

Erster Prompt an Claude Code: Testfälle generieren.

Ich: Das ist der Kern des Bestellmoduls (ca. 3000 Zeilen Code eingefügt).
Analysiere die wichtigsten Geschäftsabläufe und erstelle vollständige Tests –
Schwerpunkte: Bestellung anlegen, Zahlung, Rückerstattung, Statuswechsel.

Claude lieferte mehr als erwartet: Unit-Tests nach Szenario, kommentiert. Nach Anpassung der Grenzfälle: zwei Tage, Abdeckung von 10 % auf 45 %.

Klassisch: mindestens eine Woche.

Aufgabe 2: Code-Diagnose

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Mit Tests als Rückhalt: vollständige „Untersuchung“:

Ich: Bitte Code-Qualität dieses Projekts analysieren –
Fokus: Code Smells, Duplikate, Performance-Engpässe, potenzielle Bugs.
Liefere einen detaillierten Bericht.

Ergebnis: ein ~20-seitiger Bericht mit

• 87 Code Smells (zu lange Funktionen, tiefe Verschachtelung, Namen …)
• 23 Duplikatstellen
• 14 Performance-Hinweisen
• 5 möglichen Bugs (zwei später bestätigt)

Das wurde die Refactoring-Roadmap.

Refactoring: Mensch und KI (Tag 3–10)

Im eigentlichen Umbau hat sich ein Rhythmus eingespielt.

Rhythmus 1: Schmerzpunkte zuerst

Erster Schnitt: processOrder mit ~800 Zeilen – Validierung, Lager, Rabatt, Zahlung, Benachrichtigung in einer Funktion.

Prompt:

Ich: processOrder ist zu monolithisch. Bitte refaktorieren:
1. In kleine, einzelverantwortliche Funktionen aufteilen
2. Max. 50 Zeilen pro Funktion
3. Gemeinsame Logik in Utilities
4. 100 % funktionale Kompatibilität
5. Tests für jede neue Funktion

Vorschlag: Aufteilung in sechs Funktionen:

• validateOrderParams() – Validierung
• checkInventory() – Lager
• calculateDiscount() – Rabatt
• processPayment() – Zahlung
• sendNotifications() – Benachrichtigung
• createOrder() – Orchestrierung

Klassisch drei Tage, mit Claude Code ein halber Tag.

Qualitätssicherung: Validierung (Tag 11–13)

Umbau ist nicht das Ende – drei Tage nur Tests und Review.

Ebene 1: Automatisierte Tests

• Unit: 187 Fälle, alle grün
• Integration: 34 Szenarien, 100 %
• E2E: Kernprozesse durchgespielt

Die zuvor generierten Tests zahlten sich hier aus.

Ebene 2: Code-Review
Automatisierte Review durch Claude: zwei Findings – schlechter Variablenname, fehlende Async-Fehlerbehandlung.

Go-live und Monitoring (Tag 14)

25. Oktober, Freitag, 15 Uhr – ruhige Phase.

Canary-Strategie:

• 15:00 5 % Traffic, 30 Minuten Monitoring
• 15:30 10 %
• 16:00 30 %
• 17:00 Voll-Rollout

Das Team stand bereit für Rollback. Als alles grün blieb und die Latenz von ~450 ms auf ~360 ms sank, war die Anspannung vorbei.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Ergebnis:

• Null Produktionsvorfälle
• API-Latenz ~20 % besser
• Bug-Rate ~40 % niedriger
• SonarQube von C auf A
• Testabdeckung 10 % → 75 %

Prompt-Vorlagen aus der Praxis

Vier Vorlagen zum Kopieren und Anpassen.

Vorlage 1: Code-Diagnose

Ich habe ein [Projekttyp]-Projekt mit [Tech-Stack].
Kerngeschäftslogik: [Code einfügen]

Bitte vollständige Diagnose, Schwerpunkte:
1. Code Smells (zu lange Funktionen, Verschachtelung, Namen …)
2. Duplikate und extrahierbare gemeinsame Logik
3. Performance-Engpässe
4. Mögliche Bugs und Sicherheitsrisiken

Bericht mit Priorisierung.

Vorlage 2: Refactoring

Bitte folgenden Code refaktorieren: [Code einfügen]

Anforderungen:
1. Kleine, einzelverantwortliche Funktionen, max. [50] Zeilen
2. Duplikate in Utilities
3. Bessere Namen nach [Team-Standard]
4. 100 % funktionale Kompatibilität
5. Tests pro neuer Funktion

Constraints:
- Nur Struktur, keine Fachlogik-Änderung
- Keine neuen Dependencies (außer explizit genannt)
- Unklaren Code nicht löschen – markieren zur Bestätigung
- Stil des Projekts: [Beschreibung]

Kontext:
[Aufrufer, Typen, relevante Definitionen]

Vorlage 3: Testgenerierung

Kernmodul [Modulname]: [Code einfügen]

Bitte vollständige Tests:
1. Framework: [z. B. Jest/Vitest]
2. Hauptszenarien: [Liste]
3. Grenzfälle (null, ungültig, Extremwerte)
4. Fehlerszenarien (Timeout, API-Fehler)
5. Kommentar pro Test mit Zweck

Ziel Abdeckung: >70 %

Vorlage 4: Code-Review

Refactoring abgeschlossen – bitte prüfen:

Original: [Code]
Nach Refactoring: [Code]

Prüfen:
1. Neue Bugs oder Logikfehler
2. Performance (überflüssige Schleifen, Berechnungen)
3. [Team-Standard]
4. Sicherheit (SQL-Injection, XSS …)
5. Namen und Kommentare
6. Testabdeckung

Detailliertes Feedback und Verbesserungen.

Abschluss

Anfang Oktober war die Anspannung groß – heute wirkt der Code wieder beherrschbar.

14 Tage, 10.000 Zeilen, von der unangetasteten Basis bis zum stabilen Go-live – das hat mein Bild von KI-gestützter Entwicklung verschoben.

KI ist kein Wundermittel. Sie trifft keine Geschäftsentscheidungen, ersetzt kein Fachverständnis und übernimmt kein Risiko. Aber als Assistent – wie ein erfahrener Senior neben Ihnen für Review, Tests und Hinweise – ist sie stark.

Effizienz entsteht durch Zusammenarbeit. Sie liefern Domäne und Urteil, die KI Tempo und Patterns. So schafft eine Person oft das Dreifache bei höherer Qualität.

Wenn Sie vor ähnlicher Tech Debt stehen:

1. Ausprobieren – die Tools sind reif genug
2. Klein starten – ein Modul, Rhythmus finden
3. Wach bleiben – KI ist stark, nicht perfekt; Review bleibt Pflicht
4. Vorbereitung – Tests, Monitoring, Rollback

Tech Debt verschwindet nicht von selbst. Mit Tools wie Claude Code ist das Abtragen weniger schmerzhaft – manchmal sogar befriedigend.