Was dein Entwickler am AI-Code ändert: Refactoring erklärt

Dein Entwickler hat den Code Review gemacht. Jetzt sagt er: „Ich muss erstmal refactoren.” Du fragst: „Was bedeutet das?” Er sagt: „Den Code aufräumen und verbessern.” Du denkst: „Warum kostet Aufräumen Geld? Die App funktioniert doch.”

Berechtigte Frage. Hier ist die Antwort — ohne Fachchinesisch.

Was ist Refactoring?

Refactoring bedeutet: Den Code ändern ohne das Verhalten zu ändern. Die App macht danach exakt das Gleiche wie vorher. Aber der Code ist besser organisiert, einfacher zu verstehen und leichter zu erweitern.

Die Analogie: Stell dir ein Lager vor. Alle Waren sind da, aber nichts ist sortiert. Kartons stehen überall, manche doppelt, manche blockieren den Zugang zu anderen. Du findest alles — irgendwann. Refactoring ist: Das Lager aufräumen, Regale einziehen, Beschriftungen anbringen. Danach findest du alles in Sekunden statt Minuten.

Die Waren im Lager ändern sich nicht. Das Lager wird nur nutzbar.

Warum AI-generierter Code Refactoring braucht

AI Tools wie Lovable, Bolt und Cursor produzieren funktionierenden Code. Aber AI hat drei strukturelle Eigenheiten die zu „unsauberem” Code führen:

1. Die AI hat kein Gesamtbild

Jeder Prompt wird isoliert behandelt. Prompt 15 weiß nicht was Prompt 3 gemacht hat. Das Ergebnis: Inkonsistenzen, Widersprüche und redundante Lösungen für das gleiche Problem.

Beispiel: Prompt 3 hat eine Funktion erstellt die Preise berechnet. Prompt 15 braucht die gleiche Berechnung auf einer anderen Seite — und erstellt sie nochmal, leicht anders. Jetzt gibt es zwei Preisberechnungen die nicht immer das gleiche Ergebnis liefern.

2. Die AI optimiert für „funktioniert”, nicht für „wartbar”

AI Tools produzieren Code der das tut was du sagst. Nicht Code der einfach zu ändern ist. Das ist ein Unterschied.

Beispiel: Du promptest „Zeige alle Aufträge als Tabelle mit Filterung.” Die AI baut eine 300-Zeilen-Komponente die alles macht: Daten laden, filtern, sortieren, anzeigen, Fehlermeldungen. Es funktioniert — aber wenn du den Filter ändern willst, musst du durch 300 Zeilen navigieren und hoffen, dass du nichts kaputtmachst.

3. Die AI kopiert Muster statt Architektur

AI basiert auf Mustern aus Trainings-Daten. Sie kopiert Lösungen die sie gesehen hat — unabhängig davon ob sie zum aktuellen Projekt passen.

Beispiel: Für einen einfachen Auftrags-Tracker hat die AI ein State-Management-Pattern implementiert das für eine App mit 100 Seiten designt wurde. Funktioniert, aber es ist wie einen Sattelschlepper zu fahren um Brötchen zu holen.

Die 6 häufigsten Refactoring-Maßnahmen

Maßnahme 1: Große Dateien aufteilen

Vorher: Eine Datei mit 500 Zeilen die alles macht — Daten laden, anzeigen, bearbeiten, speichern, Fehler behandeln.

Nachher: 5 Dateien mit je 100 Zeilen. Jede hat eine klare Aufgabe. Eine lädt Daten. Eine zeigt sie an. Eine behandelt Fehler.

Was du davon hast: Wenn der Filter nicht funktioniert, schaut der Entwickler in die Filter-Datei — nicht durch 500 Zeilen. Das ist schneller und damit günstiger.

Maßnahme 2: Duplikationen entfernen

Vorher: Die gleiche Berechnung steht an 4 Stellen im Code. Wenn sich die Logik ändert, muss der Entwickler alle 4 Stellen finden und ändern.

Nachher: Eine zentrale Funktion die überall wiederverwendet wird. Änderung an einer Stelle — überall korrekt.

Was du davon hast: Weniger Bugs, weil es nur noch eine Quelle der Wahrheit gibt. Und schnellere Änderungen, weil der Entwickler nur eine Stelle anpassen muss.

Maßnahme 3: Benennung verbessern

Vorher: const d = getData(); const x = d.filter(i => i.s === 'a');

Nachher: const orders = getOrders(); const activeOrders = orders.filter(order => order.status === 'active');

Was du davon hast: Der Code erklärt sich selbst. In 6 Monaten versteht jeder Entwickler sofort was dieser Code tut — ohne den Kontext von 50 vorherigen Prompts zu kennen.

Maßnahme 4: Fehlerbehandlung einbauen

Vorher: Wenn die API nicht antwortet, passiert nichts. Oder die App crasht. Oder Daten gehen verloren.

Nachher: Jede API-Anfrage hat einen Plan B. Netzwerk-Fehler werden abgefangen. Der Nutzer sieht eine verständliche Meldung. Fehler werden geloggt.

Was du davon hast: Deine Nutzer erleben keine weißen Seiten mehr. Und du erfährst von Problemen bevor die Nutzer sich beschweren.

Maßnahme 5: Business-Logik vom UI trennen

