Claude Code Masterkurs – KI-gestuetztes Programmieren lernen mit Anthropics Coding-Agent

Real-World Workflow Patterns

Level 3 | 40 Minuten

Bewährte Workflows für echte Projekte: Spec-Driven, TDD, Vibe Coding und mehr

Lernziele

Die 3 Haupt-Workflows

Nach Monaten intensiver Nutzung durch die Community haben sich drei grundlegende Workflow-Patterns herauskristallisiert die den Großteil der täglichen Arbeit mit Claude Code abdecken. Jedes Pattern hat spezifische Stärken und eignet sich für unterschiedliche Szenarien. Diese drei Patterns sind nicht exklusiv — erfahrene Nutzer wechseln je nach Aufgabe zwischen ihnen. Das Verständnis aller drei und die Fähigkeit zum Wechsel ist das was einen Claude Code Power-User ausmacht. Pattern 1 — Spec-Driven Development: Du schreibst eine detaillierte Spezifikation bevor Claude eine Zeile Code anfasst. Ideal für klar definierte Features, Team-Projekte und Code der langfristig gewartet werden muss. Maximale Kontrolle, minimale Überraschungen. Pattern 2 — Explore-Plan-Code: Du lässt Claude erst die Codebase erkunden, dann einen Plan erstellen, dann implementieren. Ideal wenn du in unbekanntem Code arbeitest, komplexe Refactorings durchführst oder die beste Lösung erst finden musst. Gute Balance aus Exploration und Struktur. Pattern 3 — Vibe Coding: Du beschreibst was du willst und lässt Claude einfach machen — mit minimalem Vorplanen. Ideal für Prototypen, kleine Projekte und persönliche Tools. Maximum Speed, minimaler Overhead. Die Wahl des richtigen Patterns hängt von mehreren Faktoren ab: Wie kritisch ist der Code (Production vs. Experiment)? Wie groß ist das Projekt (Enterprise vs. Solo)? Wie gut kennst du den Code (eigener vs. fremder)? Wie zeitkritisch ist die Aufgabe (Sprint vs. Exploration)? In den folgenden Abschnitten gehen wir jedes Pattern im Detail durch — mit konkreten Beispielen, typischen Abläufen und Tipps wann du welches Pattern einsetzen solltest.

DIE 3 HAUPT-WORKFLOWS
━━━━━━━━━━━━━━━━━━━━

1. SPEC-DRIVEN DEVELOPMENT
   "Erst spezifizieren, dann implementieren lassen"
   → Für Feature-Arbeit in Teams
   → Höchste Qualität, mehr Aufwand upfront

2. EXPLORE → PLAN → CODE (Anthropic Best Practice)
   "Erst verstehen, dann planen, dann umsetzen"
   → Für unbekannte Codebases und komplexe Bugs
   → Beste Balance aus Speed und Qualität

3. VIBE CODING
   "Sag was du willst, lass Claude machen"
   → Für Prototypen und MVPs
   → Schnellstes Ergebnis, weniger Kontrolle

Pattern 1: Spec-Driven Development

Spec-Driven Development ist der strukturierteste der drei Workflow-Patterns. Du schreibst eine detaillierte Spezifikation BEVOR Claude eine einzige Zeile Code anfasst. Das Ergebnis: Maximale Kontrolle, minimale Überraschungen, und Code der exakt den Anforderungen entspricht. Der Ablauf: Schritt 1 — Du erstellst eine Spezifikation als Markdown-Datei oder direkt im Prompt. Sie enthält: Was soll implementiert werden, welche Architektur, welche Dateien werden betroffen, welche Tests braucht es, welche Edge Cases müssen behandelt werden, und was explizit NICHT gemacht werden soll. Schritt 2 — Du gibst die Spezifikation an Claude: 'Implementiere exakt nach dieser Spezifikation. Weiche nicht ab. Wenn du Widersprüche oder Lücken findest, frag nach bevor du implementierst.' Schritt 3 — Claude implementiert nach Spec. Bei Abweichungen oder fehlenden Details fragt es nach. Das Ergebnis ist vorhersagbar und reviewbar. Wann Spec-Driven? Bei Features die langfristig gewartet werden müssen, bei Team-Projekten wo mehrere Entwickler am gleichen Code arbeiten, bei regulierten Umgebungen wo Nachvollziehbarkeit wichtig ist, und bei komplexen Features mit vielen Abhängigkeiten. Der Aufwand für die Spezifikation lohnt sich: 20 Minuten Spezifikation sparen dir 2 Stunden Nacharbeit und 3 Review-Runden. Die Spec dient gleichzeitig als Dokumentation und Testgrundlage. Profi-Variante: Nutze Claude im Plan-Mode um die Spezifikation zu ERSTELLEN. 'Analysiere das bestehende Auth-Modul und erstelle eine Spec für die Erweiterung um OAuth2 Support.' Claude liefert die Spec, du prüfst und verfeinerst sie, dann implementiert Claude nach der genehmigten Spec.

