Experimentier-Mindset

Problem: Du greifst jede Session auf dieselben Prompting-Muster zurück. Du hast keine Ahnung, ob das die besten sind, oder ob sie dir still und leise Stunden kosten.

Schneller Gewinn: Führe jetzt dieses eine Experiment durch und schau, wie der Prompt-Stil Claudes Output verändert:

Prompt A: "Fix the bug in auth.ts"
Prompt B: "Let's work through auth.ts together. What might be wrong?"
Prompt C: "Review auth.ts like a senior engineer. List every issue you find."

Vergleiche die drei Ergebnisse. Die kollaborative Version liefert meistens tiefere Analysen und findet Edge Cases, die die direkte Version übersieht. Das ist der Experiment-Loop in Aktion.

Experiment 1: Einfluss des Prompt-Stils

Dieselbe Aufgabe liefert unterschiedliche Outputs, je nachdem wie du sie formulierst. Probiere diese drei Stile bei jeder Debugging-Aufgabe aus:

Style 1 (Command): "Fix the bug in login.ts"
Style 2 (Teaching): "Walk me through login.ts and help me find what's wrong"
Style 3 (Review): "Act as a code reviewer. Analyze login.ts for bugs, security issues, and edge cases."

Was du findest: Style 3 (Review-Modus) bringt mehr Probleme ans Licht, weil er die Arbeit als Analyse rahmt statt als schnelle Fix-Ausführung.

Hier ist das Muster in der Praxis. Führe alle drei Stile gegen einen Login-Handler mit einem klaren Null-Check-Bug und einem subtilen Timing-Fehler im Rate-Limiter aus. Style 1 (Command) patcht den Null-Check und hört auf. Style 2 (Teaching) patcht den Null-Check und erklärt warum er wichtig ist, übersieht aber den Timing-Fehler. Style 3 (Review) findet den Null-Check, die Timing-Schwachstelle, und meldet, dass Fehlermeldungen internen Zustand an den Client leaken.

Das Muster gilt für alle Aufgabentypen, aber der Unterschied variiert. Bei sicherheitskritischem Code findet der Review-Modus deutlich mehr. Bei einfachen UI-Bugs schrumpft der Unterschied und der Command-Stil reicht gut. Bei Refactors liefert der Teaching-Modus oft die saubersten Ergebnisse, weil Claude dabei jede Änderung erklären muss.

Schreibe auf, welcher Stil bei welchem Aufgabentyp in deinen Projekten gewinnt. Nach ein paar Sessions hast du deine eigene Lookup-Tabelle: Security-Arbeit bekommt Review-Modus, einfache Fixes bekommen Command-Modus, Refactors bekommen Teaching-Modus.

Experiment 2: Einfluss des Dateikontexts

Claudes Code-Qualität verändert sich je nach den Dateien, die du als Kontext mitgibst. Teste es selbst:

Experiment A: "Refactor errors.ts to use a cleaner pattern"
Experiment B: "Refactor errors.ts. Reference utils/errors.ts and AuthController.ts for the existing pattern."

Die zweite Version liefert Refactors, die zu deinen bestehenden Mustern passen. Ohne Kontext erfindet Claude Muster, die mit deiner Codebase in Konflikt geraten können.

Probiere das bei einem echten Projekt mit einer Custom-Error-Hierarchie aus. In Experiment A schreibt Claude ein generisches try/catch mit new Error()-Aufrufen. Sauberer Code, aber er ignoriert die AppError-, ValidationError- und NotFoundError-Klassen, die bereits im Repo liegen. Die refaktorierte Datei lässt sich neben dem restlichen Code nicht mal compilieren, ohne Typ-Mismatches.

In Experiment B findet Claude die Error-Klassen in utils/errors.ts, liest wie AuthController.ts sie bereits benutzt, und liefert einen Refactor, der zum bestehenden Muster passt. Gleiche Aufgabe, gleiches Modell, gleiche Session. Der einzige Unterschied waren drei extra Dateireferenzen.

