Clean Code mit AI schreiben - Wartbarer Code 2026

Clean Code mit AI schreiben: Refactoring-Prompts, SOLID-Prinzipien, Code Smells erkennen und beheben. 10 Prompts für sauberen, wartbaren Code mit ChatGPT & Claude.

Einleitung

KI kann nicht nur Code generieren – sie kann auch bestehenden Code besser machen. Refactoring, Code Smells erkennen, SOLID-Prinzipien anwenden: Hier spielt AI ihre volle Stärke aus. In diesem Artikel findest du 10 Prompts, die deinen Code sauberer, wartbarer und professioneller machen.

Zusätzlich gibt es einige bewährte Tipps für den Alltag.

Im Folgenden gehe ich auf die wichtigsten Details ein.

Prompt 1: Automatisches Code Review

Ebenfalls relevant sind die praktischen Anwendungsbeispiele.

Du bist ein Senior Developer mit 15 Jahren Erfahrung. Führe ein Code Review durch:

```
[Code hier einfügen]
```

Prüfe auf:
1. **Bugs & Logik-Fehler**: Race Conditions, Off-by-One, Null-Pointer
2. **Security**: SQL Injection, XSS, unsichere Inputs
3. **Performance**: Unnötige Loops, Memory Leaks, N+1 Queries
4. **Clean Code**: Naming, Funktionslänge, Single Responsibility
5. **Error Handling**: Fehlende try/catch, generische Catches
6. **TypeScript**: Korrekte Typen, kein `any`, keine Type Assertions

Für jedes Problem:
- Schweregrad: 🔴 Kritisch / 🟡 Warnung / 🔵 Vorschlag
- Zeile(n) betroffen
- Problem-Beschreibung
- Konkreter Fix (Code-Snippet)

Am Ende: Gesamtbewertung (1-10) mit Begründung.

Ebenfalls sinnvoll ist es, verschiedene Varianten auszuprobieren.

Vor allem in der Praxis hat sich dieser Workflow bewährt.

Prompt 2: Refactoring-Vorschläge

Somit kannst du direkt mit der Umsetzung beginnen.

Analysiere diesen Code und schlage Refactoring vor:

```
[Code hier einfügen]
```

Identifiziere:
1. Code Smells (Long Method, God Class, Feature Envy, etc.)
2. Design Pattern Opportunities (Strategy, Factory, Observer, etc.)
3. Abstraktionsmöglichkeiten (gemeinsame Interfaces, Base Classes)
4. Duplizierter Code

Für jedes Refactoring:
- Vorher: Relevanter Code-Ausschnitt
- Nachher: Refactored Version
- Pattern/Prinzip: Welches Designprinzip wird angewandt
- Risiko: Wie wahrscheinlich ist ein Bug durch das Refactoring
- Priorität: Hoch / Mittel / Niedrig

Außerdem kannst du den Prompt für verschiedene Programmiersprachen anpassen.

Allerdings gibt es dabei einige Punkte, die du beachten solltest.

Prompt 3: SOLID-Prinzipien anwenden

Zusammenfassend lässt sich sagen, dass dies ein zentraler Aspekt ist.

Prüfe diesen Code auf SOLID-Prinzipien:

```
[Code hier einfügen]
```

Analysiere jedes Prinzip:

1. **S – Single Responsibility**
   - Hat jede Klasse/Funktion genau eine Aufgabe?
   - Welche sollten aufgeteilt werden?

2. **O – Open/Closed**
   - Kann das Verhalten erweitert werden ohne es zu ändern?
   - Wo fehlen Abstraktionen?

3. **L – Liskov Substitution**
   - Können Subklassen überall für ihre Elternklasse eingesetzt werden?
   - Gibt es Verletzungen?

4. **I – Interface Segregation**
   - Werden Interfaces zu groß? Zwingen sie Klassen ungenutztes zu implementieren?

5. **D – Dependency Inversion**
   - Hängt der Code von Abstraktionen ab oder von konkreten Implementierungen?
   - Wird Dependency Injection genutzt?

Liefere für jede Verletzung den konkreten Fix mit vorher/nachher Code.

Dabei zeigt dieses Beispiel den grundlegenden Ansatz.

Zudem lassen sich die Ergebnisse auch auf andere Projekte übertragen.

Prompt 4: Bessere Benennung

Grundsätzlich gibt es dabei einige Punkte zu beachten.

Verbessere die Benennung in diesem Code:

```
[Code hier einfügen]
```

Regeln:
1. Variablen: Beschreibend, nicht abgekürzt (data → userData, tmp → temporaryFile)
2. Funktionen: Verb + Substantiv (get → fetchUserById, calc → calculateTotalPrice)
3. Booleans: isX, hasX, canX, shouldX (flag → isActive, check → hasPermission)
4. Konstanten: UPPER_SNAKE_CASE, selbsterklärend (3600 → SECONDS_PER_HOUR)
5. Klassen: Substantiv, PascalCase, kein „Manager" oder „Helper"
6. Event Handler: handleX, onX (click → handleSubmitClick)
7. Async: fetchX, loadX, resolveX

