Claude Code: Best Practices aus echtem Produktivbetrieb

Notiz vom Betreiber: Ich nutze Claude Code jeden Arbeitstag in zwei Unternehmen — einer Beratungsmarke und Pickleland, einer Pickleball-Anlage in Pflugerville, Texas — für alles vom Publishing-Pipeline dieses Blogs bis zum Code-Review auf Produktions-Workers. Das hier ist keine Einführung in das, was Claude Code ist. Es sind die Gewohnheiten, die ich nach Monaten echten Einsatzes behalten habe, und die, die ich abgelegt habe, weil sie mich mehr gekostet als gebracht haben.

Inhaltsverzeichnis

Inhaltsverzeichnis öffnen

• Schreib die CLAUDE.md als Regeln, nicht als Dokumentation
• Was ich an einen Subagent delegiere und was in meinem eigenen Thread bleibt
• Kontextmanagement ist die tägliche Disziplin, kein einmaliges Setup
• Was ich gelernt habe, ihn nicht allein tun zu lassen
• Verifiziere, bevor du ausrollst — Claudes “fertig” ist eine Behauptung, keine Tatsache
• Das Fazit des Operators
• FAQ
  • Was gehört eigentlich in eine CLAUDE.md-Datei?
  • Wie entscheidest du, wann du Claude Codes Ausgabe vertraust, ohne sie erneut zu prüfen?
  • Lässt du Claude Code von sich aus committen und pushen?
  • Welche einzelne Gewohnheit hat dir am meisten Zeit gespart?

Schreib die CLAUDE.md als Regeln, nicht als Dokumentation

Die erste Version jeder CLAUDE.md, die ich geschrieben habe, war zu lang, und jede einzelne ist mit der Zeit kürzer geworden, nie länger. Der Fehler ist, sie wie eine Wiki-Seite zu behandeln — Hintergrund, Philosophie, “warum wir das so machen”. Claude liest die ganze Datei bei jeder Session, egal ob die aktuelle Aufgabe das Detail braucht oder nicht, also konkurriert jeder Absatz, der keine Anweisung ist, um Aufmerksamkeit mit den Absätzen, die es sind.

Was den Rotstift überlebt, ist schmaler: harte Regeln, idealerweise solche, die ein Test erzwingt, damit sie nicht still und leise wieder auftauchen können, plus Links zu längeren Dokumenten für die Fälle, die das Detail wirklich brauchen. “Titel unter 60 Zeichen” verdient eine Zeile. Die Geschichte, warum dieses Limit existiert, verdient einen Link zu einem Dokument, keinen Absatz in der Datei, die Claude bei jeder Session neu liest.

Das Zweite, das ich hinzugefügt habe, und das, von dem ich nicht erwartet hatte, dass es so viel ausmacht: eine kurze Liste geklärter Fakten, einmal aufgeschrieben, mit der expliziten Anweisung, sie nicht erneut zu untersuchen. Am Anfang hat Claude Code alle paar Sessions denselben Fehlalarm neu diagnostiziert — einen instabilen Check, eine bekannte Eigenart in einem Build-Schritt — und Kontext damit verbrannt, eine Schlussfolgerung neu herzuleiten, zu der ich schon gekommen war. Eine Zeile, die den verifizierten Fakt festhält und dem Agenten sagt, weiterzumachen statt die Untersuchung wieder aufzumachen, hat diese Totzeit fast auf null gebracht. Die Regel, die ich anwende: Wenn du dasselbe “eigentlich ist das erwartet” zweimal erklärt hast, gehört es als Fakt in die CLAUDE.md, nicht als etwas, das du ein drittes Mal in den Chat tippst.

Was ich an einen Subagent delegiere und was in meinem eigenen Thread bleibt

Das vollständige Entscheidungsraster zu Skills, Slash Commands und Subagents habe ich separat geschrieben, das wiederhole ich hier nicht. Was es wert ist hinzuzufügen, ist der Filter auf Betreiberebene, den ich tatsächlich anwende, bevor ich einen starte: Kann ich in einem Satz sagen, wie “fertig” aussieht, und würde ich die Zwischenschritte tatsächlich lesen, wenn sie in meinem Hauptthread blieben?

Wenn beide Antworten Nein sind — die Aufgabe ist abgegrenzt und ich will nur das Ergebnis — ist es ein Subagent. Diesen Beitrag in 12 Sprachen zu übersetzen ist das klarste Beispiel: jede Übersetzung ist unabhängig prüfbar, dieses Auffächern ist genau der Grund, warum die Content-Pipeline einen Subagent pro Sprache laufen lässt, und ich will niemals, dass 12 Sprachen an Zwischenhin-und-her den Thread verstopfen, in dem ich noch entscheide, ob der englische Beitrag stimmt.

