Answer-First: Was Plan Mode bedeutet
Plan Mode ist ein eigener Berechtigungsmodus in Claude Code: Claude untersucht das Projekt und schlägt einen Plan vor, ohne deinen Quellcode zu ändern. Vor der Umsetzung prüfst du den Plan und bestätigst den Wechsel aus dem Planungsmodus. Die Vollständigkeit betroffener Dateien, Abhängigkeiten und Tests bleibt Teil deiner Prüfung.
Der Unterschied zeigt sich bei Multi-File-Änderungen: Ohne Plan Mode riskierst du inkonsistente Änderungen über mehrere Dateien, fehlende Tests oder Breaking Changes. Mit Plan Mode siehst du vorher, was Claude vorhat — und kannst korrigieren, bevor der erste Code geschrieben wird.
Dieser Artikel erklärt, wie Plan Mode funktioniert, wann du ihn brauchst und wie du ihn optimal nutzt.
Warum Plan Mode existiert — das Problem
KI-Coding-Tools ohne Planungs-Phase neigen zu drei typischen Fehlern:
Problem 1: Scope-Creep Du fragst nach einem einfachen Bug-Fix. Die KI "verbessert" dabei gleich noch drei unrelated Funktionen, ändert Naming-Conventions und refactored halbe Module — weil ihr Kontext lang ist und sie "hilfsbereit" sein will. Du wolltest 5 Zeilen ändern, bekommst 500.
Problem 2: Fehlende Abhängigkeits-Analyse Die KI ändert eine Funktion in Datei A, übersieht aber dass Datei B und C diese Funktion ebenfalls nutzen — und bricht damit zwei andere Features. Ohne Plan kein Überblick über Side-Effects.
Problem 3: Kein Definition-of-Done Die KI schreibt Code, aber keine Tests. Oder Tests, aber kein Error-Handling. Oder alles, aber ohne Logging. Was "fertig" bedeutet, wurde nie definiert — also entscheidet die KI selbst, oft unvollständig.
Plan Mode löst das: Claude zeigt dir vorher, was es ändern wird, welche Dateien betroffen sind, welche Tests nötig sind und wie Erfolg gemessen wird. Du sagst "Go" oder "Nein, anders" — bevor Code fliegt.
Wie Plan Mode funktioniert
Der typische Plan-Mode-Workflow läuft in drei Phasen:
Phase 1: Analyse und Planungs-Vorschlag
Du gibst Claude eine Aufgabe. Zum Beispiel:
"Füge Rate-Limiting zum Login-Endpoint hinzu. 5 Versuche pro Minute, dann 15 Minuten Sperre."
Ohne Plan Mode würde Claude jetzt sofort anfangen, Code zu editieren.
Mit Plan Mode antwortet Claude stattdessen mit einem strukturierten Plan:
PLAN:
Betroffene Dateien:
- backend/api/auth.py (Login-Endpoint erweitern)
- backend/middleware/rate_limit.py (neues Rate-Limiter-Middleware)
- backend/config/settings.py (Rate-Limit-Config hinzufügen)
- tests/test_auth.py (Rate-Limit-Tests hinzufügen)
Abhängigkeiten:
- Redis (für verteiltes Rate-Limiting) — bereits vorhanden? Ja
- python-redis Client — bereits installiert? Nein → requirements.txt erweitern
Implementierungsschritte:
1. Rate-Limiter-Middleware schreiben (Decorator-Pattern)
2. Redis-Client konfigurieren (Connection-Pool)
3. Middleware in Login-Route integrieren
4. Config-Werte in settings.py definieren
5. Tests schreiben: happy path + rate-limit-exceeded + reset nach Ablauf
6. Verifizierung: curl-Test gegen lokalen Server
Definition of Done:
- Login-Endpoint gibt 429 nach 5 Versuchen zurück
- Sperre läuft nach 15 Minuten ab
- Tests grün
- Kein Breaking Change für bestehende Auth-Flows
Soll ich so vorgehen? [Ja/Nein/Änderungen]
Du siehst jetzt: Claude hat verstanden was du willst, welche Dateien betroffen sind, welche Dependencies fehlen und wie der Code getestet wird.
Phase 2: Freigabe oder Korrektur
Du prüfst den Plan und antwortest:
- "Ja, mach weiter" → Claude implementiert
- "Nein, ändere X" → Claude überarbeitet den Plan
- "Skip Tests, ich schreibe sie später" → Claude passt DoD an
Das ist der Moment, wo du korrigierst. Nicht nachdem 200 Zeilen Code geschrieben wurden.
Phase 3: Implementierung mit Validierung
Nach deiner Freigabe implementiert Claude den Plan Schritt für Schritt. Wichtig: Es hält sich an die definierten Schritte und meldet nach jedem Schritt Fortschritt.
Am Ende zeigt es die Verifikation:
Fertig. Verifikation:
✅ Rate-Limiter-Middleware implementiert (backend/middleware/rate_limit.py)
✅ Redis-Client konfiguriert (Connection-Pool in settings.py)
✅ Middleware in Login-Route integriert
✅ Tests implementiert (tests/test_auth.py)
✅ Tests grün: 5/5 passed
✅ curl-Test: Login funktioniert, 6. Versuch → 429 Too Many Requests
Definition of Done erfüllt. Bereit für Code-Review.
Wann du Plan Mode brauchst
Nutze Plan Mode bei:
- Multi-File-Änderungen (mehr als 3 Dateien betroffen)
- Breaking Changes (API-Änderungen, DB-Schema-Migrationen)
- Neuen Features (nicht nur Bug-Fixes)
- Refactorings (besonders wenn Tests angepasst werden müssen)
- Unklaren Anforderungen (Claude hilft dir, sie zu klären)
Plan Mode ist optional bei:
- Single-File-Bug-Fixes (offensichtliche Änderungen)
- Reine Code-Formatierung
- Triviale Typo-Fixes
- Einmalige Snippets ohne Integration
Faustregel: Wenn deine Anfrage mehr als einen Satz braucht, um sie zu erklären — nutze Plan Mode.
Wie du Plan Mode aktivierst
Starte Claude Code im Projektverzeichnis direkt im Planungsmodus:
claude --permission-mode plan
In einer laufenden CLI-Sitzung wechselst du mit Shift+Tab, bis die Statusleiste Plan Mode anzeigt. Unter Windows ist bei bestimmten Terminal-Konfigurationen Alt+M eine Alternative. Kontrolliere die Anzeige, statt eine feste Zahl von Tastendrücken vorauszusetzen.
Quellen: Plan before editing und Tastenkürzel.
Formuliere anschließend deine Planungsaufgabe, zum Beispiel:
„Plane Rate-Limiting für den Login-Endpoint. Nenne betroffene Dateien, Abhängigkeiten, Umsetzungsschritte und geeignete Tests.“
Ein solcher Prompt beschreibt das gewünschte Ergebnis. Er schaltet den Berechtigungsmodus nicht ein. Das gilt auch für Planungsanweisungen in CLAUDE.md: Sie beeinflussen das Verhalten, ersetzen aber keine durch Claude Code durchgesetzten Berechtigungen. Siehe Berechtigungen.
Noch expliziter (via CLAUDE.md):
Lege in deiner CLAUDE.md-Datei fest:
# Workflow-Regel: Plan-First
Bei Aufgaben die mehr als eine Datei betreffen:
1. Erstelle strukturierten Plan mit:
- Betroffene Dateien
- Abhängigkeiten
- Implementierungsschritte
- Definition of Done
2. Warte auf Freigabe
3. Implementiere nach Plan
4. Zeige Verifikation
Erst nach "Ja" oder "Go" mit Implementierung beginnen.
Claude lädt passende CLAUDE.md-Anweisungen als Projektkontext. Kontrolliere die Umsetzung; die Anweisungen erzwingen keinen Berechtigungsmodus.
Plan Mode vs. "Einfach Loscoden"
Ein konkreter Vergleich:
Ohne Plan Mode (chaotisch):
User: "Füge Webhooks für neue User hinzu."
Claude: [editiert sofort 8 Dateien]
- Webhook-Endpoint erstellt
- User-Signup-Flow erweitert
- Webhook-Config hinzugefügt
- Error-Handling … vergessen
- Tests … fehlen
- Logging … teilweise
- Retry-Logic … nicht implementiert
User: "Moment, ich wollte Retry-Logic und Tests!"
Claude: "Oh, ich füge das hinzu." [editiert nochmal 5 Dateien]
User: "Jetzt sind alte Tests kaputt."
Claude: "Ich fixe das." [editiert nochmal 3 Dateien]
Ergebnis: 3 Iterationen, 16 Datei-Edits, viel Hin-und-Her.
Mit Plan Mode (strukturiert):
User: "Erstelle einen Plan für Webhooks bei neuen Usern."
Claude:
PLAN:
Betroffene Dateien:
- backend/webhooks/handler.py (neuer Webhook-Sender)
- backend/api/users.py (User-Signup-Integration)
- backend/config/webhooks.py (Webhook-URLs konfigurieren)
- tests/test_webhooks.py (Tests: Success + Retry + Failure)
Implementierungsschritte:
1. Webhook-Sender mit Retry-Logic (exponentielles Backoff, max 3 Retries)
2. Integration in User-Signup (nach DB-Commit, async)
3. Error-Handling (Webhook-Fehler dürfen Signup nicht blocken)
4. Logging (Success/Failure/Retry)
5. Tests: happy path + Retry-Szenario + Failure-Handling
DoD:
- Webhook wird bei User-Signup gesendet
- Fehler blocken Signup nicht
- 3 Retries bei Timeout
- Tests grün
Soll ich so vorgehen?
User: "Ja, aber Error-Logging in Sentry statt stdout."
Claude: [Plan angepasst] "Verstanden, ich integriere Sentry. Bereit?"
User: "Go."
Claude: [implementiert nach Plan, 1 Iteration, 8 Datei-Edits, alles komplett]
Ergebnis: 1 Iteration, klare DoD, nichts vergessen.
Typische Plan-Mode-Fehler
Fehler 1: Plan zu vage
Schlechter Plan:
1. Webhook hinzufügen
2. User-Code anpassen
3. Tests schreiben
Das ist kein Plan, sondern eine Todo-Liste ohne Details. Ein guter Plan nennt konkrete Dateien, Funktionen, Edge-Cases.
Fehler 2: Plan akzeptieren ohne zu prüfen
Nur weil Claude einen Plan vorschlägt, muss er nicht optimal sein. Prüfe:
- Sind alle betroffenen Dateien genannt?
- Fehlt ein Edge-Case?
- Ist die DoD vollständig?
Korrigiere bevor du "Go" sagst.
Fehler 3: Plan ignorieren während Implementierung
Wenn Claude während der Implementierung plötzlich Dateien editiert, die nicht im Plan standen — stoppe und frage nach. Oft deutet das auf Scope-Creep hin.
Plan Mode + CLAUDE.md = Maximum Kontrolle
Die stärkste Kombination: Plan Mode als Workflow + CLAUDE.md mit projektspezifischen Regeln.
Beispiel CLAUDE.md:
# Projekt: E-Commerce API
## Stack
- Backend: FastAPI, PostgreSQL, Redis
- Tests: pytest
- Deployment: Docker
## Coding-Rules
- Jeder Endpoint: Pydantic-Schema + Error-Handling + Rate-Limiting
- Jeder DB-Zugriff: Auth + Ownership-Check
- Kein Code ohne Tests
## Plan-First Workflow
Bei Features/Refactorings:
1. Plan mit betroffenen Dateien + DoD
2. Freigabe abwarten
3. Implementierung
4. Verifikation (Tests + curl)
## Definition of Done
- Tests grün
- Kein print() oder console.log
- Error-Handling vollständig
- Logging implementiert
Diese CLAUDE.md beschreibt euren gewünschten Ablauf. Aktiviere Plan Mode zusätzlich über die CLI oder Modusauswahl, wenn du dessen Berechtigungsgrenzen nutzen willst.
Tools die Plan Mode unterstützen
Plan Mode ist kein Claude-Code-exklusives Feature, aber Claude ist dafür optimiert:
Claude Code (CLI/Desktop/Web): Volle Plan-Mode-Unterstützung, CLAUDE.md-Integration, explizite Freigabe-Workflows
Cursor: Kann Pläne vorschlagen, aber weniger strukturiert (oft vermischt mit sofortiger Implementierung)
GitHub Copilot: Kein Plan Mode — arbeitet rein suggestion-basiert ohne Freigabe-Schritt
GPT-5 Codex: Plant wenn explizit gefordert, aber weniger konsistent als Claude
Plan Mode funktioniert am besten mit Tools, die für Multi-Step-Reasoning optimiert sind — Claude ist dafür aktuell führend.
Weitere Ressourcen
- Claude Code installieren — Windows, Mac, Linux
- Claude Code auf Deutsch nutzen — kompletter Guide
- CLAUDE.md-Templates in der Community
- MCP-Server bauen in 60 Minuten
Häufige Fragen
Ist Plan Mode langsamer als direktes Coden? Initial ja (1–2 Minuten für Planung). Aber über die gesamte Aufgabe gerechnet ist Plan Mode schneller — weil du weniger Iterationen brauchst und nichts nachträglich fixen musst.
Kann ich Plan Mode überspringen bei simplen Tasks? Ja. Bei Single-File-Bug-Fixes oder trivialen Änderungen ist direktes Coden schneller. Plan Mode lohnt sich ab ~3 betroffenen Dateien.
Funktioniert Plan Mode mit allen Claude-Modellen? Ja, aber die Planungs-Qualität variiert. Opus (höchste Intelligenz) plant am detailliertesten. Sonnet (schneller) plant solide. Haiku (günstig) plant weniger tiefgehend.
Wie detailliert sollte der Plan sein? Faustformel: So detailliert, dass ein anderer Entwickler den Plan lesen und selbst implementieren könnte — ohne Rückfragen.
Was wenn Claude vom Plan abweicht während Implementierung? Stoppe und frage nach. Entweder hat Claude einen guten Grund (neu entdeckte Abhängigkeit) oder es ist Scope-Creep. In beiden Fällen: Plan aktualisieren und neu freigeben lassen.
Kann ich Plan Mode erzwingen in CLAUDE.md?
Du kannst dort einen Planungsablauf verlangen. Den Berechtigungsmodus erzwingt diese Datei jedoch nicht: Starte mit claude --permission-mode plan oder wähle Plan Mode in der Sitzung. Kontrolliere anschließend die Statusanzeige.
Veröffentlicht am 12. August 2026. Am 10. September 2026 wurden die Quellenadresse, Aktivierung des Plan Mode und Abgrenzung zu CLAUDE.md anhand der offiziellen Dokumentation korrigiert. Die übrigen Beispiele und Tool-Vergleiche wurden bei dieser Korrektur nicht vollständig neu geprüft.