Die eigentliche Lektion geht tiefer als "gib Claude mehr Dateien." Es gibt einen Sweet Spot. 2-4 eng verwandte Dateien einzuschließen verbessert die Output-Qualität zuverlässig. Ab 6-7 Dateien gibt es abnehmende Erträge, weil Claude die Aufmerksamkeit auf zu viele Muster verteilt. Starte mit der Typdefinitions-Datei und einer Datei, die das Muster bereits implementiert, das du willst.

Experiment 3: Planungsmodus vs. direkte Ausführung

Der Planungsmodus (Shift+Tab zweimal) verändert, wie Claude Probleme angeht. Führe diesen Vergleich durch:

Direct: "Add user permissions to the admin dashboard"
Planning: [Shift+Tab twice] "Add user permissions to the admin dashboard"

Im Planungsmodus liest Claude deine Codebase und präsentiert Optionen, bevor er eine einzige Datei anfasst. Du überprüfst den Ansatz, erkennst Probleme frühzeitig und wählst den Weg nach vorne.

Der Unterschied zeigt sich schnell bei Multi-Datei-Features. Führe dieses Experiment bei einem Permissions-System aus, das Auth-Middleware, Dashboard-Routen und Frontend-Komponenten umspannt. Die direkte Ausführung taucht sofort in die Middleware ein und fängt an zu coden. Sie macht Annahmen über die Rollenstruktur, die mit dem bestehenden User-Modell in Konflikt stehen, und die Hälfte der Änderungen muss rückgängig gemacht werden.

Der Planungsmodus hingegen zeigt drei Architektur-Optionen, bevor auch nur eine Zeile Code geschrieben wird. Eine Option nutzt das bestehende Rollen-Enum. Eine andere schlägt eine Permissions-Tabelle für feinere Granularität vor. Die dritte schlägt einen hybriden Ansatz vor. Wähle Option eins, und die Implementierung passt von der ersten berührten Datei an zur Codebase.

Wo der Schwellenwert liegt: Komplexe Features, die 3+ Dateien berühren, profitieren fast immer vom Planungsmodus. Einfache Fixes (eine Datei, offensichtliche Änderung) nicht. Der Break-Even liegt bei ungefähr 2 Dateien. Bei 2 Dateien fügt der Planungsmodus etwa 30 Sekunden Overhead hinzu, spart aber Backtracking. Darunter ist es Zeremonie um der Zeremonie willen.

Experiment 4: CLAUDE.md-Konfigurationen

Deine CLAUDE.md-Datei beeinflusst Claudes Verhalten direkt. Teste verschiedene Konfigurationen:

Configuration A: (empty CLAUDE.md)
Configuration B:
  - Always ask before making changes outside the current feature directory
  - Use conventional commits
  - Prefer small, focused changes over large refactors

Führe dieselbe Aufgabe mit jeder Konfiguration aus und vergleiche:

• Wie viele Rückfragen stellt Claude?
• Hält es sich an deine Projektmuster?
• Sind die Commits richtig eingegrenzt?

Mit Konfiguration A behandelt Claude jedes Verzeichnis als offenes Terrain. Bitte es, ein Dashboard-Feature hinzuzufügen, und es ändert das Datenbankschema, aktualisiert die API-Routen und ändert die Deployment-Konfiguration in einem Schuss. Keine Fragen gestellt. Ein riesiger Commit.

Mit Konfiguration B löst dieselbe Anfrage eine Rückfrage aus: "Das Dashboard-Feature braucht einen neuen API-Endpoint. Soll ich ihn in src/api/ erstellen oder die bestehende routes.ts ändern?" Die resultierende Arbeit landet als drei fokussierte Commits, die jeweils nur die Dateien für diese Schicht berühren.