# Beispiel: Feature-Spezifikation
# Datei: docs/specs/user-auth.md

## Feature: User Authentication

### Anforderungen
- [ ] Login mit Email + Password
- [ ] Registration mit Email-Verifikation
- [ ] Password Reset Flow
- [ ] JWT Tokens (Access + Refresh)
- [ ] Rate Limiting (max 5 Login-Versuche/Minute)

### Technische Entscheidungen
- Auth: JWT mit HttpOnly Cookies (NICHT localStorage)
- Hashing: bcrypt mit salt rounds = 12
- Token-Lifetime: Access 15min, Refresh 7 Tage
- Email: Resend API für Verifikation

### API Endpunkte
POST /api/auth/register  → 201 Created
POST /api/auth/login     → 200 OK + Set-Cookie
POST /api/auth/logout    → 200 OK + Clear-Cookie
POST /api/auth/refresh   → 200 OK + New Tokens
POST /api/auth/forgot    → 200 OK (immer, auch bei unbekannter Email)
POST /api/auth/reset     → 200 OK

### Nicht im Scope
- Social Login (kommt in Phase 2)
- 2FA (kommt in Phase 3)
- Session-Management (nutzen JWT stattdessen)
# Spec-Driven Workflow:

# Schritt 1: Spec schreiben (DU, nicht Claude!)
# → docs/specs/user-auth.md erstellen

# Schritt 2: Claude die Spec reviewen lassen
claude -p "Reviewe docs/specs/user-auth.md. 
  Gibt es Lücken? Fehlende Edge Cases? 
  Security-Bedenken?"

# Schritt 3: Claude implementieren lassen
claude "Implementiere das Feature basierend auf 
  docs/specs/user-auth.md. 
  Starte mit dem Datenbank-Schema."

# Schritt 4: Tests ZUERST (TDD)
claude "Schreibe Tests für alle Endpunkte in der Spec.
  Die Tests sollen ZUERST geschrieben werden,
  BEVOR du die Route-Handler implementierst."

# Schritt 5: Implementation
claude "Implementiere die Route-Handler so dass
  alle Tests grün werden."

# Schritt 6: Review
claude "Prüfe die Implementation gegen die Spec.
  Sind alle Anforderungen erfüllt?"

Pattern 2: Explore → Plan → Code

Explore-Plan-Code ist der von Anthropic empfohlene Standard-Workflow. Er balanciert Struktur mit Flexibilität und eignet sich für die meisten alltäglichen Entwicklungsaufgaben — von mittleren Features über Refactorings bis zur Arbeit in unbekanntem Code. Phase 1 — Explore: Du lässt Claude die Codebase erkunden. 'Analysiere das Payment-Modul. Wie ist es aufgebaut? Welche Abhängigkeiten gibt es? Wo sind die Schwachstellen?' Claude liest Dateien, sucht nach Patterns und baut ein Verständnis auf. Du lernst dabei ebenso viel wie Claude. Phase 2 — Plan: Basierend auf der Exploration erstellt Claude einen Implementierungsplan. 'Erstelle einen Plan für die Integration von Stripe Webhooks. Welche Dateien müssen geändert werden? In welcher Reihenfolge? Welche Tests braucht es?' Du prüfst den Plan, stellst Fragen, und gibst Feedback. Phase 3 — Code: Nach Planfreigabe implementiert Claude den Code. 'Setze den Plan um, Schritt für Schritt. Nach jedem Schritt kurzer Status.' Du verfolgst den Fortschritt und greifst bei Bedarf ein. Der Vorteil dieses Patterns: Es vermeidet den häufigsten Fehler — direkt in die Implementierung zu springen ohne die bestehende Codebase zu verstehen. Die Explore-Phase verhindert teure Fehlentscheidungen. Der Sweet Spot: Genug Struktur um Fehler zu vermeiden, aber nicht so viel Overhead dass kleine Aufgaben unverhältnismäßig lang dauern. Für ein mittleres Feature (1-2 Stunden Implementierung) brauchst du: 5-10 Minuten Explore, 5 Minuten Plan-Review, Rest Implementierung. Profi-Tipp: Nutze Plan Mode (/plan) für die Explore und Plan Phase. So kann Claude nicht versehentlich Code ändern während es noch analysiert.

