Workflow der Profis

Wie Anthropic-Entwickler wirklich arbeiten

Die Entwickler bei Anthropic -- also die Leute, die Claude Code gebaut haben -- nutzen es täglich selbst. Ihr Workflow hat sich zu einem klaren Muster kristallisiert:

Explore --> Plan --> Code --> Commit

1. Explore -- Verstehen, was da ist

Zuerst orientierst du dich. Du lässt Claude die relevanten Dateien lesen, die Architektur verstehen und den aktuellen Stand analysieren. Noch kein Code, nur lesen und verstehen.

> Lies dir die Dateien in src/auth/ durch und erkläre mir,
  wie die aktuelle Authentifizierung funktioniert.

2. Plan -- Einen Plan machen

Bevor eine Zeile Code geschrieben wird, erstellst du einen Plan. Was muss sich ändern? Welche Dateien sind betroffen? Welche Reihenfolge ergibt Sinn?

> Erstelle einen Plan, wie wir von JWT auf Session-basierte
  Auth umstellen. Noch keine Änderungen, nur der Plan.

3. Code -- Umsetzen

Jetzt erst wird implementiert. Mit einem klaren Plan arbeitet Claude deutlich fokussierter und macht weniger Umwege.

4. Commit -- Sichern

Nach jedem abgeschlossenen Arbeitsschritt: committen. Nicht erst am Ende des Tages, sondern nach jeder logischen Einheit.

*Plan Mode mit Shift+Tab

Mit Shift+Tab schaltest du in den Plan Mode. Claude liest und analysiert, macht aber keine Änderungen an deinem Code. Perfekt für die Explore- und Plan-Phase. Nochmal Shift+Tab schaltet zurück in den normalen Modus.

5 Fehler, die jeder macht

1. Die Kitchen-Sink-Session

Das Problem: Du startest morgens mit einem Bug, baust dann ein Feature, schreibst zwischendurch Tests, aktualisierst die Docs und refactorst eine Komponente -- alles in einer Session.

Warum es schadet: Nach dem dritten Thema ist der Context so voll und durchmischt, dass Claude anfängt, Dinge zu verwechseln. Es referenziert Code von der Bug-Suche, während es am Feature arbeitet. Die Ergebnisse werden immer schlechter.

Die Lösung: /clear zwischen jeder Aufgabe. Fünf fokussierte Sessions schlagen eine chaotische Mammut-Session.

2. Endlos korrigieren statt neu starten

Das Problem: Claude hat einen Fehler gemacht. Du korrigierst. Claude macht einen neuen Fehler. Du korrigierst wieder. Nach der fünften Korrektur ist der Code ein Flickenteppich und der Context voll mit gescheiterten Versuchen.

Warum es schadet: Jeder fehlgeschlagene Versuch bleibt im Context. Claude sieht alle seine Fehler und wird dadurch nicht besser -- sondern oft schlechter, weil es zwischen den verschiedenen Versionen durcheinander kommt.

Die Lösung: Faustregel: Nach zwei gescheiterten Versuchen -- /clear und komplett neu starten. Formuliere den Prompt um, gib bessere Anweisungen und lass Claude mit einem frischen Blick ran.

!Der Sunk-Cost-Fehler

"Aber ich habe schon so viel Context aufgebaut!" -- Das ist der häufigste Grund, warum Leute zu lange in einer kaputten Session bleiben. Ein frischer Start ist fast immer schneller als endloses Korrigieren.

3. Der CLAUDE.md-Roman

Das Problem: Deine CLAUDE.md ist 500 Zeilen lang, mit detaillierten Erklärungen zu jedem Aspekt des Projekts, historischen Entscheidungen und Philosophie.

Warum es schadet: CLAUDE.md wird bei jedem Start geladen und belastet den Context von Anfang an. 500 Zeilen bedeuten tausende Tokens, die du nie wieder zurückbekommst.

Die Lösung: Halte CLAUDE.md kurz und prägnant. Maximal 100-150 Zeilen. Fokus auf: Build-Commands, Architektur-Überblick, wichtige Konventionen. Alles andere kann Claude bei Bedarf aus den Dateien selbst lesen. Prune regelmäßig -- entferne Einträge, die nicht mehr relevant sind.

4. Blindes Vertrauen

Das Problem: Du gibst Claude eine Aufgabe und akzeptierst das Ergebnis, ohne es zu prüfen. "Claude hat es geschrieben, also wird es schon stimmen."

Warum es schadet: Claude kann überzeugend falschen Code schreiben. Besonders bei komplexerer Logik, Edge Cases und API-Integrationen sind Fehler häufig.

Die Lösung: Vertrauen, aber verifizieren.

Tests mitgeben: "Implementiere die Funktion und schreibe Tests dafür"
Screenshots: Bei UI-Änderungen Screenshots machen und prüfen
Schrittweise arbeiten: Nicht "baue das ganze Feature", sondern Schritt für Schritt

*Tests als Sicherheitsnetz

Wenn du Claude bittest, zuerst die Tests zu schreiben und dann die Implementierung, hast du automatisch eine Verifizierung. Die Tests zeigen sofort, ob der Code funktioniert.

5. "Erkunde mal alles"

Das Problem: Du sagst Claude: "Schau dir mal das ganze Projekt an und sag mir, was verbessert werden könnte." Claude liest daraufhin dutzende Dateien, und dein Context ist sofort voll.

Warum es schadet: Ungerichtete Exploration frisst Context, ohne dass du ein konkretes Ergebnis bekommst. Claude liest Dateien, die für deine eigentliche Aufgabe irrelevant sind.

Die Lösung: Scope begrenzen. Statt "schau dir alles an" lieber:

> Analysiere nur die Dateien in src/api/auth/ und identifiziere
  potenzielle Sicherheitsprobleme.

Für projektweite Analysen: Nutze Subagents. Sie haben ihren eigenen Context und liefern dir nur die Zusammenfassung.

Der optimale Tagesablauf

Ein produktiver Tag mit Claude Code sieht so aus:

Morgens: Starte mit einer frischen Session. Lies kurz den Stand vom Vortag (/resume oder Git-Log)
Pro Aufgabe: Explore --> Plan --> Code --> Commit --> /clear
Bei Problemen: Maximal zwei Korrekturversuche, dann /clear und Neustart
Zwischendurch: /compact wenn der Context voll wird, aber die Aufgabe noch läuft
Wissensfragen: /btw für alles, was nicht zur aktuellen Aufgabe gehört

iZusammenfassung

Das Geheimnis produktiver Claude-Code-Nutzung ist nicht, möglichst viel in eine Session zu packen. Es ist das Gegenteil: Viele kurze, fokussierte Sessions mit klaren Aufgaben und sauberem Context.