Deine CLAUDE.md ist keine Dokumentation. Sie ist ein Betriebssystem. Die Anweisungen, die du dort hineinschreibst, formen jede Entscheidung, die Claude trifft. Führe verschiedene Anweisungen gegen dieselbe Aufgabe aus und beobachte, wie sich der Output verändert. Kleine Änderungen in CLAUDE.md produzieren überraschend große Verhaltensänderungen. Schau dir die Rules-Directory-Anleitung an für noch feinere Kontrolle über Claudes Verhalten pro Dateityp.

Experiment 5: Kontext-Fenster-Druck

Dieses hier ist still und leise wichtig. Claudes Output-Qualität sinkt unter Kontext-Druck auf eine Weise, die sich nicht ankündigt. Führe diesen Test durch:

Starte eine frische Session und bitte Claude, ein moderat komplexes Feature zu bauen (etwas, das 3-4 Dateien berührt). Notiere die Qualität. Dann bitte in einer bestehenden Session, die schon eine Weile läuft und angesammelten Kontext hat, um exakt dasselbe Feature.

Die frische Session liefert meistens saubereren Code mit besserem Error-Handling. Die geladene Session schneidet Ecken ab: kürzere Variablennamen, weniger Edge-Case-Checks, manchmal werden Tests übersprungen. Nicht dass Claude vergessen hätte, wie man guten Code schreibt. Das Modell verteilt seine Aufmerksamkeit auf den gesamten angesammelten Kontext und hat weniger Raum für die aktuelle Aufgabe.

Die praktische Schlussfolgerung: Nutze /compact aggressiv vor komplexen Aufgaben. Führe /compact vor jedem Feature aus, das mehr als zwei Dateien berührt, und der Qualitätsunterschied ist leicht sichtbar. Manche Entwickler bevorzugen /clear für einen völlig frischen Start, aber dann verlierst du den Gesprächsverlauf. Der /compact-Befehl teilt den Unterschied, indem er vorherigen Kontext zusammenfasst ohne ihn wegzuwerfen.

Baue deinen eigenen Experiment-Log

Erstelle eine einfache Tracking-Datei, um festzuhalten, was du lernst:

# Claude Code Experiments

## Prompt Style
- Review mode: best for security and auth code
- Command mode: best for quick UI fixes
- Teaching mode: best for refactors

## Planning Mode
- Use for 3+ files
- Skip for single-file changes

Dieser Log wird dein persönlicher Optimierungsleitfaden. Nach einem Monat hast du einen Datensatz dessen, was wirklich in deiner Codebase mit deinen Mustern funktioniert. Das ist mehr wert als jeder generische Rat, weil der richtige Ansatz je nach Projekt, Sprache und Arbeitsart variiert.

Spezifisch zu sein ist der Punkt. "Review-Modus ist besser" ist nicht hilfreich. "Review-Modus findet 2-3x mehr Sicherheitsprobleme in Auth-Code" ist etwas, worauf du jede Session handelst.

Nächste Experimente zum Ausprobieren

Bereit, mehr zu testen? Probiere diese:

1. Kontext-Management: Was passiert bei 60% vs. 90% Kontextnutzung?
2. Auto-Planung: Schlägt automatisierte Planung manuelles Modus-Wechseln?
3. Modellauswahl: Wie gehen verschiedene Modelle mit derselben komplexen Aufgabe um?
4. Tiefes Denken: Produziert erweitertes Denken bessere Architektur-Entscheidungen?

Hör auf zu raten. Führe das Experiment durch. Notiere das Ergebnis. Iteriere.

Jede Session ist eine Chance, etwas zu finden, das dich schneller macht. Entwickler, die systematisch experimentieren, überholen diejenigen, die bei ihrem ersten Instinkt bleiben. Jeder Workaround ist ein Muster, das darauf wartet, benannt zu werden. Jedes benannte Muster ist eine Fähigkeit, die Claude wiederverwenden kann.

Das ist es, was der "System-Evolution-Mindset" in der Praxis bedeutet. Es ist eine der 5 Claude Code Best Practices, die Top-Entwickler von allen anderen unterscheiden.