# PHASE 1: EXPLORE (Read-Only!)
# ─────────────────────────────
claude "Analysiere die Projektstruktur und erkläre mir:
  1. Welches Framework wird genutzt?
  2. Wie ist der Code organisiert?
  3. Wo ist die Authentifizierung implementiert?
  4. Welche Tests gibt es?
  
  WICHTIG: Ändere NICHTS, nur lesen!"

# → Claude erkundet das Projekt und gibt dir eine Übersicht
# → Du verstehst die Codebase BEVOR du Änderungen machst

# PHASE 2: PLAN (Denken, nicht coden!)
# ─────────────────────────────────────
claude "Basierend auf deiner Analyse: Erstelle einen Plan
  wie wir den Login-Bug fixen können.
  
  Der Plan soll enthalten:
  1. Root Cause Analyse
  2. Betroffene Dateien
  3. Schritte zur Lösung
  4. Potenzielle Risiken
  5. Test-Strategie
  
  Schreibe den Plan in PLAN.md.
  Implementiere NOCH NICHTS!"

# → Du prüfst den Plan und gibst Feedback
# → Eventuell mehrere Plan-Iterationen

# PHASE 3: CODE (Jetzt implementieren!)
# ──────────────────────────────────────
claude "Setze PLAN.md um. Starte mit Schritt 1.
  Nach jedem Schritt: Tests laufen lassen."

# → Schritt für Schritt, mit Verifikation
# → Bei Problemen: Zurück zu Phase 2

Pattern 3: Vibe Coding

Vibe Coding ist der schnellste und unstrukturierteste Workflow — und für bestimmte Szenarien genau das Richtige. Du beschreibst was du willst in natürlicher Sprache und lässt Claude einfach machen. Minimales Vorplanen, maximale Geschwindigkeit, sofortiges Feedback. Der Name kommt daher: Du gibst die 'Vibe' vor — das Gefühl, die Richtung, die grobe Idee. 'Bau mir eine Landing Page mit modernem Design, Hero Section, Features und Pricing.' Claude interpretiert die Vibe und erstellt das Ergebnis. Du schaust es dir an, gibst Feedback, und Claude iteriert. Der Ablauf: Prompten → Ergebnis ansehen → Feedback geben → Iterieren. Kein Plan, keine Spec, kein Analysis-Paralysis. Du arbeitest wie ein Bildhauer: Grob die Form hauen, dann verfeinern, dann polieren. Wann Vibe Coding? Für Prototypen und Proof-of-Concepts (Idee schnell validieren). Für persönliche Projekte und Skripte (wo nur du den Code nutzt). Für Experimente und Lernprojekte (wo der Weg das Ziel ist). Für UI/UX Exploration (schnell verschiedene Designs ausprobieren). Wann NICHT Vibe Coding? Für Produktionscode (zu wenig Kontrolle). Für Team-Projekte (zu wenig Dokumentation). Für sicherheitskritische Features (zu wenig Review). Für große Änderungen an bestehendem Code (zu hohes Risiko). Der Trick für effektives Vibe Coding: Iteration statt Perfektion beim ersten Versuch. 'Mach den Button größer', 'Ändere die Farbe zu Blau', 'Füge eine Animation hinzu' — schnelle Feedback-Loops sind der Kern dieses Patterns. Vibe Coding + /compact ist eine mächtige Kombination: Nach 10-15 Iterationen /compact ausführen, dann mit frischem Kontext die nächste Runde starten. So bleibst du produktiv ohne von Context Rot gebremst zu werden.