Vorher: Die Preisberechnung steckt in der Komponente die den Warenkorb anzeigt. Wenn du den Warenkorb umgestaltest, kann die Preisberechnung kaputtgehen.

Nachher: Die Preisberechnung ist eine eigene Funktion. Das UI ruft sie auf. Du kannst das UI komplett umbauen ohne die Berechnung zu berühren.

Was du davon hast: Änderungen am Design beeinflussen nicht die Geschäftslogik. Und umgekehrt. Das reduziert die Wahrscheinlichkeit von „Ich habe nur das Layout geändert und jetzt stimmen die Preise nicht mehr.”

Maßnahme 6: Abhängigkeiten aufräumen

Vorher: 80 externe Bibliotheken, 15 davon veraltet, 5 mit bekannten Sicherheitslücken, 10 die das Gleiche tun.

Nachher: 40 Bibliotheken, alle aktuell, keine bekannten Sicherheitslücken, keine Duplikate.

Was du davon hast: Weniger Angriffsfläche, schnellere App (weniger Code = schnellerer Download) und einfachere Updates in der Zukunft.

Was Refactoring kostet — und warum es sich lohnt

Typischer Aufwand: 20–40 Stunden für einen durchschnittlichen AI-Prototyp.

Typische Kosten: 2.000–5.000 € (je nach Komplexität).

Die Rechnung: - Ohne Refactoring: Jedes neue Feature braucht 20% mehr Zeit weil der Code schwer zu verstehen ist - Mit Refactoring: Jedes neue Feature braucht die normale Zeit

Bei 10 Features über 12 Monate: - Ohne Refactoring: 10 × 1,2 = 12 Feature-Einheiten Aufwand - Mit Refactoring: 10 × 1,0 = 10 Feature-Einheiten Aufwand + 1 Einheit Refactoring = 11

Ab dem 6. Feature hat sich das Refactoring bezahlt gemacht. Langfristig spart es 15–25% der gesamten Entwicklungskosten.

Woran du erkennst dass Refactoring sinnvoll ist

Nicht jeder Prototyp braucht Refactoring. Hier sind die Signale:

Refactoring lohnt sich wenn: - Du planst, langfristig an der App weiterzuentwickeln - Du einen Entwickler dauerhaft beschäftigst (monatliche Zusammenarbeit) - Dein Code mehr als 50 Prompts und 3 Monate alt ist - Einfache Änderungen unverhältnismäßig lange dauern - Jede Änderung neue Bugs erzeugt

Refactoring lohnt sich NICHT wenn: - Du den Prototyp nur kurzfristig für Validation nutzt - Du planst, die App komplett neu zu bauen - Die App weniger als 20 Nutzer hat und du noch validierst

FAQ: Häufig gestellte Fragen

Warum sieht die App nach dem Refactoring gleich aus?

Weil Refactoring per Definition das Verhalten nicht ändert. Es ist wie ein Motor-Tuning: Von außen sieht das Auto gleich aus, aber es fährt besser. Wenn du neue Features oder ein neues Design willst, ist das ein separater Schritt — der dank des Refactorings schneller und günstiger umgesetzt werden kann.

Kann die AI den Code nicht selbst refactoren?

Teilweise. AI Tools wie Claude Code können einfache Refactorings durchführen — Dateien aufteilen, Variablen umbenennen. Aber strategisches Refactoring — Architektur verbessern, die richtige Abstraktion wählen, technische Schulden abbauen — braucht menschliches Urteilsvermögen.

Wie lange dauert Refactoring?

Für einen typischen AI-Prototyp: 3–5 Arbeitstage. Bei komplexeren Prototypen mit vielen Prompts: 1–2 Wochen. Der Aufwand hängt von der Größe und Komplexität des Codes ab — und wie viele Prompts ohne Gesamtplan aufeinander gestapelt wurden.

Kann ich Refactoring vermeiden?

Wenn du den Prototyp für immer so nutzen willst wie er ist: Ja. Wenn du weiterentwickeln, skalieren oder einen Entwickler daran arbeiten lassen willst: Nein. Refactoring ist keine Luxus-Option — es ist die Investition die alles Weitere möglich und wirtschaftlich macht.

Was ist der Unterschied zwischen Refactoring und Neubau?

Refactoring: Bestehenden Code verbessern ohne das Verhalten zu ändern. Ergebnis: Gleiche App, besserer Code. Neubau: Von Null anfangen mit den Erkenntnissen aus dem Prototyp. Ergebnis: Neue App, neuer Code. Refactoring ist günstiger und schneller. Neubau ist sinnvoll wenn die Grundstruktur fundamental falsch ist.

Fazit: Refactoring ist der unsichtbare Held

Refactoring ist die unsexy Arbeit die niemand sieht. Keine neuen Features, kein neues Design — nur besserer Code. Aber es ist die Arbeit die den Unterschied macht zwischen einer App die nach 6 Monaten auseinanderfällt und einer die jahrelang stabil läuft.

Wenn dein Entwickler sagt „Ich muss refactoren”, ist das kein Zeichen von Langsamkeit. Es ist ein Zeichen von Professionalität. Er investiert jetzt in die Grundlage damit du später schneller und günstiger weiterentwickeln kannst.

Dein AI-Code braucht Struktur? Wir machen daraus sauberen, wartbaren Code — und jedes zukünftige Feature wird schneller und günstiger.

Jetzt Code professionalisieren