Claude Code Best Practices: 12 Regeln aus der Praxis

Diese Website ist seit Mai 2026 mit Claude Code entstanden, Seite für Seite, Test für Test. Dabei habe ich gelernt, dass das Werkzeug selten an der Technik scheitert, sondern an fehlenden Regeln: Was soll es wissen, was darf es, woran merkt es, dass etwas nicht stimmt? Die zwölf Regeln unten stammen aus der Praxis, aus echten Fehlern und guten Erfahrungen. Die wichtigste vorweg: Claude Code ist schnell und selbstbewusst, auch wenn es sich irrt. Bauen Sie deshalb jeden Ablauf so, dass Fehler auffallen, bevor sie live gehen.

Wie eine gute Sitzung aussieht

Bevor es an die Regeln geht, ein vereinfachter Blick in eine typische Sitzung. Klicken Sie sich durch:

Schritt für Schritt

Eine Sitzung, Schritt für Schritt

1. Auftrag

   „Bau auf /marketing einen Abschnitt, wie man in KI-Antworten sichtbar wird. Vier Signale, Messung, ein Selbstversuch. Stil wie die anderen Leistungsseiten.“

2. Agent überlegt

   Zuerst schaue ich mir an, wie die anderen Leistungsseiten aufgebaut sind und welche Regeln für Texte gelten.

3. Agent nutzt ein Werkzeug: Dateien lesen

   Leistungsseiten, Datenquelle der Leistungen, Schreibstil

4. Agent nutzt ein Werkzeug: Seite bauen und testen

   Abschnitt geschrieben, Website gebaut, Tests gestartet

5. Werkzeug liefert

   Ein Test schlägt fehl: Ein grauer Hinweistext hat zu wenig Kontrast.

6. Agent überlegt

   Ich nehme die Textfarbe aus dem Designsystem, die für getönte Flächen freigegeben ist, und teste erneut.

7. Werkzeug liefert

   Alle Tests bestanden: Barrierefreiheit, Suchmaschinen, Kontaktformular, Ladezeit.

8. Rückfrage an einen Menschen

   Screenshots vom Desktop und vom Handy an Sebastian. Antwort: „Passt, live stellen.“

9. Antwort des Agenten

   „Veröffentlicht. Der neue Abschnitt ist unter /marketing#ki-antworten erreichbar.“

Nachgestellt und vereinfacht, angelehnt an echte Sitzungen beim Bau dieser Website.

In diesem kleinen Ablauf stecken schon die meisten Regeln: vorher lesen, Tests als Netz, ein Mensch schaut vor der Veröffentlichung drauf.

Die zwölf Regeln

1. Schreiben Sie die Projektregeln auf. Alles, was Claude über Ihr Projekt wissen muss und nicht aus dem Code lesen kann, gehört in die CLAUDE.md oder das Gedächtnis des Projekts. Bei mir stehen dort zum Beispiel: welche Kunden nicht namentlich genannt werden dürfen, dass KI-Bilder gekennzeichnet werden und dass Texte ohne Gedankenstriche auskommen. Wie das geht, zeigt die Anleitung zur Einrichtung.

2. Bauen Sie ein Sicherheitsnetz aus Tests. Bei dieser Website laufen nach jeder Änderung über hundert automatische Tests: Barrierefreiheit nach WCAG 2.2 auf jeder Seite, Suchmaschinen-Grundlagen, das Kontaktformular, Ladezeiten. Claude Code startet sie selbst und behebt, was fehlschlägt. Ohne Tests prüfen Sie alles von Hand, oder gar nicht.

3. Prüfen Sie jede Behauptung über Abläufe. Im Entwurf einer Leistungsseite stand einmal der Satz, dass nichts online geht, was die Tests nicht besteht. Klang plausibel, stimmte nicht: Die Veröffentlichung läuft auch bei roten Tests. Aufgefallen ist es erst bei der Prüfung vor der Veröffentlichung. Seitdem steht diese Tatsache in den Projektregeln.

4. Keine Zahl ohne Quelle. In Blogentwürfen tauchten anfangs Sätze auf wie „die häufigste Frage in meinen Kursen“, ohne dass das jemand gezählt hatte. Seit der Regel „keine Zahl, keine Behauptung über mich ohne Beleg“ landet, was nicht belegt ist, als Frage an mich statt im Text.