# Vibe Coding Beispiel:
claude "Baue mir eine To-Do App mit React und Tailwind.
  - Todos hinzufügen, abhaken, löschen
  - LocalStorage für Persistenz
  - Dark Mode
  - Responsive
  GO!"

# → Claude erstellt in 2-3 Minuten eine funktionierende App
# → Gut genug für Demos und Prototypen

# Wann Vibe Coding OK ist:
# ✅ Prototypen & Proof of Concepts
# ✅ Hackathons & Demos
# ✅ Persönliche Tools & Scripts
# ✅ Learning & Experimentieren

# Wann NICHT:
# ❌ Production Code für Teams
# ❌ Sicherheitskritische Features
# ❌ Langlebige Projekte
# ❌ Code der maintained werden muss

Die "Ask User Question" Methode

Die richtige Kombination von Tools und Techniken macht den Unterschied zwischen einem Anfänger und einem Power-User. Hier sind die bewährtesten Workflow-Patterns die erfahrene Claude Code Nutzer täglich einsetzen — praktisch und sofort anwendbar. Das Morning-Briefing Pattern: Starte jeden Tag mit /project:daily (ein Slash-Command den du erstellst). Er zeigt: Git-Status, offene TODOs, fehlgeschlagene Tests, letzte Änderungen. In 10 Sekunden hast du den perfekten Überblick. Das Session-Hygiene Pattern: Neue Aufgabe = neue Session. Vor komplexen Tasks: /plan. Alle 15-20 Nachrichten: /compact. Vor dem Ende: /cost. Diese vier Gewohnheiten allein verbessern deine Ergebnisse um geschätzt 30-40%. Das Zweier-Team Pattern: Nutze zwei Claude Code Instanzen gleichzeitig (mit Git Worktrees). Eine für die Implementierung, eine für Reviews. Der Review-Agent prüft was der Implementierungs-Agent geschrieben hat. Vier Augen sehen mehr als zwei. Das Progressive-Complexity Pattern: Starte einfach und erhöhe die Komplexität schrittweise. Erst die Basis-Funktion, dann Error-Handling, dann Edge Cases, dann Performance-Optimierung, dann Tests. Jeder Schritt baut auf dem vorherigen auf. Das Checkpoint-Pattern: Bei großen Aufgaben alle 30 Minuten: Committen, /compact, kurzer Statuscheck. So hast du immer einen sauberen Rücksetzpunkt falls etwas schiefgeht. Das Cost-Conscious Pattern: Haiku für Exploration, Sonnet für Implementation, Opus nur für kritische Entscheidungen. MCP Server nur bei Bedarf aktivieren. /cost regelmäßig prüfen.

# Claude kann DICH fragen! Nutze das strategisch:

claude "Implementiere ein Dashboard. 
  BEVOR du anfängst:
  - Frage mich welche Metriken angezeigt werden sollen
  - Frage mich welches Chart-Library ich bevorzuge
  - Frage mich ob es responsive sein muss
  - Frage mich nach dem Farbschema
  
  Erst NACH meinen Antworten: Implementiere."

# → Claude stellt dir 4 Fragen
# → Du gibst deine Präferenzen an
# → Claude implementiert GENAU was du willst

# Warum das funktioniert:
# → Vermeidet Annahmen
# → Klarere Anforderungen
# → Besseres Ergebnis beim ersten Mal
# → Weniger Iterations-Schleifen

Team-Workflows

