- April abmedia berichtete, dass Forrest Chang das von Karpathy im Januar geäußerte Coding-Gejammer zu einer „4 CLAUDE.md-Regeln“-Liste aufbereitet hat – damals sammelte das GitHub-Repo 15.000 Sterne; am 12. Mai hatte dieser Repo bereits mehr als 126.000 Sterne erreicht – und zwar in weniger als einem Monat, also ein Wachstum von 8-fach. In der Community tauchten daraufhin viele „erweiterte“ Versuche auf. Besonders der Post des Ingenieurs Mnilax (@Mnimiy) vom 9. Mai, in dem es „zusätzliche 8 Regeln auf Basis der 4 gibt, sodass daraus eine komplette Version mit 12 Regeln wird“, erhielt 5.968 Likes und ist eine der meistdiskutierten Einzelveröffentlichungen in der aktuellen Claude Code Community.
Rückblick auf die 4 Regeln: Forrest Chang verwandelt Karpathys Beschwerden in ausführbare Templates
Forrest Chang ursprüngliche 4 Regeln (jede Regel entspricht einem im Januar auf X von Karpathy benannten Failure-Pattern):
Think Before Coding (erst denken, dann schreiben): Keine impliziten Annahmen treffen – sondern klar sagen, worauf sich die Annahmen beziehen; Trade-offs ausbreiten und diskutieren; wenn unsicher, direkt fragen statt raten; komplexe Lösungen ablehnen, wenn es einfacher geht
Simplicity First (erst Einfachheit): Den kleinsten Code schreiben, der das Problem löst; keine spekulativen Funktionen; keine Abstraktion für einmaligen Code; Senior Engineers sagen, dass zu komplexes Design vereinfacht werden muss
Surgical Changes (chirurgische Änderungen): Nur das ändern, was wirklich zu ändern ist – keine „nebenbei“-Verbesserungen an angrenzendem Code, keine Kommentare, keine Format-Änderungen; kein Refactoring von Dingen, die nicht kaputt sind; an den bestehenden Stil anpassen
Goal-Driven Execution (zielorientierte Ausführung): Erfolgs-Kriterien definieren, iterieren bis verifiziert ist; Claude nicht die Schritte erklären – sondern beschreiben, wie „Erfolg“ aussieht, damit es selbst loop
Das offizielle Anthropic-Dokument formuliert es eigentlich ganz eindeutig: CLAUDE.md ist eine „advisory“-Datei, und Claude hält sich ungefähr zu 80% Wahrscheinlichkeit daran; nach mehr als 200 Zeilen sinkt die Compliance-Rate drastisch, weil wichtige Regeln vom Rauschen überdeckt werden. Forrest Changs Ansatz komprimiert die Regeln auf 65 Zeilen, 4 Regeln – und erreicht damit den „floor“ (die niedrigste Schwelle).
Mnilax fügt 8 Regeln hinzu: neue Failure-Patterns aus der Agenten-Ära im Mai 2026 ergänzen
Mnilax argumentiert: Karpathys Beschwerden im Januar konzentrierten sich auf das Szenario „Claude schreibt Code“, aber die Claude-Code-Ökologie im Mai hat sich weiterentwickelt – hin zu Szenarien mit mehreren Agenten in Zusammenarbeit, Hook-Verkettung, konkurrierenden Skill-Loads, mehrstufigen Workflows über Sessions hinweg usw. – dafür braucht es zusätzliche Regeln. Die folgenden 8 Regeln fügte er hinzu (in der Reihenfolge des Originaltexts zusammengestellt):
Rule 5: Nutze Claude nur für Aufgaben, die Urteilsvermögen erfordern (Klassifizieren, Entwerfen, Zusammenfassen, Extrahieren). Gewisse Entscheidungen (erneut versuchen bei 503, Routing, status code-Verarbeitung, deterministische Umwandlungen) mit normalem Code behandeln
Rule 6: Token Budget ist kein Vorschlag – pro Einzelsauftrag 4.000 Tokens, pro Session 30.000 Tokens als Obergrenze. Wenn du dich dem Budget näherst, aktiv zusammenfassen und neu starten – nicht still überschreiten
Rule 7: Zwei konkurrierende Code-Muster müssen „klar expliziert“ werden (das eine wählen – das Neuere bzw. mit mehr Tests). Erkläre, warum du das ausgewählt hast, und markiere das andere als „zur Bereinigung offen“; das Mischen beider Muster ist die schlechteste Option
Rule 8: Bevor du Code schreibst, zuerst wirklich verstehen – lies exportierte Dateien, direkten Caller, geteilte Utilities. „Sieht nicht zusammenhängend aus (looks orthogonal)“ ist die gefährlichste Formulierung; wenn unklar, nachfragen
Rule 9: Tests müssen die „Intention“ verifizieren, nicht nur das „Verhalten“ – ein Test gilt erst dann als qualifiziert, wenn er schreiben kann, wie es scheitert, wenn sich die Business-Logik ändert; sonst gibst du Claude nur Selbstvertrauen, aber keinen echten Schutz
Rule 10: Mehrstufige Aufgaben brauchen Checkpoints – nach jedem Schritt eine Zusammenfassung: „Was wurde getan? Was wurde verifiziert? Was bleibt?“ Wenn du den Status nicht klar beschreiben kannst, nicht weitermachen
Rule 11: Bestehende Codebase-Konventionen beachten, auch wenn du nicht einverstanden bist – snake_case bleibt snake_case, class component bleibt class component. Wenn du nicht zustimmst, behandle es als eine andere Diskussion, nicht als einseitige Abzweigung
Rule 12: Fehlschläge müssen laut sein – „migration abgeschlossen“ ist falsch, wenn du 30 Records überspringst; „Tests bestanden“ ist falsch, wenn du irgendeinen überspringst. Setze standardmäßig auf aktives Aufdecken von Ungewissheit, nicht auf „Ungewissheit verstecken“
Mnilax behauptet, diese 12 Regeln in 30 Codebasen innerhalb von 6 Wochen getestet zu haben, mit einer Senkung der Fehlerquote von 41% auf 3%. Die Compliance-Rate sei nur leicht gestiegen bzw. leicht gefallen (78% → 76%). Beobachtung dieses Mediums: Diese Zahlen seien selbst gemeldete Testergebnisse des Autors, ohne unabhängige Verifikation; aber die Inhalte der 8 Regeln selbst sind solide und decken sich eng mit den Pain Points, die sich aus den aktuellen Claude-Code-Mehr-Agenten-Use-Cases ergeben (z. B. Agent View bei mehr Sessions-Management, Multi-Agent Layer in der sechsstufigen Architektur).
Anwendbare Szenarien und pragmatische Empfehlungen
Mnilax nennt auch recht direkt, welche Vorgehensweisen du nicht versuchen solltest:
Mehr als 14 Regeln: Compliance sinkt auf 52% (von 76% ein steiler Absturz), 200 Zeilen sind faktisch die reale Obergrenze
Statt Regeln Beispiele verwenden: Die Token-Kosten von 3 Beispielen entsprechen 10 Regeln – Claude neigt dann eher zum Overfitting auf ein einzelnes Beispiel
Abstrakte Instruktionen wie „Be careful / think hard / really focus“: geringe Verifizierbarkeit, Compliance nur 30%
Claude als „Senior Engineer“ anweisen: Identity-Prompt ist unwirksam, wenn das Verhalten sich ändert – nur regelbasierte Anweisungen funktionieren
Auf bestimmte Tools setzen: „Benutze immer eslint“ würde bei nicht installiertem eslint still scheitern; formuliere stattdessen neutral, z. B. „in Übereinstimmung mit dem vorhandenen Codebase-Stil“
Die pragmatische Umsetzung, die dieses Medium empfiehlt: CLAUDE.md ist ein „Behavior Contract“ und keine Wunschliste – jede Regel muss beantworten, welchen konkreten Fehler sie vermeiden soll. Wenn deine Arbeit kein Multi-Step-Pipeline-Szenario betrifft, ist Rule 10 (Checkpoint) unwichtig; wenn in der Codebase bereits Lint eine einzige Stilvorgabe erzwingt, ist Rule 11 (Konventionen beachten) überflüssig. Nach dem Lesen der 12 Regeln behalte die Version, die zu den „echten“ Pannen passt, die du selbst erlebt hast – den Rest kannst du streichen.
Zu den später verfolgbaren Ereignissen gehören: Ob Anthropic offiziell CLAUDE.md als Standardisiertes Dokument aufzieht (derzeit nur „advisory“), ob das Forrest-Chang-Repo in offizielle empfohlene Template-Varianten aufgenommen wird, ob die Community maßgeschneiderte Versionen für bestimmte Domänen (Frontend/Backend/Data Engineering) veröffentlicht und ob sich nach Updates der Claude-Modellversion die Compliance-Rate der Regeln verändert.
Dieser Artikel Karpathy CLAUDE.md knackt 126K Sterne: Community-Version mit 12 fortgeschrittenen Regeln – frühestes Erscheinen in Kettennachrichten ABMedia.