5. Verlangen Sie Screenshots. Vom Desktop und vom Handy, nach jeder sichtbaren Änderung. Das kostet Claude Sekunden und mich einen Blick. So fiel zum Beispiel eine Tabelle auf, die auf dem Handy zwei Pixel zu breit war. Andere Fehler, etwa abgeschnittene Buchstaben im Menü, habe ich erst beim eigenen Klicken bemerkt. Deshalb gibt es Regel 12.

6. Eine Aufgabe pro Sitzung. Lange Sitzungen werden teuer und unübersichtlich, weil Claude den ganzen Verlauf bei jedem Schritt neu liest. Neue Aufgabe, neue Sitzung. Wie sich das in den Kosten zeigt, steht im Artikel Was Claude Code kostet.

7. Große Vorhaben zuerst planen. Im Planungsmodus liest Claude nur und schlägt Schritte vor. Erst wenn der Plan stimmt, wird gebaut. Bei der Navigation mit Brotkrumen für die ganze Website habe ich zuerst ein Konzept schreiben lassen, eine Ebene gestrichen und erst dann umsetzen lassen.

8. Machen Sie aus jedem Fehler eine Regel. Ein Skript wurde von den Sicherheitsregeln der Website blockiert, eine Animation ließ sich nicht aus einem Ordner mit Leerzeichen im Namen rendern. Jedes Mal steht danach eine Notiz im Gedächtnis des Projekts, und derselbe Fehler kommt nicht wieder.

9. Messen statt glauben. Die Ladezeit-Tests schlugen ab und zu fehl, obwohl sich nichts geändert hatte. Statt die Grenze zu senken, misst die Website jetzt dreimal nach einem Aufwärmlauf und zählt den mittleren Wert. Seitdem sind die Ergebnisse stabil.

10. Lassen Sie recherchieren, mit Quellen. Für Preise, Gesetze und Fristen lasse ich Claude parallel recherchieren, mit der Vorgabe: Primärquelle, Datum, und markieren, was nicht belegt ist. Das Ergebnis ist ein Faktenblatt, aus dem der Text entsteht. Was als unsicher markiert ist, kommt nicht in den Text oder nur vorsichtig formuliert.

11. Veröffentlichen nur auf Ansage. Claude Code darf bei mir bauen, testen und Dateien ändern. Veröffentlicht wird, wenn ich es sage. Diese Grenze lässt sich in den Berechtigungen festlegen.

12. Am Ende selbst draufschauen. Bevor ein Artikel live geht, lese ich ihn im fertigen Design. Tests prüfen, ob eine Seite funktioniert. Ob sie stimmt, prüft ein Mensch.

Was die Regeln gemeinsam haben

Alle zwölf verschieben Arbeit vom Programmieren zum Beschreiben und Prüfen. Das ist der eigentliche Wandel: Wer mit Claude Code arbeitet, schreibt weniger Code und mehr Regeln, Aufträge und Tests. Wer das nicht mag, wird mit dem Werkzeug nicht glücklich. Wer es mag, baut in Tagen, wofür früher Wochen nötig waren.

Wo die Regeln nicht reichen

Die Regeln machen Fehler seltener, nicht unmöglich. Bei großer, gewachsener Software mit vielen Abhängigkeiten braucht es zusätzlich Menschen, die den Code verstehen. Und bei allem, was rechtlich heikel ist, ersetzt keine Regel die fachliche Prüfung. Ein Gesetzestext, den Claude zusammenfasst, bleibt eine Zusammenfassung.

So fangen Sie an

Nehmen Sie die drei Regeln, die bei Ihnen am meisten fehlen, und schreiben Sie sie heute in die CLAUDE.md Ihres Projekts. Für die meisten sind das: Projektregeln, ein erster automatischer Test und Screenshots nach jeder Änderung.

Wenn Sie Claude Code in Ihrem Team mit solchen Regeln einführen möchten: Ich helfe bei Einführung und Einrichtung von Claude. Die Grundlagen stehen im Artikel Claude Code erklärt.