In Team-Umgebungen braucht es standardisierte Workflows die konsistent von allen Entwicklern befolgt werden. Claude Code kann diese Workflows nicht nur unterstützen sondern auch durchsetzen — durch Skills, Commands, Hooks und Agent-Konfigurationen die ins Repository committed werden. Der PR-Workflow: Jeder Entwickler nutzt /project:pr um Pull Requests zu erstellen. Der Command enthält: Branch erstellen nach Naming-Convention, Code implementieren, atomare Commits mit Conventional Commit Format, Tests schreiben und ausführen, PR mit strukturierter Beschreibung erstellen. Das Ergebnis: Jeder PR sieht gleich aus, egal wer ihn erstellt. Der Review-Workflow: Claude reviewt automatisch jeden PR (via GitHub Actions). Menschliche Reviewer fokussieren auf Architektur und Business-Logik statt auf Style und triviale Bugs. Das spart dem Team 5-10 Stunden pro Woche. Der Onboarding-Workflow: Neue Teammitglieder klonen das Repo und haben sofort Zugang zu allen Commands, Skills und Agents. Ein /project:onboarding Command führt sie durch das Projekt: Architektur-Überblick, wichtige Dateien, Konventionen, Workflow-Erklärung. Der Sprint-Workflow: Am Sprint-Beginn: /project:sprint-setup lädt die Sprint-Tickets und erstellt Branches. Während des Sprints: Standardisierte Feature-Entwicklung mit Spec-Driven oder Explore-Plan-Code. Am Sprint-Ende: /project:sprint-review fasst alle Änderungen zusammen. Konsistenz durch Konfiguration: Alle Workflows sind in .claude/ definiert und committed. settings.json für Permissions und Hooks, commands/ für Slash-Commands, skills/ für Wissen, agents/ für spezialisierte Agents. Neue Teammitglieder bekommen alles automatisch. Der Wert standardisierter Team-Workflows: Weniger Kommunikations-Overhead, konsistentere Code-Qualität, schnelleres Onboarding, und messbare Produktivitätssteigerung.

TEAM WORKFLOW: Feature Development
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. PRODUCT OWNER → Feature-Spec schreiben
   → Anforderungen, Akzeptanzkriterien
   
2. TECH LEAD → Spec reviewen mit Claude
   → claude -p "Review @docs/specs/feature.md"
   → Technische Entscheidungen festhalten
   
3. DEVELOPER → Implementieren mit Claude Code
   → Explore → Plan → Code Workflow
   → Tests parallel schreiben (TDD)
   
4. CLAUDE CI → Automatisches Code Review
   → GitHub Action reviewt den PR
   → Prüft auf Spec-Compliance
   
5. TEAM REVIEW → Human Review des PRs
   → Claude's Review als Basis
   → Fokus auf Architektur & Business Logic
   
6. MERGE → Claude aktualisiert Docs
   → claude -p "Aktualisiere README basierend auf neuem Feature"

Pro-Tipps für bessere Ergebnisse

Diese Tipps kommen von erfahrenen Claude Code Nutzern die das Tool täglich seit Monaten einsetzen. Es sind die kleinen Dinge die den Unterschied zwischen guten und exzellenten Ergebnissen machen. Tipp 1 — Zeige Claude guten Code: Wenn du willst dass Claude einen bestimmten Stil schreibt, zeige ihm ein Beispiel. 'Implementiere die Payment-Validierung im gleichen Stil wie @src/auth/validation.ts.' Claude lernt aus Beispielen besser als aus Beschreibungen. Tipp 2 — Nutze die Stärke des Dialogs: Du musst nicht alles in einem Prompt sagen. Starte breit und verfeinere iterativ. 'Implementiere die Funktion → Jetzt füge Error-Handling hinzu → Jetzt optimiere die Performance → Jetzt schreibe Tests.' Jeder Schritt baut auf dem vorherigen auf. Tipp 3 — Committe häufig: Kleine, häufige Commits geben dir Rücksetzpunkte. Wenn Claude in eine falsche Richtung geht, revertierst du den letzten Commit und versuchst es mit einem anderen Prompt. Tipp 4 — Nutze Plan Mode für Exploration: Wenn du nicht sicher bist wie du etwas angehen sollst, frage Claude im Plan Mode. Es analysiert, plant und erklärt — ohne etwas zu ändern. Das spart Token und verhindert Fehlentscheidungen. Tipp 5 — Optimiere deine CLAUDE.md kontinuierlich: Jeder Fehler den Claude macht weil ihm Kontext fehlt, ist ein Hinweis. Notiere diese Fälle und ergänze die CLAUDE.md. Nach 2-3 Wochen ist sie perfekt auf dein Projekt zugeschnitten. Tipp 6 — Kenne die Kosten: Prüfe regelmäßig /cost. Entwickle ein Gefühl welche Aufgaben teuer und welche günstig sind. Optimiere die teuren mit besserem Modell-Routing und Context-Management. Tipp 7 — Vertraue aber verifiziere: Claude produziert meist guten Code. Aber 'meist' ist nicht 'immer'. Lass Tests laufen, reviewe sicherheitskritischen Code, und prüfe Edge Cases manuell.

