KI-Prompts für Clean Code: Spaghetti Code erkennen und mit Vibe Coding vermeiden

Wenn Du vor dem Spaghetti Code Problem stehst, ist KI ein mächtiges Werkzeug. In unserem Artikel Spaghetti Code vermeiden haben wir die Grundlagen erklärt. Hier zeigen wir Dir, wie Du mit gezielten KI-Prompts und kleinen Prüf-Scripts Dein Projekt auf Spaghetti Code untersuchst, nach Clean Code, SOLID und OOP refactorest und solide Unit Tests erstellst. Wir gehen dabei auch auf Vibe Coding ein, denn gerade dort entsteht schnell unübersichtlicher Code.

Vibe Coding und das Spaghetti Code Risiko

Vibe Coding bedeutet, mit KI-Assistenten wie GitHub Copilot, ChatGPT oder Claude schnell Code zu generieren. Das funktioniert beeindruckend gut für Prototypen und kleine Features. Das Problem: KI optimiert auf funktionierenden Code, nicht auf Wartbarkeit. Wenn Du jeden Vorschlag ungeprüft übernimmst, sammeln sich lange Funktionen, Duplikate und undurchsichtige Abhängigkeiten an.

Spaghetti Code entsteht also nicht automatisch durch Vibe Coding, aber die Gefahr steigt massiv, wenn Du nicht gezielt nach Clean Code, SOLID und testbaren Strukturen fragst. Die Lösung ist ein Workflow aus automatischer Analyse, Zielvorgaben in Prompts und manueller Review.

Projekt automatisch auf Spaghetti Code prüfen

Bevor Du KI fragst, solltest Du wissen, wo die größten Probleme liegen. Ein kleines Node.js Script durchsucht Dein Projekt nach typischen Warnsignalen.

// scripts/analyze-spaghetti.js
const fs = require('fs');
const path = require('path');

const TARGET_DIR = process.argv[2] || 'src';
const EXTENSIONS = ['.js', '.ts', '.jsx', '.tsx'];
const issues = [];

function scanDir(dir) {
  fs.readdirSync(dir, { withFileTypes: true }).forEach(entry => {
    const full = path.join(dir, entry.name);
    if (entry.isDirectory()) scanDir(full);
    else if (EXTENSIONS.includes(path.extname(full))) analyzeFile(full);
  });
}