Wenn die Aufgabe verlangt, dass ich die Argumentation live mitverfolge — eine Schema-Änderung, bei der die dritte Entscheidung davon abhängt, was die zweite ergeben hat — bleibt sie in meinem Hauptthread. Der Fehlermodus, den ich tatsächlich erlebt habe, ist, trotzdem einen Subagent für so etwas zu starten, eine saubere Zusammenfassung zurückzubekommen und dann dreimal zu fragen “warte, was genau hast du gefunden”, weil die Zusammenfassung genau das eine Detail fallen gelassen hat, das zählte. Wenn das bei derselben Aufgabenart zweimal passiert, delegiere ich sie nicht mehr.

Kontextmanagement ist die tägliche Disziplin, kein einmaliges Setup

Die CLAUDE.md ist der Teil, den man einmal schreibt und vergisst. Das Kontextfenster ist der Teil, den ich bei jeder Session managen muss, und der ist es, der tatsächlich entscheidet, ob das Ergebnis gut ist.

• Lesen lassen, bevor er editiert. Claude Code schlägt gerne eine Änderung gegen eine Datei vor, deren vollen aktuellen Zustand er nicht gesehen hat. Ich lasse ihn immer erst die Datei lesen, selbst wenn ich sicher bin zu wissen, was drinsteht — ich habe mich bei diesem “sicher” oft genug geirrt, dass das nicht mehr optional ist.
• Lass eine Session nicht zwei unzusammenhängende Jobs machen. Ein Thread, der eine Stunde ein Deploy-Problem debuggt hat und dann zu Marketing-Texten wechselt, schleppt diese Stunde irrelevanter Tool-Ausgabe in jede folgende Antwort mit. Ich starte lieber eine neue Session, statt Claude zu bitten, “das Deploy-Zeug zu vergessen” — diese Anweisung entfernt die Tokens nicht, sie bittet das Modell nur, sie zu ignorieren, was es unvollkommen tut.
• Planen, bevor er ausführt. Bei allem mit mehr als zwei oder drei Schritten lasse ich mir erst den Plan zeigen und lese ihn, bevor ich die Ausführung freigebe. Einen fünfzeiligen Plan zu lesen dauert fünfzehn Sekunden. Herauszufinden, dass Schritt drei falsch war, nachdem Schritt fünf schon gelaufen ist, kostet den Rest des Nachmittags.
• Große Einfüge-Blöcke sind eine Kosten, keine Bequemlichkeit. Eine ganze Logdatei oder eine komplette API-Antwort in die Unterhaltung zu werfen, wenn nur drei Zeilen davon relevant sind, verbrennt Kontext für die anderen 97 %. Ich grep zuerst und füge den Treffer ein.

Das ist dasselbe Prinzip hinter Context Engineering für KI-Agenten allgemein — Claude Code macht die Kosten nur früher sichtbar, weil du derjenige bist, der den Kontext in Echtzeit volllaufen sieht, statt es hinterher in einem Worker-Log zu debuggen.

Was ich gelernt habe, ihn nicht allein tun zu lassen

Jede irreversible Aktion — Commit, Push, Veröffentlichen, Versenden, Ausgeben — steht hinter einem expliziten Freigabeschritt, den ich selbst ausführe, nie einem, den Claude Code beschließt, weil er die Aufgabe für erledigt hielt. Das ist dasselbe Human-in-the-Loop-Prinzip, das ich überall dort anwende, wo Agents echte Konsequenzen berühren, und Claude Code ist keine Ausnahme, nur weil es auf meiner eigenen Maschine statt in der Cloud läuft.

Das andere, was ich abgelegt habe: pauschale, dauerhafte Erlaubnis für destruktive Befehle zu vergeben. rm -rf, Force-Push, Test-Hooks überspringen — keiner davon bekommt ein generelles Ja. Jeder wird angefragt, jedes Mal, im Kontext, weil das eine Mal, als ich etwas Breites “um Zeit zu sparen” vorab freigegeben habe, das eine Mal war, bei dem die Aufgabe in einen Umfang abgedriftet ist, den ich nicht wirklich geprüft hatte. Die fünf Sekunden, die ein Berechtigungs-Prompt kostet, sind eine billige Versicherung gegen die Alternative.

Verifiziere, bevor du ausrollst — Claudes “fertig” ist eine Behauptung, keine Tatsache

Das ist die Gewohnheit, die sich am meisten ausgezahlt hat, und die am wenigsten glamouröse: Ich vertraue keinem Abschlussbericht. Ich lasse die echte Prüfung laufen.