Workflow Vergleich

Die drei Workflow-Patterns — Spec-Driven, Explore-Plan-Code und Vibe Coding — eignen sich für unterschiedliche Situationen. Hier ein systematischer Vergleich der dir hilft, für jede Aufgabe das richtige Pattern zu wählen. Kontrolle: Spec-Driven (★★★★★) — Volle Kontrolle, alles vordefiniert. Explore-Plan-Code (★★★★☆) — Gute Kontrolle mit Flexibilität. Vibe Coding (★★☆☆☆) — Minimale Kontrolle, maximale Freiheit. Geschwindigkeit: Spec-Driven (★★☆☆☆) — Langsam wegen Spec-Erstellung. Explore-Plan-Code (★★★☆☆) — Mittlere Geschwindigkeit. Vibe Coding (★★★★★) — Schnellster Weg zum Ergebnis. Qualität: Spec-Driven (★★★★★) — Höchste vorhersagbare Qualität. Explore-Plan-Code (★★★★☆) — Hohe Qualität mit gelegentlichen Überraschungen. Vibe Coding (★★★☆☆) — Variable Qualität, gut für Prototypen. Team-Eignung: Spec-Driven (★★★★★) — Perfekt für Teams. Explore-Plan-Code (★★★★☆) — Gut für Teams. Vibe Coding (★☆☆☆☆) — Nur für Solo-Arbeit. Beste Einsatzgebiete: Spec-Driven → Production Features, regulierte Umgebungen, kritischer Code. Explore-Plan-Code → Alltägliche Entwicklung, Refactoring, mittlere Features. Vibe Coding → Prototypen, persönliche Tools, UI-Exploration. Die Empfehlung: Lerne alle drei und wechsle je nach Situation. Im Alltag wirst du vermutlich 50% Explore-Plan-Code, 30% Vibe Coding und 20% Spec-Driven nutzen. Power-User wechseln flüssig zwischen den Patterns — manchmal sogar innerhalb einer Session.

WORKFLOW VERGLEICH
━━━━━━━━━━━━━━━━━

                    │ Spec-Driven │ Explore-Plan │ Vibe Coding
────────────────────┼─────────────┼──────────────┼────────────
Geschwindigkeit     │ ⭐⭐        │ ⭐⭐⭐       │ ⭐⭐⭐⭐⭐
Code-Qualität       │ ⭐⭐⭐⭐⭐  │ ⭐⭐⭐⭐     │ ⭐⭐
Vorhersagbarkeit    │ ⭐⭐⭐⭐⭐  │ ⭐⭐⭐⭐     │ ⭐⭐
Team-Tauglichkeit   │ ⭐⭐⭐⭐⭐  │ ⭐⭐⭐⭐     │ ⭐
Wartbarkeit         │ ⭐⭐⭐⭐⭐  │ ⭐⭐⭐⭐     │ ⭐⭐
Lerneffekt          │ ⭐⭐⭐      │ ⭐⭐⭐⭐⭐   │ ⭐
Aufwand (upfront)   │ ⭐⭐⭐⭐⭐  │ ⭐⭐⭐       │ ⭐

EMPFEHLUNG:
→ Production Code: Spec-Driven oder Explore-Plan
→ Prototypen: Vibe Coding
→ Bug-Fixing: Explore-Plan
→ Neue Codebase: Explore-Plan
→ Bekannte Codebase: Spec-Driven
🎓 Workflow Patterns Zusammenfassung ✅ Spec-Driven: Höchste Qualität, Spec zuerst, TDD ✅ Explore → Plan → Code: Anthropics Best Practice ✅ Vibe Coding: Schnell für Prototypen, nicht für Production ✅ Ask User Question: Claude fragt DICH für Klarheit ✅ Verifizierung: Immer Tests + Lint + Typecheck einbauen ✅ Schrittweise: Kleine Tasks > Ein großer Task ✅ Git: Commit nach jedem erfolgreichen Schritt ✅ Team: Spec → Review → Implement → CI → Human Review