Für jede Umbenennung:
- Alt → Neu
- Begründung in einem Satz

Hierbei hilft es, von konkreten Beispielen auszugehen.

Prompt 5: Komplexität reduzieren

Im Grunde vereinfacht dieser Ansatz den gesamten Workflow erheblich.

Reduziere die Komplexität dieses Codes:

```
[Code hier einfügen]
```

Techniken anwenden:
1. **Early Return**: Verschachtelte if/else durch Guard Clauses ersetzen
2. **Extract Method**: Lange Funktionen in kleinere Teile aufteilen 
   (Ziel: max. 20 Zeilen pro Funktion)
3. **Replace Conditional with Polymorphism**: switch/case durch Klassen
4. **Lookup Tables**: if/else-Ketten durch Objects/Maps ersetzen
5. **Decompose Conditionals**: Komplexe Bedingungen in benannte Funktionen
6. **Remove Nesting**: Promise-Chains mit async/await flatten

Für jede Verbesserung:
- Cyclomatic Complexity vorher → nachher
- Code vorher → nachher
- Lesbarkeit-Score (1-10) vorher → nachher

Deshalb empfiehlt es sich, den Prompt schrittweise zu verfeinern.

Ebenso hilfreich ist ein strukturierter Ansatz bei der Umsetzung.

Prompt 6: Error Handling verbessern

Allerdings gibt es einige wichtige Unterschiede zu beachten.

Verbessere das Error Handling in diesem Code:

```
[Code hier einfügen]
```

Prüfe und verbessere:
1. **Fehlende Error Handling**: Wo kann etwas fehlschlagen ohne try/catch?
2. **Generische Catches**: `catch(e) {}` → spezifische Error-Typen
3. **Custom Error Classes**: ApplicationError, ValidationError, NotFoundError
4. **Fehler-Propagation**: Wo sollten Fehler weitergegeben vs. behandelt werden?
5. **User-facing Errors**: Technische Details verstecken, freundliche Messages
6. **Logging**: Fehler loggen aber nicht verschlucken
7. **Retry Logic**: Für transiente Fehler (Netzwerk, DB-Timeout)
8. **Graceful Degradation**: Fallbacks statt Crashes

Liefere:
- Custom Error Classes (TypeScript)
- Verbesserten Code mit Error Handling
- Error Boundary / Global Handler Pattern

Im Grunde funktioniert dieser Ansatz mit allen gängigen AI-Tools.

Somit ergibt sich ein klarer Vorteil gegenüber manuellen Methoden.

Prompt 7: DRY – Duplikate entfernen

Ebenso wichtig ist es, die Best Practices zu kennen.

Finde und entferne Duplikate in meinem Code:

Dateien:
```
[Code aus Datei 1]
```

```
[Code aus Datei 2]
```

```
[Code aus Datei 3]
```

Finde:
1. Exakte Duplikate (Copy-Paste Code)
2. Strukturelle Duplikate (gleiche Logik, andere Variablen)
3. Daten-Duplikate (Magic Numbers, wiederholte Strings)

Lösung für jedes Duplikat:
- Shared Utility Function / Klasse
- Generics / Templates wo möglich
- Constants für wiederholte Werte
- Higher-Order Functions für ähnliche Patterns

Ziel: Jede Logik existiert genau einmal.

Weiterhin ist es ratsam, die Ergebnisse immer kritisch zu prüfen.

Im Grunde sparst du dadurch langfristig viel Zeit.

Prompt 8: Testbaren Code schreiben

Folglich profitierst du von einem besseren Verständnis dieser Konzepte.

Mache diesen Code testbar:

```
[Code hier einfügen]
```

Aktuell untestbar weil:
- [z.B. "Direkte DB-Aufrufe in der Business Logic"]
- [z.B. "Globaler State"]
- [z.B. "Hardcoded Dependencies"]

Refactore für Testbarkeit:
1. **Dependency Injection**: Abhängigkeiten von außen übergeben
2. **Interfaces**: Für alle externen Dependencies (DB, API, FileSystem)
3. **Pure Functions**: Wo möglich, Side Effects isolieren
4. **Seams**: Punkte einbauen wo Mock-Objekte eingesetzt werden können
5. **Small Functions**: Jede Funktion testbar mit max. 3-4 Assertions

Liefere:
- Refactored Production Code
- Passende Unit Tests (Jest/Vitest)
- Mock/Stub Beispiele für Dependencies

Natürlich kannst du den Ansatz an deine Bedürfnisse anpassen.

Prompt 9: Code dokumentieren

Deshalb lohnt es sich, dieses Thema genauer zu betrachten.

Dokumentiere diesen Code:

```
[Code hier einfügen]
```

Erstelle:
1. **JSDoc/TSDoc Kommentare** für alle exportierten Funktionen:
   - @description: Was macht die Funktion
   - @param: Parameter mit Typ und Beschreibung
   - @returns: Rückgabewert
   - @throws: Mögliche Fehler
   - @example: Mindestens ein Verwendungsbeispiel

2. **Inline-Kommentare** nur für komplexe Logik:
   - WARUM, nicht WAS (der Code zeigt WAS)
   - Business-Regeln erklären
   - Workarounds markieren mit TODO/HACK

3. **README.md** für das Modul:
   - Zweck und Kontext
   - Installation/Setup
   - API-Dokumentation
   - Beispiele

4. **ADR** (Architecture Decision Record) wenn relevante Design-Entscheidungen erkennbar

Grundsätzlich kannst du diesen Prompt an deine Bedürfnisse anpassen.

Zusammenfassend bietet dieser Abschnitt praktische Handlungsempfehlungen.

Prompt 10: Legacy Code modernisieren

Tatsächlich ist dieser Bereich besonders wichtig für Entwickler.

Modernisiere diesen Legacy Code:

```
[Legacy Code hier einfügen]
```

Sprache: [z.B. "JavaScript ES5 → TypeScript"]
Framework: [z.B. "jQuery → React" oder "Express → Hono"]

Modernisierung:
1. **Sprach-Features**: var → const/let, Callbacks → async/await, 
   Classes → Functions, etc.
2. **TypeScript**: Typen hinzufügen, Interfaces definieren
3. **Patterns**: MVC → Clean Architecture, Global State → Zustand
4. **Dependencies**: Veraltete Packages durch moderne Alternativen ersetzen
5. **Security Fixes**: Bekannte Schwachstellen in alten APIs
6. **Performance**: Ineffiziente Patterns durch moderne ersetzen

Migrationsstrategie:
- Schrittweiser Plan (nicht alles auf einmal)
- Strangler Fig Pattern verwenden
- Tests vor der Migration schreiben
- Rollback-Plan für jeden Schritt

Insbesondere die Struktur des Prompts ist dabei entscheidend für gute Ergebnisse.

Tatsächlich zeigt die Praxis, dass dieser Ansatz sehr effektiv ist.

Clean Code Checkliste

Natürlich gibt es dabei verschiedene Herangehensweisen.

Nutze diesen Prompt vor jedem Commit:

Schnellcheck für meinen Code (Ja/Nein mit kurzer Begründung):

```
[Code hier einfügen]
```

□ Verständliche Benennung? (Kann ein neuer Entwickler den Code lesen?)
□ Funktionen unter 20 Zeilen?
□ Max. 2 Verschachtelungsebenen?
□ Kein auskommentierter Code?
□ Error Handling vorhanden?
□ Keine Magic Numbers/Strings?
□ Keine Duplikate?
□ Typen korrekt (kein `any`)?
□ Edge Cases behandelt?
□ Testbar?

Folglich erhältst du mit diesem Ansatz deutlich bessere Resultate.

Ebenfalls empfehlenswert ist eine regelmäßige Überprüfung der Ergebnisse.

FAQ

Kann AI wirklich Clean Code bewerten?

Außerdem gibt es hilfreiche Tools, die dich dabei unterstützen.

Ja – und oft besser als Junior/Mid-Level Entwickler. AI kennt alle Patterns aus Millionen von Repos. Schwäche: Kontext der Business-Logik. AI weiß nicht warum Code so geschrieben wurde. Deshalb: AI als zweite Meinung, nicht als alleinige Autorität.

Sollte ich den gesamten Code refactoren?

Vor allem für den praktischen Einsatz sind diese Informationen wertvoll.

Nein! Boy Scout Rule: Lass den Code immer etwas sauberer zurück als du ihn vorgefunden hast. Refactore nur Code den du ohnehin anfasst. Vollständiges Refactoring nur mit Test-Coverage.

Welches AI-Tool ist am besten für Code Reviews?

Weiterhin ist es wichtig, die Grundlagen zu verstehen.

Claude für gründliche Reviews (beste Analyse). ChatGPT für schnelle Checks. GitHub Copilot Code Review für automatisierte PR-Reviews. Am besten: Kombination aus AI Review + menschlichem Review.

Clean Code vs. Performance?

Dementsprechend solltest du die folgenden Aspekte kennen.

In 99% der Fälle gibt es keinen Konflikt. Sauberer Code ist oft auch performanter (weniger unnötige Operationen). Optimiere erst clean, dann mit Profiler die echten Bottlenecks finden. Premature Optimization ist die Wurzel allen Übels.

Dabei ist der folgende Punkt besonders wichtig.

Verwandte Artikel:

Deshalb ist es wichtig, diesen Abschnitt aufmerksam zu lesen.

Zuletzt aktualisiert: März 2026