function analyzeFile(file) {
  const lines = fs.readFileSync(file, 'utf8').split('\n');
  let functionStart = null;
  let braceDepth = 0;

  lines.forEach((line, index) => {
    const trimmed = line.trim();

    if (/^\s*(function\s+\w+|const\s+\w+\s*=|async\s+function|=>)/.test(line)) {
      functionStart = index;
    }

    braceDepth += (line.match(/\{/g) || []).length;
    braceDepth -= (line.match(/\}/g) || []).length;

    if (functionStart !== null && braceDepth === 0 && trimmed === '}') {
      const length = index - functionStart;
      if (length > 30) issues.push(`${file}:${functionStart + 1} - Funktion ca. ${length} Zeilen lang`);
      functionStart = null;
    }

    if (/^\s*if\s*\(.*\)\s*\{\s*$/.test(line)) {
      const next = lines.slice(index + 1, index + 4).join('\n');
      const nested = (next.match(/\n\s*if\s*\(/g) || []).length;
      if (nested > 0) issues.push(`${file}:${index + 1} - verschachtelte if-Blöcke`);
    }

    if (/\bvar\b/.test(line)) issues.push(`${file}:${index + 1} - var verwendet`);
    const todoMatch = line.match(/(TODO|FIXME|HACK)\b/);
    if (todoMatch) issues.push(`${file}:${index + 1} - ${todoMatch[1]} gefunden`);
  });
}

scanDir(TARGET_DIR);
if (issues.length === 0) console.log('Keine offensichtlichen Spaghetti-Code Hinweise gefunden.');
else issues.forEach(i => console.log(i));

Das Script ist bewusst einfach gehalten. Für Produktivsysteme ergänzt Du besser ESLint, SonarQube oder Codacy. Es zeigt Dir aber schnell Hotspots, die Du mit KI angehen kannst.

Von der Warnung zum Clean Code

Wenn das Script eine Stelle markiert, kopierst Du den betroffenen Code in einen KI-Assistenten und arbeitest ihn mit den Prompts unten durch. Der typische Workflow ist:

1. Hotspot finden
2. Verantwortlichkeit beschreiben
3. Prompt für sprechende Namen, kleine Funktionen und Tests nutzen
4. Ergebnis auf Clean Code, SOLID und OOP prüfen
5. Unit Tests ergänzen

Die folgenden Abschnitte liefern Dir für jeden wichtigen Bereich einen direkt kopierbaren Prompt. Wir unterscheiden dabei zwischen Prompts für einzelne Code-Blöcke und Prompts, die das gesamte Projekt betrachten.

Clean Code Prinzipien und Prompts

Im Artikel Clean Code Prinzipien haben wir die Regeln erklärt. Für die Arbeit mit KI ist es wichtig, diese Regeln als konkrete Zielvorgaben im Prompt zu formulieren. Hier findest Du einen Prompt pro wichtigem Clean Code Prinzip.

Aussagekräftige Namen

Gute Namen ersetzen viele Kommentare. Frag die KI gezielt danach, damit x, data oder tmp verschwinden.

Du bist ein erfahrener Softwareentwickler. Analysiere den folgenden Code auf unklare Variablen-, Funktions- und Klassennamen. Schlage für jeden Namen eine bessere Alternative vor und begründe, warum der neue Name die Lesbarkeit verbessert. Achte darauf, dass Namen Absichten und Verantwortlichkeiten beschreiben.

Code:
{{CODE}}

Kleine Funktionen

Lange Funktionen sind ein Hauptmerkmal von Spaghetti Code. Jede Funktion sollte eine Sache tun und idealerweise auf den Bildschirm passen.

Du bist ein erfahrener Softwareentwickler. Refactore den folgenden Code, sodass jede Funktion maximal eine Verantwortlichkeit hat und auf den Bildschirm passt. Extrahiere Hilfsfunktionen, verwende sprechende Namen und entferne tief verschachtelte Bedingungen durch Early Returns oder Guard Clauses. Gib den refactorten Code zurück.

Code:
{{CODE}}

DRY Prinzip

DRY bedeutet Don’t Repeat Yourself. KI erzeugt oft duplizierte Muster. Ein Prompt findet und beseitigt sie.

Du bist ein erfahrener Softwareentwickler. Identifiziere im folgenden Code doppelte Logik und fasse sie in wiederverwendbare Funktionen, Klassen oder Konstanten zusammen. Erkläre, wo DRY verletzt wurde und wie Deine Lösung die Wartbarkeit verbessert.

Code:
{{CODE}}

KISS Prinzip

KISS bedeutet Keep It Simple, Stupid. Der einfachste Weg ist meist der beste.

Du bist ein erfahrener Softwareentwickler. Vereinfache den folgenden Code nach dem KISS Prinzip. Entferne unnötige Abstraktionen, überflüssige Schleifen oder komplizierte Bedingungen. Der Code soll das gleiche Verhalten haben, aber möglichst einfach und selbsterklärend sein.

Code:
{{CODE}}

Gute Kommentare

Kommentare sollen das Warum erklären, nicht das Was. Schlechte Kommentare verschleiern schlechten Code.

Du bist ein erfahrener Softwareentwickler. Überprüfe den folgenden Code auf sinnvolle Kommentare. Entferne redundante oder veraltete Kommentare, ergänze fehlende Kommentare, die das Warum erklären, und verbessere den Code dort, wo er selbsterklärend sein sollte. Gib den überarbeiteten Code zurück.

Code:
{{CODE}}

Einheitliche Formatierung

Konsistente Formatierung reduziert kognitive Last. Der Prompt bereinigt Stil und Variablenart.

Du bist ein erfahrener Softwareentwickler. Formatiere den folgenden Code konsistent nach gängigen Konventionen. Achte auf Einrückung, Leerzeilen, Klammern und Zeilenumbrüche. Nutze kein var, bevorzuge const und let, und achte auf einheitliche Anführungszeichen.

Code:
{{CODE}}

Fehlerbehandlung

Stille Fehler, leere catch-Blöcke und unklare Meldungen sind Spaghetti Code im Fehlerfall.

Du bist ein erfahrener Softwareentwickler. Verbessere die Fehlerbehandlung im folgenden Code. Verwende aussagekräftige Fehlermeldungen, vermeide leere catch-Blöcke, validiere Eingaben frühzeitig und nutze Guard Clauses. Gib den verbesserten Code zurück.

Code:
{{CODE}}

Unit Tests mit KI erstellen

Unit Tests prüfen isoliert die kleinste Einheit eines Programms, meist eine Funktion oder Methode. Sie sichern nicht nur das Verhalten ab, sondern zwingen Dich auch dazu, Code testbar zu strukturieren. Testbarer Code ist in der Regel besser strukturierter Code.

Beim Schreiben von Tests achte auf klare Arrange-Act-Assert Struktur, sinnvolle Testnamen und die Abdeckung von Normalfällen, Grenzfällen und Fehlern. Externe Abhängigkeiten wie Datenbanken oder APIs ersetzt Du durch Mocks oder Stubs.

Du bist ein erfahrener Softwareentwickler. Schreibe für den folgenden Code Unit Tests. Achte auf klare Arrange-Act-Assert Struktur, sinnvolle Testfälle für Normalfälle, Grenzfälle und Fehler. Mock externe Abhängigkeiten und verwende aussagekräftige Testnamen. Gib den Testcode zurück.

Code:
{{CODE}}

Wann nutzt Du welchen Prompt?

Nicht jeder Prompt passt zu jeder Situation. Hier ist eine einfache Orientierung, wann Du welche Gruppe einsetzt.

• Code-Detail-Prompts: Nutze sie für einzelne Funktionen oder Dateien, die Dir auffallen. Sie eignen sich besonders, wenn Du gerade an einem Feature arbeitest und schnell Lesbarkeit, Namen oder Fehlerbehandlung verbessern willst.
• Unit-Test-Prompts: Setze sie ein, sobald Du eine Funktion refactort hast. Tests sichern das Verhalten ab und zwingen Dich zu testbarem Design.
• Sicherheitsaudits: Führe sie vor Releases, nach größeren Änderungen oder bei neuen Features durch, die Benutzereingaben verarbeiten.
• Architektur-Audits: Verwende sie, wenn sich das Projekt schwer erweitern lässt, technische Schulden wachsen oder Du eine Refactoring-Session planst.
• Iteratives Vorgehen bei großen Projekten: Teile große Codebases in Pakete, Schichten oder Features auf. Lass die KI nacheinander Bereiche analysieren und fasse die Ergebnisse am Ende zusammen.

Sicherheitsaudits mit KI

Sicherheitslücken in KI-generiertem Code entdeckst Du am zuverlässigsten, wenn Du das Projekt Schritt für Schritt durchleuchtest. Die folgenden Prompts decken verschiedene Perspektiven ab.

1. Gesamte Sicherheitsanalyse

Du bist ein erfahrener Security-Auditor.

Analysiere das gesamte Projekt auf Sicherheitslücken.

Suche insbesondere nach:

- SQL Injection
- Command Injection
- Remote Code Execution (RCE)
- Local File Inclusion (LFI)
- Remote File Inclusion (RFI)
- Path Traversal
- Cross Site Scripting (XSS)
- Cross Site Request Forgery (CSRF)
- Server Side Request Forgery (SSRF)
- Authentication Bypass
- Authorization-Problemen
- Session Hijacking
- Unsicherer Passwortspeicherung
- Information Disclosure
- Hardcoded Secrets
- Unsicherer Kryptographie
- Race Conditions

Für jede gefundene Schwachstelle liefere:

- Dateiname
- Zeilennummer
- Beschreibung
- Angriffsbeispiel
- Risikostufe (Low/Medium/High/Critical)
- Konkreten Verbesserungsvorschlag

---

2. Suche nach versteckten Problemen

Suche ausschließlich nach subtilen Sicherheitsproblemen.

Ignoriere Style und Codequalität.

Konzentriere dich auf Logikfehler, die ein Angreifer ausnutzen könnte.

Suche insbesondere nach:

- fehlenden Berechtigungsprüfungen
- Trust Boundary Problemen
- User Input ohne Validierung
- gefährlichen Default-Werten
- TOCTOU-Problemen
- Privilege Escalation
- Umgehung von Rechteprüfungen

---

3. Penetrationstest aus Sicht eines Angreifers

Versetze dich in die Rolle eines Penetration Testers.

Versuche ausschließlich Angriffe gegen die Anwendung zu finden.

Erstelle für jede Schwachstelle:

- Angriffsszenario
- Beispielrequest
- Voraussetzungen
- Auswirkung
- CVSS-Einschätzung

---

4. Suche nach allen Stellen mit Benutzereingaben

Liste alle Stellen auf, an denen Benutzereingaben verarbeitet werden.

Zeige:

- Quelle der Eingabe
- Verarbeitung
- Validierung
- Escaping
- Datenbankzugriffe
- Dateizugriffe
- Shell-Aufrufe
- Netzwerkzugriffe

Bewerte jede Stelle hinsichtlich des Risikos.

---

5. Suche nach gefährlichen Funktionen

Suche im gesamten Projekt nach potentiell gefährlichen Funktionen.

Beispiele:

eval
exec
system
shell_exec
popen
proc_open
passthru
include
require
require_once
fopen
unlink
rename
move_uploaded_file

Prüfe jede Verwendung auf Missbrauchsmöglichkeiten.

(Diese Liste kannst du natürlich an die verwendete Programmiersprache anpassen.)

---

6. OWASP Top 10

Prüfe das Projekt vollständig anhand der aktuellen OWASP Top 10.

Erstelle eine Tabelle:

OWASP-Kategorie
betroffene Dateien
Beschreibung
Risiko
Empfohlene Maßnahmen

---

7. API-Analyse

Falls die Seite APIs besitzt:

Analysiere alle API-Endpunkte.

Prüfe auf:

- fehlende Authentifizierung
- fehlende Autorisierung
- IDOR
- Rate Limiting
- Mass Assignment
- Injection
- Input Validation

---

8. “Denk wie ein Hacker”

Das ist oft mein Lieblingsprompt:

Denke wie ein erfahrener Angreifer.

Welche drei Schwachstellen würdest du zuerst ausnutzen?

Beschreibe Schritt für Schritt:

- warum
- wie
- Erfolgsaussichten
- mögliche Auswirkungen

---

9. False Positives reduzieren

Sehr hilfreich:

Melde nur Schwachstellen, die mit hoher Wahrscheinlichkeit tatsächlich ausnutzbar sind.

Wenn du dir nicht sicher bist, kennzeichne sie ausdrücklich als Vermutung.

Keine theoretischen oder spekulativen Findings.

---

10. Zweite Prüfung

Nachdem Claude etwas gefunden hat:

Überprüfe deine eigene Analyse kritisch.

Suche nach:

- False Positives
- übersehenen Sicherheitsproblemen
- Logikfehlern
- weiteren Angriffsmöglichkeiten

Erstelle anschließend den endgültigen Security Report.

Ein zusätzlicher Tipp

Wenn das Projekt größer ist (z. B. mehrere tausend Dateien), beginne mit einer Architekturübersicht, statt sofort nach Schwachstellen zu suchen:

Analysiere zunächst die Architektur des Projekts.

Identifiziere:

- Programmiersprache(n)
- Framework(s)
- Authentifizierung
- Datenbankzugriffe
- Upload-Funktionen
- Admin-Bereiche
- API-Endpunkte
- Dateioperationen
- Externe Abhängigkeiten

Erstelle danach einen Plan für einen vollständigen Security Audit und führe ihn Schritt für Schritt durch.

Das gibt Claude Code einen besseren Gesamtüberblick und führt oft zu gründlicheren Ergebnissen als ein einmaliger “Prüfe alles”-Prompt. Wichtig ist aber: Ein LLM-Audit ersetzt keine spezialisierten Werkzeuge (z. B. SAST-, Dependency- oder DAST-Scanner), sondern ergänzt sie. Die besten Ergebnisse erhältst du, wenn du beides kombinierst.

Ebenso wichtig ist eine projektweite Prüfung der Architektur. Einzelne Prompts wie “Prüfe auf SOLID” liefern meist nur allgemeine Hinweise. Besser arbeitest Du mit gezielten Audits.

Architektur, Clean Code und SOLID Audits

Die folgenden Prompts helfen Dir, das gesamte Projekt auf Wartbarkeit, doppelte Logik und SOLID/OOP zu prüfen. Sie ergänzen die Code-Detail-Prompts aus dem vorherigen Abschnitt und betrachten das Projekt als Ganzes.

1. Gesamter Architektur-Review

Du bist ein erfahrener Software-Architekt.

Analysiere das gesamte Projekt hinsichtlich:

- Clean Code
- OOP
- SOLID
- DRY (Don't Repeat Yourself)
- KISS
- YAGNI
- Separation of Concerns
- High Cohesion
- Low Coupling

Erstelle zunächst eine Übersicht der Architektur.

Danach identifiziere alle Stellen, die gegen diese Prinzipien verstoßen.

Für jedes Problem liefere:

- Datei
- Klasse
- Methode
- Beschreibung
- Begründung
- Verbesserungsvorschlag
- Priorität (Low/Medium/High)

---

2. Doppelte Logik finden (mein Favorit)

Das ist genau das, was du beschrieben hast.

Analysiere das gesamte Projekt auf doppelte Logik.

Suche insbesondere nach:

- identischen Funktionen
- nahezu identischen Methoden
- kopiertem Code
- gleicher Businesslogik
- mehrfach implementierten Berechnungen
- mehrfacher Validierung
- mehrfacher Datenbanklogik
- mehrfachen API-Aufrufen

Zeige jeweils:

- beide Dateien
- beide Methoden
- Ähnlichkeitsgrad in %
- welche Methode die gemeinsame Basis sein sollte
- wie die Duplikate zusammengeführt werden können

Ignoriere Unterschiede in Variablennamen.

---

3. SOLID-Prinzipien einzeln prüfen

Prüfe jede Klasse einzeln auf die SOLID-Prinzipien.

Für jede Klasse beantworte:

Single Responsibility:
Hat die Klasse mehr als eine Verantwortung?

Open/Closed:
Muss Code geändert werden statt erweitert zu werden?

Liskov:
Sind Vererbungen korrekt?

Interface Segregation:
Sind Interfaces zu groß?

Dependency Inversion:
Werden konkrete Klassen statt Abstraktionen verwendet?

Gib konkrete Verbesserungsvorschläge.

---

4. Klassen mit zu vielen Aufgaben

Suche nach God Classes.

Eine God Class erkennst du unter anderem an:

- über 500 Zeilen
- sehr viele Methoden
- kennt viele andere Klassen
- enthält Businesslogik, UI und Datenbankzugriffe gleichzeitig
- besitzt viele Membervariablen

Schlage eine sinnvolle Aufteilung vor.

---

5. Schlechte Methoden

Suche nach Methoden, die gegen Clean Code verstoßen.

Beispiele:

- über 30 Zeilen
- mehrere Verantwortlichkeiten
- tiefe Verschachtelungen
- viele Parameter
- viele boolesche Flags
- doppelte Logik

Schlage Refactorings vor.

---

6. Verantwortlichkeiten prüfen

Analysiere jede Klasse.

Beschreibe in einem Satz ihre eigentliche Verantwortung.

Wenn eine Klasse mehrere Verantwortlichkeiten besitzt,
zeige genau welche.

Schlage anschließend eine sinnvolle Aufteilung vor.

---

7. Abhängigkeiten

Erstelle ein Abhängigkeitsdiagramm des Projekts.

Markiere:

- zyklische Abhängigkeiten
- unnötige Abhängigkeiten
- enge Kopplungen
- Verletzungen der Dependency Inversion

Schlage Verbesserungen vor.

---

8. Vererbungen prüfen

Analysiere alle Vererbungen.

Prüfe:

- unnötige Vererbung
- sollte Komposition verwendet werden?
- Liskov-Verletzungen
- doppelte Implementierungen

Schlage bessere Alternativen vor.

---

9. Refactoring-Plan

Das ist oft der nützlichste Prompt.

Erstelle einen vollständigen Refactoring-Plan.

Ordne alle Probleme nach Priorität.

Für jedes Problem beschreibe:

- warum es existiert
- welche SOLID-Regel verletzt wird
- wie die Klasse nach dem Refactoring aussehen sollte
- welche Dateien betroffen sind
- Aufwand (klein/mittel/groß)

Ziel:

- weniger Code
- keine doppelte Logik
- bessere Wartbarkeit
- bessere Testbarkeit

---

10. Strenger Architektur-Review

Verhalte dich wie ein Senior Software Architect bei einem Code Review.

Sei kritisch.

Akzeptiere keine doppelte Logik.

Akzeptiere keine Klassen mit mehreren Verantwortlichkeiten.

Akzeptiere keine Copy-&-Paste-Lösungen.

Zeige alle Stellen, die du vor einem Merge in den Main-Branch zwingend ändern würdest.

Priorisiere die wichtigsten Probleme zuerst.

Noch ein Tipp

Wenn dein Projekt bereits recht groß ist (z. B. über 20.000 Zeilen Code), kannst du Claude Code zusätzlich diesen Arbeitsauftrag geben:

Arbeite iterativ.

Gehe Datei für Datei durch.

Erstelle nach jeder Datei eine Liste der gefundenen Probleme.

Am Ende fasse alle Ergebnisse zusammen.

Wenn du ähnliche Methoden in verschiedenen Dateien findest, vergleiche sie miteinander und prüfe, ob sie zu einer gemeinsamen Funktion oder Basisklasse zusammengeführt werden können.

Suche ausdrücklich nach Verletzungen von DRY und mehrfach implementierter Businesslogik.

Gerade dieser letzte Satz ist wichtig: Standardmäßig bewertet Claude Dateien oft isoliert. Mit dem ausdrücklichen Auftrag, dateiübergreifend nach identischer oder ähnlicher Logik zu suchen, erkennt es wesentlich zuverlässiger doppelte Implementierungen und Möglichkeiten zur Zentralisierung.

Beispiel-Workflow für eine Refactoring-Session

Stell Dir vor, Du übernimmst ein Projekt mit viel KI-generiertem Code. So könnte ein Arbeitstag aussehen:

1. Führe node scripts/analyze-spaghetti.js src aus und sammle die Hotspots.
2. Kopiere die auffälligsten Funktionen in die Code-Detail-Prompts für Namen, Formatierung und Fehlerbehandlung.
3. Generiere Unit Tests für die bearbeiteten Stellen.
4. Wenn Du Duplikate oder große Klassen über Dateigrenzen hinweg erkennst, starte die Architektur-Audits.
5. Erstelle einen Refactoring-Plan und arbeite ihn nach Priorität ab.
6. Vor dem Merge oder Release führst Du die Sicherheitsaudits durch.
7. Reviewe alle KI-Vorschläge manuell. KI hilft Dir, Probleme zu finden, aber Du entscheidest über die Lösung.

Fazit

KI und Vibe Coding sind hervorragende Werkzeuge, wenn Du weißt, wonach Du fragen musst. Die besten Ergebnisse bekommst Du, wenn Du Spaghetti Code zuerst mit einem einfachen Script identifizierst und dann mit gezielten Prompts nach Clean Code, SOLID, OOP und Unit Tests aufräumst. So bleibt KI ein Beschleuniger statt ein Risiko für Deine Codequalität.

Buchempfehlungen

Diese Bücher begleiten Dich beim Thema Clean Code und professionelle Softwareentwicklung.

Weitere Artikel

• Spaghetti Code vermeiden
• Clean Code Prinzipien
• Clean Code und SOLID Prinzipien
• SOLID Prinzipien Grundlagen
• Unit Tests Grundlagen
• Fehlerbehandlung und Debugging