henning thies.

Arbeitsweise

Erst planen, dann bauen

Explore → Plan → Code → Commit

Explore → Plan → Code → Commit

Der größte Fehler beim Agentic Coding: Direkt losbauen ohne Plan. Claude springt gerne zur Lösung – aber ohne klare Spezifikation baut es oft das Falsche.

Planning-First bedeutet: Claude erstellt erst einen Plan, du prüfst ihn, dann wird implementiert. Die Spezifikation ist der Schlüssel.

Warum Planung so wichtig ist

Wenn du Claude sagst "Implementiere Feature X", macht es Annahmen. Viele Annahmen. Und diese Annahmen sind oft falsch.

Ohne Plan

  • Claude baut direkt los
  • Falscher Ansatz → alles nochmal
  • Vergessene Edge Cases
  • Chaos bei größeren Features
  • Du bemerkst Fehler erst spät

Mit Plan

  • Claude zeigt Ansatz vorab
  • Du korrigierst vor dem Coding
  • Alle Fälle durchdacht
  • Strukturiertes Vorgehen
  • Fehler werden früh gefunden

Der Workflow: Explore → Plan → Code → Commit

1. Explore

Bevor du planst, muss Claude den Kontext verstehen. Lass es zuerst erkunden:

" Lies dir folgende Dateien durch und erkläre mir, wie aktuell die Authentifizierung funktioniert: - app/controllers/sessions_controller.rb - app/models/user.rb - app/models/concerns/authenticatable.rb Ändere noch nichts. "

Claude liest die Dateien, erklärt den aktuellen Stand, und du verstehst, womit du arbeitest.

2. Plan

Jetzt erstellst du mit Claude zusammen einen Plan:

" Ich will OAuth mit Google hinzufügen. Erstelle einen detaillierten Plan: 1. Welche Dateien werden betroffen? 2. Welche Änderungen pro Datei? 3. In welcher Reihenfolge vorgehen? 4. Welche Edge Cases beachten? 5. Wie können wir verifizieren, dass es funktioniert? Implementiere noch NICHTS – zeig mir nur den Plan. "

Tipp

Das explizite 'Implementiere noch NICHTS' ist wichtig. Ohne diese Anweisung springt Claude gerne direkt zum Code.

3. Review & Verfeinern

Claude liefert einen Plan. Jetzt prüfst du:

  • Macht der Ansatz Sinn? Gibt es einen einfacheren Weg?
  • Fehlt etwas? Edge Cases, Validierung, Fehlerbehandlung?
  • Reihenfolge ok? Abhängigkeiten beachtet?
  • Verifizierung dabei? Wie prüfen wir, ob es funktioniert?
Feedback geben
" Der Plan sieht gut aus, aber: - Wir brauchen auch einen Fallback wenn Google nicht erreichbar ist - Die Session-Dauer sollte konfigurierbar sein - Füge einen Test für den Callback-Handler hinzu Aktualisiere den Plan. "

4. Code

Erst wenn der Plan steht, geht es ans Implementieren:

" Plan sieht gut aus. Starte mit Schritt 1. Nach jedem Schritt: Zeig mir kurz was du gemacht hast. "

5. Commit

Nach erfolgreicher Implementation und Verifizierung:

" Alle Tests sind grün. Committe die Änderungen mit einer aussagekräftigen Message und erstelle einen PR. "

Die Spezifikation als Schlüssel

Je besser die Spec, desto besser das Ergebnis

Eine gute Spezifikation ermöglicht Claude, sich selbst zu validieren. Wenn klar definiert ist, was "fertig" bedeutet, kann Claude prüfen, ob es fertig ist.

Ohne klare Spec ist Claude auf dein Feedback angewiesen. Mit klarer Spec kann Claude selbstständig iterieren bis es stimmt.

Elemente einer guten Spezifikation

## Feature: Google OAuth

### Ziel
User können sich mit ihrem Google-Account anmelden.

### Akzeptanzkriterien
- [ ] "Mit Google anmelden" Button auf Login-Seite
- [ ] Redirect zu Google OAuth
- [ ] Callback erstellt User wenn nicht vorhanden
- [ ] Callback loggt existierenden User ein
- [ ] Fehlerbehandlung wenn Google nicht erreichbar
- [ ] Session-Dauer: 7 Tage (konfigurierbar)

### Nicht im Scope
- Andere OAuth-Provider (kommt später)
- Account-Linking (nur Google ODER E-Mail)

### Verifizierung
- Unit Tests für OauthController
- Integration Test für kompletten Flow
- Manueller Test mit echtem Google-Account

Wann planen, wann nicht?

Nicht jede Aufgabe braucht einen ausführlichen Plan:

Situation Planen?
Neues Feature mit mehreren Dateien Ja, immer
Refactoring bestehenden Codes Ja
Unklare Anforderungen Ja, erst klären
Bugfix (Ursache bekannt) Nein
Kleine Änderung (1 Datei) Optional
Typo fixen Nein

Tipp

Faustregel: Wenn du mehr als 2-3 Dateien anfassen musst, lohnt sich ein Plan. Die Zeit für Planung spart ein Vielfaches an Korrekturzeit.

Plan Mode in Claude Code

Claude Code hat einen eingebauten Plan Mode, der Explore und Plan formalisiert:

# In Claude Code:
/plan # Wechselt in den Plan Mode

Im Plan Mode kann Claude Dateien lesen und analysieren, aber keine Änderungen machen. Perfekt für die Explore- und Plan-Phase.

Interview-Technik für komplexe Features

Bei größeren Features: Lass Claude dich interviewen, bevor es plant.

" Ich will ein Benachrichtigungssystem bauen. Interview mich dazu: - Welche Arten von Benachrichtigungen? - Wie werden sie ausgelöst? - Wo werden sie angezeigt? - E-Mail-Integration? Stelle Rückfragen bis du alles verstanden hast. Dann schreibe eine Spezifikation. "

Claude stellt gezielte Fragen, deckt Unklarheiten auf, und die resultierende Spec ist durchdachter als wenn du sie alleine geschrieben hättest.

Zusammenfassung

  • Explore → Plan → Code → Commit – diese Reihenfolge spart Zeit
  • Die Spezifikation ermöglicht Selbstvalidierung – Claude kann prüfen, ob es fertig ist
  • Review den Plan vor der Implementation – Fehler früh zu finden ist billiger
  • Explizit "Implementiere noch nichts" – sonst springt Claude zum Code