Claude Code sagt dir, ein Build sei erfolgreich gewesen, eine Testsuite sei grün, ein Link funktioniere. Manchmal wird dieser Bericht aus echter Ausgabe generiert. Manchmal ist es eine selbstsichere Zusammenfassung eines Befehls, der nur zur Hälfte lief, oder eines Checks, der früh zurückkam, ohne etwas Brauchbares drin. Beide sehen im Chat-Transkript identisch aus. Der einzige Weg, sie auseinanderzuhalten, ist, sich die echte Ausgabe selbst anzusehen — dieselbe Disziplin hinter dem Eval-Harness, mit dem ich Agenten ausliefere: eine Aufgabe gilt nicht als erledigt, weil der Agent es sagt, sondern wenn der definierte Check tatsächlich besteht.

In der Praxis heißt das: den Build-Befehl selbst laufen lassen und die Ausgabe lesen, nicht Claudes Paraphrase davon. Die Datei öffnen, die er angeblich bearbeitet hat. Auf den Link klicken, der angeblich funktioniert. Bei Content speziell lese ich den Entwurf adversarial gegen die Regeln, von denen ich weiß, dass sie erzwungen werden — Längenlimits, verbotene Muster, kaputte interne Links — statt darauf zu vertrauen, dass Claude sie beim ersten Mal korrekt angewendet hat, denn meistens hat er, gelegentlich nicht, und die Kosten des gelegentlichen Ausrutschers auf einer Live-Seite sind höher als die neunzig Sekunden, die das erneute Lesen kostet.

Das Fazit des Operators

Bei all dem geht es nicht darum, Claude Code mit der Zeit weniger zu vertrauen — es geht darum, genau festzulegen, wo sich das Vertrauen erst verdienen muss. Kurze, erzwingbare CLAUDE.md statt langer Dokumentation. Subagents für abgegrenzte, prüfbare Arbeit, dein eigener Thread für alles, wo die Argumentation genauso zählt wie das Ergebnis. Frischer Kontext statt einer in die Länge gezogenen Session. Freigabe-Gates auf allem, was du nicht rückgängig machen kannst. Und eine echte Prüfung, selbst gelesen, bevor irgendetwas Delegiertes live geht. Das ist die ganze Liste, und es ist die, die ich tatsächlich durchziehe.

FAQ

Was gehört eigentlich in eine CLAUDE.md-Datei?

Regeln, die der Agent bei jeder Session befolgen muss, als Anweisungen formuliert — nicht der Hintergrund, warum die Codebasis so aussieht, wie sie aussieht. Wenn eine Regel durch einen Test erzwungen wird, sag das und lass den Test die Wahrheitsquelle sein. Längerer Kontext gehört in ein Dokument, auf das die CLAUDE.md verlinkt, nur gelesen, wenn die Aufgabe diesen Bereich tatsächlich berührt, nicht standardmäßig bei jeder Session neu geladen.

Wie entscheidest du, wann du Claude Codes Ausgabe vertraust, ohne sie erneut zu prüfen?

Ich entscheide nicht, den Check zu überspringen — ich entscheide, wie teuer er ist. Einen Build-Befehl selbst laufen zu lassen ist fast kostenlos, also mache ich das immer. Ein vollständiges adversariales erneutes Lesen eines langen Dokuments dauert länger, das hebe ich mir für alles auf, was vor ein echtes Publikum geht. Das Einzige, das ich nie überspringe: alles Irreversible — veröffentlichen, committen, Geld ausgeben.

Lässt du Claude Code von sich aus committen und pushen?

Nein. Jeden Commit und jeden Push führe ich selbst aus, nachdem ich mir den Diff angesehen habe. Claude Code schlägt die Änderung vor; ich bin das Freigabe-Gate für alles, was den Entwurfsstatus verlässt — dieselbe Regel, die ich bei jedem anderen Agenten anwende, den ich betreibe.

Welche einzelne Gewohnheit hat dir am meisten Zeit gespart?

Einen Abschlussbericht als Behauptung zu behandeln, nicht als Tatsache, und die echte Prüfung selbst laufen zu lassen. Es klingt, als würde das alles verlangsamen. In der Praxis ist es das Gegenteil — ein falsches “fertig” in dreißig Sekunden zu erwischen ist schneller, als es drei Tage später in der Produktion zu erwischen.

---

Verwandt: Claude Skills vs. Slash Commands vs. Subagents · Der Agenten-Stack, mit dem ich 30+ Produktionsagenten betreibe · KI-Agenten mit Mensch im Loop: wann braucht es Freigaben? · Wie du Claude Scheduled Tasks nutzt

Willst du Claude Code so in deinem eigenen Unternehmen betreiben? Mein AI Agents for Beginners-Kurs deckt die Grundlagen ab, die dieses Playbook voraussetzt. Das Cowork-Programm ist, wo ich diese Betriebsgewohnheiten in einer strukturierten Gruppe vermittle. Wenn du lieber das Setup für dich erledigen lässt, buche eine 30-minütige Session.