Karpathy CLAUDE.md Skills: Ich habe es installiert. Ehrliches Urteil

Letzten Dienstag habe ich Claude Code gebeten, einen einzigen Null-Check in einer Laravel-Service-Klasse zu fixen. Eine Zeile. Null-Coalesce statt eines verschachtelten if.

Zurueck kam ein 214-Zeilen-Diff.

Neue Klassen-Konstanten. Eine umbenannte Methode. Vier unnoetige Refactors in Dateien, die ich nicht einmal geoeffnet hatte. Ein "wenn wir schon dabei sind"-Blockkommentar, der erklaerte, warum der vorherige Autor im Unrecht gewesen war. Der Null-Check lag auf Zeile 138 vergraben, korrekt, umgeben von einer kompletten Reorganisation einer Datei, die elf Monate lang tadellos funktioniert hatte.

Genau dieses Verhalten soll das Karpathy CLAUDE.md Skills Plugin stoppen. Und nachdem ich es in drei separaten Projekten installiert habe – einer Laravel-13-Agentur-Codebase, einem persoenlichen Next.js-15-Build und der Content-Pipeline hinter diesem Blog – kann ich dir sagen, was sich wirklich aendert, wo die Leitplanken halten und wo nicht.

Wenn du meine Notizen zum ersten Build des Opus 4.7 Claude Routines Workflows gelesen hast, weisst du schon, dass ich in Claude Code Vollzeit lebe. Dieser Post ist der natuerliche Nachfolger: Sobald du jeden Tag in Claude Code steckst, faellt dir genau auf, welche Verhaltensweisen deinen Vormittag auffressen – und das Karpathy Skills Plugin zielt auf die vier schlimmsten.

Warum dieses Repo in unter einem Monat 71,5k Sterne erreicht hat

Das Projekt heisst andrej-karpathy-skills. Waehrend ich das schreibe, steht es bei 71,5k Sternen, 6,5k Forks, 28 Commits und 8 Contributors. Das ist ein absurdes Star-zu-Commit-Verhaeltnis. Die meisten Repos, die so trenden, sind Frameworks mit 50.000 Zeilen Code. Dieses hier ist im Wesentlichen eine einzige CLAUDE.md Datei plus ein Plugin-Manifest, ein Skills-Verzeichnis, ein Cursor-Rules-Ordner und eine Handvoll Beispiele.

Das ist das gesamte Produkt. Eine einzige Markdown-Datei, die umformt, wie sich Claude Code verhaelt.

Der Grund fuer die Explosion ist einfach: Es benennt die vier Failure Modes, ueber die jeder arbeitende Engineer das vergangene Jahr lang gegen seinen AI-Assistenten geflucht hat, und packt die Loesung als vier benannte Prinzipien, die Claude tatsaechlich respektiert, sobald sie im Context Window sind. Andrej Karpathy hat das Repo nicht geschrieben (es stammt von forrestchang), aber die Prinzipien sind direkt aus Karpathys oeffentlichen Beobachtungen auf X zu LLM-Coding-Fallstricken destilliert – am bekanntesten seine Beschreibung von AI-Assistenten als "an over-eager junior intern savant with encyclopedic knowledge of software, but who also bullshits you all the time, has an over-abundance of courage and shows little to no taste for good code."

Dieses eine Zitat erklaert das ganze Repo. Der Praktikant ist brillant. Der Praktikant ist aber auch gefaehrlich ohne Leine.

Das Karpathy CLAUDE.md Skills Plugin ist die Leine.

Was tatsaechlich im Repo steckt

Vor der Installation musst du wissen, was du dir reinziehst. So sieht das Verzeichnis-Layout auf Wurzelebene aus:

.claude-plugin/
  plugin.json
.cursor/
  rules/
    karpathy-guidelines.mdc
skills/
  karpathy-guidelines/
    SKILL.md
CLAUDE.md
CURSOR.md
EXAMPLES.md
README.md
README.zh.md
LICENSE

Vier Auslieferungsmechanismen, dieselben vier Prinzipien:

1. CLAUDE.md – die Drop-in-Datei fuer Claude-Code-Projektwurzeln
2. .claude-plugin/plugin.json – das Manifest fuer Claude Codes Plugin-Marketplace-Flow
3. skills/karpathy-guidelines/SKILL.md – die Skill-Format-Version, kompatibel mit dem skills.sh Oekosystem, das ich frueher dieses Jahr behandelt habe
4. .cursor/rules/karpathy-guidelines.mdc – Cursors Aequivalent, in den letzten paar Commits hinzugefuegt

Das Plugin-Manifest ist bewusst winzig. Hier ist es wortwoertlich:

{
  "name": "andrej-karpathy-skills",
  "description": "Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls",
  "version": "1.0.0",
  "author": {
    "name": "forrestchang"
  },
  "license": "MIT",
  "keywords": ["guidelines", "best-practices", "coding", "karpathy"],
  "skills": ["./skills/karpathy-guidelines"]
}

Eine Version, eine Skill-Referenz, MIT-Lizenz. Keine Abhaengigkeiten. Keine Post-Install-Skripte. Keine Telemetrie. Das ist die Art Repo, die ich ohne jedes Byte zu lesen installieren wuerde – aber ich habe trotzdem jedes Byte gelesen, und du solltest das auch.

Jetzt der interessante Teil. Die vier Prinzipien selbst.

Die vier Prinzipien, wortwoertlich aus der CLAUDE.md

Ich zitiere sie genau so, wie sie in der Quelldatei stehen, denn wer paraphrasiert, verliert die Schaerfe. Die Spezifitaet ist der Punkt.

1. Think Before Coding

"Don't assume. Don't hide confusion. Surface tradeoffs."

• State your assumptions explicitly. If uncertain, ask.
• If multiple interpretations exist, present them — don't pick silently.
• If a simpler approach exists, say so. Push back when warranted.
• If something is unclear, stop. Name what's confusing. Ask.

Failure Mode, den das verhindert: stille Annahmen. Das mit Abstand schlimmste Verhalten beim AI-gestuetzten Coding. Du bittest um "einen User-Export-Endpoint" und bekommst einen CSV-Download zurueck, der jedes Feld der Datenbank ausliefert, weil das Modell entschieden hat, dass du das wolltest. Ohne dieses Prinzip raet Claude. Mit ihm fragt Claude, ob der Export eingegrenzt werden soll, welche Felder sensibel sind und ob du JSON oder CSV brauchst, bevor es eine einzige Zeile schreibt.

2. Simplicity First

"Minimum code that solves the problem. Nothing speculative."

• No features beyond what was asked.
• No abstractions for single-use code.
• No "flexibility" or "configurability" that wasn't requested.
• No error handling for impossible scenarios.
• If you write 200 lines and it could be 50, rewrite it.

Failure Mode, den das verhindert: das Strategy-Pattern-fuer-ein-einziges-if-Statement-Problem. Du bittest um eine Rabatt-Berechnung und bekommst eine abstrakte DiscountStrategyFactory zurueck, mit konfigurierbaren Rundungsregeln, einem Enum fuer Promotion-Typen und einer DiscountContext Dataclass. Das eigentliche Problem war price * 0.1. Dieses Prinzip ist der Grund, warum meine Testprojekte von ueberladenen 180-Zeilen-Implementierungen auf 30-Zeilen-Versionen geschrumpft sind, ohne ein einziges echtes Feature zu verlieren. Es ist dasselbe Over-Engineering-Muster, das ich in meiner April 2026 AI Tool Roundup bei drei der Modelle angesprochen habe – fast jedes Frontier-Modell baut dir bereitwillig die Kathedrale, wenn du nach einem Schuppen gefragt hast.

3. Surgical Changes

"Touch only what you must. Clean up only your own mess."

• Don't "improve" adjacent code, comments, or formatting.
• Don't refactor things that aren't broken.
• Match existing style, even if you'd do it differently.
• If you notice unrelated dead code, mention it — don't delete it.
• Remove imports/variables/functions that YOUR changes made unused.
• Don't remove pre-existing dead code unless asked.

Failure Mode, den das verhindert: das Drive-by-Refactor. Genau das Verhalten, das meinen Dienstagmorgen gefressen hat. Das ist das Prinzip mit dem groessten spuerbaren Effekt. Damit aktiv wird aus dem 214-Zeilen-Diff ein 1-Zeilen-Diff, und Claude sagt dir am Ende: "Mir ist aufgefallen, dass die Klasse drei unbenutzte Imports aus einem Refactor von vor zwei Commits hat – soll ich die separat angehen?" – anstatt sie einfach zu loeschen.

4. Goal-Driven Execution

"Define success criteria. Loop until verified."

• Transform tasks into verifiable goals
• For multi-step tasks, state a brief plan with steps and verification checks
• Strong success criteria let you loop independently

Failure Mode, den das verhindert: das Vibes-basierte "ich glaub, das passt so"-Ende. Karpathys eigene Formulierung dazu ist die pointierteste Zeile im ganzen Repo: "LLMs are exceptionally good at looping until they meet specific goals… Don't tell it what to do, give it success criteria and watch it go." Sobald dieses Prinzip geladen ist, hoert Claude auf zu sagen "Ich habe Rate-Limiting hinzugefuegt, sag Bescheid, falls noch was ist" und faengt an zu sagen "Rate-Limit hinzugefuegt. Verifikationsplan: (a) curl 10 Requests unter dem Limit, erwarte 200er, (b) curl 11 und erwarte beim letzten einen 429, (c) die bestehende Test-Suite laufen lassen. Laeuft jetzt."

Diese vier Bulletpoints sind das gesamte Framework. Alles andere in diesem Post dreht sich darum, wie du sie geladen bekommst, wie du sie geladen haeltst und wie du merkst, dass sie wirken.

Die drei Installationswege – und welchen du wirklich willst

Das Repo liefert drei Installationswege, weil es drei verschiedene Kontexte gibt, in denen du diese Prinzipien aktiv haben willst. Ich habe alle drei getestet. Jeder hat einen spezifischen Use Case, und sie zu vermischen verbrennt Tokens und produziert Regelkollisionen.

Weg A – Die Claude Code Plugin Installation

Das ist der sauberste Weg, wenn du die Guidelines in jeder Claude-Code-Session auf deiner Maschine verfuegbar haben willst, unabhaengig vom Projekt. Zwei Befehle:

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

Das sind Slash-Commands, die du in Claude Code selbst einfuegst, nicht in die Bash. Der erste fuegt das Repo als Plugin-Marketplace-Quelle hinzu. Der zweite installiert das Plugin, das die skills/karpathy-guidelines/SKILL.md Datei als verfuegbaren Skill registriert. Claude laedt ihn automatisch, wenn die Session zur Aktivierungsbeschreibung des Skills passt.

Wo die Dateien tatsaechlich landen: Claude Code legt installierte Plugins unter ~/.claude/plugins/andrej-karpathy-skills/ ab. Das Skill-Manifest liegt unter ~/.claude/plugins/andrej-karpathy-skills/skills/karpathy-guidelines/SKILL.md. Verifizieren kannst du das mit:

ls -la ~/.claude/plugins/andrej-karpathy-skills/
cat ~/.claude/plugins/andrej-karpathy-skills/.claude-plugin/plugin.json

Wann du das verwenden solltest: Du willst die Prinzipien global aktiv haben, ueber jedes Repo hinweg, ohne irgendeine Projektdatei anzufassen. Am besten fuer Solo-Entwickler auf Maschinen, auf denen du der einzige Nutzer bist.

Wann du das ueberspringen solltest: Du arbeitest an einer Team-Codebase. Skill-Level-Loading ist per-User, also bekommen deine Teammates nicht dasselbe Verhalten. Fuer Team-Konsistenz willst du Weg B.

Weg B – Der Projekt-Root CLAUDE.md Drop-in (oder Merge)

Das ist der Weg, den ich in jedem echten Kundenprojekt verwende. Die Guidelines leben im Repo, werden gemeinsam mit dem Code versioniert, und jeder Teammate, der Claude Code auf diesem Checkout laufen laesst, bekommt automatisch dasselbe Verhalten.

Wenn das Projekt noch keine CLAUDE.md hat, ist es ein einziger Befehl:

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

Commit machen. Fertig. Die naechste claude Session in diesem Verzeichnis laedt die vier Prinzipien in den System-Context, bevor deine erste Nachricht raus ist.

Wenn das Projekt bereits eine CLAUDE.md hat – was wahrscheinlich der Fall ist – ueberschreib sie nicht. Ich habe das einmal im ai-agents-team Repo gemacht (dem, das diesen Blog antreibt) und meine gesamte Content-Generierungs-Konfiguration fuer rund neunzig Sekunden verloren, bevor mir klar wurde, was passiert war, und ich sie aus Git zurueckgezogen habe. Sei nicht wie ich.

Stattdessen: mergen. Hier ist der exakte Workflow, den ich jetzt verwende:

# 1. Fetch the Karpathy principles to a temp file
curl -o .karpathy-skills-temp.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

# 2. Append as a new section to your existing CLAUDE.md
{
  echo ""
  echo "---"
  echo ""
  echo "# Coding Behavior (Karpathy Guidelines)"
  echo ""
  echo "_Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT_"
  echo ""
  cat .karpathy-skills-temp.md
} >> CLAUDE.md

# 3. Clean up the temp file
rm .karpathy-skills-temp.md

# 4. Verify the result opens cleanly and your original rules are still on top
head -40 CLAUDE.md
tail -60 CLAUDE.md

Die Reihenfolge der Abschnitte ist entscheidend. Claude behandelt frueher stehende Regeln in der CLAUDE.md als hoeher priorisiert, wenn Regeln kollidieren. Du willst projektspezifisches Verhalten (deine Content-Templates, deine Laravel-Konventionen, deine Deployment-Regeln) oben stehen haben, und die Karpathy-Prinzipien als allgemeinen Coding-Behavior-Abschnitt weiter unten. Es sind Meta-Regeln darueber, wie Claude Code angehen soll – nicht Domain-Regeln darueber, was Claude bauen soll – also gehoeren sie ans Ende der Datei, nicht an den Anfang.

Wann du das verwenden solltest: Jede Team-Codebase, jedes Projekt, das dir langfristig am Herzen liegt, jedes Repo, in dem du versionskontrolliertes Agent-Verhalten willst.

Weg C – Die Cursor Installation

Wenn du statt Claude Code auf Cursor unterwegs bist, liefert das Repo eine .cursor/rules/karpathy-guidelines.mdc Datei aus, die mit Cursors Rules-System funktioniert. Installieren, indem du die Datei in dein Projekt kopierst:

mkdir -p .cursor/rules
curl -o .cursor/rules/karpathy-guidelines.mdc \
  https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/.cursor/rules/karpathy-guidelines.mdc

Cursors Rules-Engine laedt beim Oeffnen des Projekts automatisch jede .mdc Datei in .cursor/rules/, also ist das ab der naechsten Session aktiv. Der Inhalt sind dieselben vier Prinzipien im Cursor-Rule-Format – eine .mdc Datei ist im Grunde nur Markdown mit einem kurzen Frontmatter-Block, der deklariert, wann die Regel greifen soll.

Wann du das verwenden solltest: Du arbeitest primaer in Cursor. Ich nutze Claude Code weiterhin fuer agentische Arbeit, also installiere ich beides – die Dateien kollidieren nicht, weil sie in unterschiedlichen tool-spezifischen Verzeichnissen liegen.

Wie du pruefst, ob es wirklich aktiv ist

Installieren ist das eine. Zu wissen, ob es irgendwas bewirkt, ist das andere. Jedes Skill/Plugin-System, das ich benutzt habe, hat ein "ist das ueberhaupt geladen?"-Problem, und die Antwort ist nie, einfach der Install-Message zu vertrauen.

Hier ist meine dreistufige Verifikation, die ich nach jeder Installation durchgehe:

Schritt 1 – Read-back-Test. Oeffne eine frische Claude-Code-Session im Projekt und frag:

"Which coding behavior principles are currently loaded in your context? List them with their source."

Wenn die Installation funktioniert hat, listet Claude die vier Karpathy-Prinzipien mit Namen auf – Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution – und nennt die CLAUDE.md Datei oder den Plugin-Skill als Quelle. Wenn es generische "good coding practices" ohne die Karpathy-Namen auflistet, stimmt etwas nicht: Entweder wurde die Datei nicht gespeichert, das Plugin hat nicht installiert, oder du bist in einem Verzeichnis, das Claude nicht als Projektwurzel betrachtet.

Schritt 2 – Verhaltenstest. Gib ihm eine Aufgabe, die gezielt das alte Fehlverhalten triggert:

"Fix the null check on line 42 of UserService.php."

Ohne die Guidelines: wuchernder Diff, ungefragter Refactor, Style-Aenderungen, die volle Dienstagmorgen-Erfahrung. Mit den Guidelines: Claude sollte genau das tun, worum du gebeten hast, den minimalen Edit machen und alles andere, was ihm aufgefallen ist, in einer separaten Nachricht flaggen, statt es mit auszuliefern.

Schritt 3 – Scope-Creep-Falle. Das ist die, die es dir wirklich zeigt.

"Add a rate limit to the login endpoint. While you're in there, also add request logging."

Ohne die Guidelines: Claude macht beides, verkauft es als eine einzige Aenderung und schmeisst wahrscheinlich noch einen Refactor der Auth-Middleware obendrauf. Mit Goal-Driven Execution aktiv sollte Claude die Tasks trennen, Erfolgskriterien fuer jede einzelne nennen und – das ist das Signal – Verifikationsschritte fuer das Rate-Limit vorschlagen, bevor es die Logging-Aufgabe anfasst. Wenn es sie in eine grosse unverifizierte Aenderung zusammenklappt, sind die Prinzipien nicht korrekt geladen.

Ich habe diesen Drei-Schritte-Test bei jeder Installation laufen lassen. Er dauert rund vier Minuten. Ueberspringst du ihn, vertraust du dem Self-Report des Modells darauf, ob die Leitplanken stehen – und Self-Report ist genau das, wogegen diese Prinzipien entworfen wurden.

Merge mit einem bestehenden Setup (der reale Fall)

Alles oben geht von einer sauberen Installation aus. Der haertere Fall – und der, dem die meisten Engineers, die ich kenne, tatsaechlich begegnen – ist das Mergen dieser Prinzipien in ein Projekt, das schon eine opinionated CLAUDE.md mit eigenen Regeln hat.

Das Repo dieses Blogs ist ein gutes Beispiel. Das ai-agents-team Projekt hat eine Content-Generierungs-CLAUDE.md, die Arias Voice-Regeln, Brand-Konfigurationen, Dateinamens-Konventionen und einen Stapel harter Constraints definiert ("no AI filler phrases", "3,000+ words minimum", "no YAML frontmatter in posts"). Karpathys Prinzipien drehen sich um Coding-Verhalten, nicht um Content-Verhalten, aber ich wollte sie trotzdem geladen haben fuer die Momente, in denen Arias Arbeit in echten Code ueberschwappt – wenn ich das Repo bitte, eine Agent-Definition zu refactoren, einen Hook zu aktualisieren oder eine neue Skill-Datei hinzuzufuegen.

Die Struktur, bei der ich nach ein paar Iterationen gelandet bin:

# CLAUDE.md

<Project-specific identity and purpose goes first>

## Project Overview
...

## Architecture
...

## Hard Constraints
<Domain rules — these are non-negotiable and win any conflict>
...

---

# Coding Behavior (Karpathy Guidelines)

<Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT>

<The four principles verbatim, dropped in as an appendix>

Die horizontale Linie vor dem Coding-Behavior-Abschnitt ist Absicht. Sie gibt Claude einen visuellen Struktur-Hinweis, dass der folgende Abschnitt eine andere Ebene betrifft – Meta-Regeln darueber, wie Code geschrieben wird, im Gegensatz zu Domain-Regeln darueber, was das Projekt macht. In meinen Tests respektiert Claude diese Trennung: Wenn ich Content editiere, folgt es den Content-Regeln oben; wenn ich Code editiere, zieht es den Karpathy-Abschnitt rein und wendet ihn an.

Drei Regeln fuer das Mergen, ohne dein bestehendes Setup zu zerschiessen:

1. Projektspezifische Regeln bleiben oben. Dein Brand-Voice, deine Framework-Entscheidungen, deine Dateinamens-Konventionen, deine Verbotsphrasen-Liste – das sind Domain-Regeln und sie muessen jeden Konflikt gewinnen. Setz sie ueber den Karpathy-Abschnitt.

2. Behalte die Quellen-Attribution. Eine Zeile: Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT. Es ist MIT-lizenziert, du kannst es also frei reindroppen, aber die Attribution zaehlt aus zwei Gruenden: Sie laesst dich in Zukunft nachvollziehen, woher die Prinzipien stammen, falls sie sich je falsch anfuehlen, und sie signalisiert Claude (das solche Dinge liest), dass dieser Abschnitt eine externe Herkunft hat.

3. Vermische niemals den Wortlaut der Prinzipien mit deinen Projektregeln. Wenn du Simplicity First innerhalb einer projektspezifischen Regel referenzieren willst ("apply Simplicity First here — no speculative abstractions"), ist das okay. Was nicht okay ist: die Prinzipien in deine eigenen Worte umzuschreiben und den wortwoertlichen Wortlaut wegzulassen. Die Spezifitaet des Originaltextes ist es, die die Prinzipien wirksam macht, und ihn in deiner eigenen Sprache umzuformulieren stumpft genau die Kante ab, die Claude braucht, um sie zu erkennen.

Das ersetzt keine Superpowers, Skills oder andere Verhaltens-Systeme, die du schon geladen hast. Es ergaenzt sie. Die Karpathy-Prinzipien sind schmal – sie regeln, wie Code-Aenderungen gemacht werden, nicht was das Projekt ist, nicht welche Tools zum Einsatz kommen, nicht welche deine Domain-Konventionen sind. Gestapelt auf einer starken Projekt-CLAUDE.md sind sie ein Netto-Upgrade. Statt einer gestapelt, lassen sie Claude ohne Domain-Context zurueck, und du wirst das Ergebnis hassen.

Ein konkretes Beispiel aus meinem eigenen Stack: Die Pipeline dieses Blogs nutzt den Claude programmatic SEO skill, den ich frueher fuer automatisierte On-Page-Optimierung gebaut habe. Dieser Skill lebt ueber dem Karpathy-Abschnitt in meiner CLAUDE.md, weil er eine Domain-Regel ist – er definiert, was geschrieben wird. Die Karpathy-Prinzipien sitzen darunter, weil sie Meta-Regeln sind – sie definieren, wie der Code hinter diesem Skill editiert wird, wenn ich ihn refactoriere. Getrennte Belange, getrennte Abschnitte, keine Kollisionen.

Mein meinungsstarkes Fazit – Wo das gewinnt, wo nicht

Die diplomatische Version erspare ich dir. Hier ist der klare Call nach einer Woche Nutzung:

Wo das gewinnt – und zwar deutlich: Genau die vier Failure Modes, die AI-gestuetztes Coding im letzten Jahr von "fantastisch" zu "frustrierend" gedreht haben. Stille Annahmen. Over-Engineering. Drive-by-Refactors. Vibes-basiertes "ich glaub, ich bin fertig." Alle vier sind in meinen Sessions messbar seltener. Der Dienstagmorgen-214-Zeilen-Null-Check-Vorfall ist seit der Installation nicht wieder aufgetreten. Meine durchschnittliche Diff-Groesse fuer kleine Bugfix-Tasks ist spuerbar gesunken – das konsistente Muster ueber die drei Projekte hinweg liegt bei rund einem Drittel der Zeilenzahl fuer dieselbe Aufgabe, ohne Korrektheitsverlust.

Das Goal-Driven Execution Prinzip ist der Sleeper. Klingt wie der langweilige der vier, aber es veraendert deinen Workflow am staerksten. Sobald Claude anfaengt, Verifikationskriterien vorneweg zu nennen, hoerst du auf, Prompts wie "add validation" zu schreiben, und fangst an, Prompts wie "add validation for empty emails — success = test case X passes" zu schreiben. Allein diese Verschiebung hat mich zu einem messbar besseren Prompter gemacht – ein seltsamer Nebeneffekt der Installation einer fremden Markdown-Datei.

Wo das an seine Grenzen stoesst: Vier Prinzipien sind kein Ersatz fuer Domain-Wissen. Claude mit geladenen Karpathy-Guidelines weiss immer noch nicht, dass deine Laravel-Codebase Form Requests statt Inline-Validierung nutzt, oder dass dein React-Projekt ueberall Server Components verwendet, oder dass deine API in diesem einen Endpoint aus Legacy-Gruenden snake_case zurueckgibt. Die Prinzipien verhindern, dass Claude Dinge schlimmer macht – sie machen Claude nicht schlauer bezueglich deines spezifischen Stacks. Du brauchst weiterhin eine projektspezifische CLAUDE.md. Du brauchst weiterhin Skills. Du brauchst weiterhin gute Prompts.

Wo es mich aktiv nervt: Bei trivialen Tasks fuegen die Prinzipien Reibung hinzu. Wenn ich Claude bitte, eine Variable umzubenennen, bekomme ich gelegentlich eine dreizeilige Scope-Bestaetigung, bevor das Rename passiert. Die Guidelines selbst geben das zu ("the guidelines bias toward caution over speed — useful for non-trivial work while maintaining judgment for simple tasks"), aber in der Praxis unterscheidet das Modell nicht immer. Ich habe mir angewoehnt, "single trivial change, no verification needed" an Prompts anzuhaengen, wenn ich weiss, dass der Scope zwei Zeichen ist. Das funktioniert. Aber es ist ein Workaround, kein Fix.

Installier es, wenn: Du echten Code fuer echte Projekte schreibst, taeglich mit AI-Coding-Assistenten arbeitest und im letzten Monat von Scope Creep, stillen Annahmen oder Drive-by-Refactors gebissen wurdest. Die Messlatte fuer den Nutzen ist hier niedrig genug, dass jeder, der Produktionscode ausliefert, es schon installiert haben sollte.

Ueberspring es, wenn: Du Claude Code rein fuer Wegwerf-Prototyping, Spike-Arbeit oder Vibe-Coding nutzt, wo Geschwindigkeit mehr zaehlt als Scope-Disziplin. Die Guidelines werden dir im Weg stehen. Sie sind nicht fuer den Modus gemacht, den Karpathy selbst als "fully give in to the vibes, embrace exponentials, and forget that the code even exists" beschrieben hat. Sie sind fuer den Modus gemacht, den er spaeter beschrieben hat – den, in dem du bei Code, der dir wirklich wichtig ist, "slow, defensive, careful, paranoid" bist.

Fuer die Pipeline dieses Blogs und jedes Kundenprojekt, das ich aktuell ausliefere, sind sie drin. Fuer Wochenend-Experimente sind sie draussen. Das ist die ehrliche Aufteilung.

Vorher und Nachher – der Null-Check nochmal

Lass mich den Kreis schliessen, den ich oben im Post geoeffnet habe.

Ich habe den Dienstagmorgen-Task nach der Installation der Guidelines erneut laufen lassen. Dieselbe Codebase, dieselbe Datei, dieselbe Zeile, derselbe Prompt: "Fix the null check on line 138 of UserService.php — $user->profile->avatar should fall back to a default if the profile is null."

Vor den Guidelines (repraesentativ fuer das, was beim ersten Mal passiert ist):

• 214-Zeilen-Diff
• Neue Klassen-Konstante DEFAULT_AVATAR
• Methode von getAvatar() in resolveAvatar() umbenannt, "for clarity"
• Vier unnoetige Null-Coalesce-Fixes in Methoden, die ich nicht erwaehnt hatte
• Ein Blockkommentar, der erklaerte, warum der Ansatz des Originalautors suboptimal gewesen war
• Der eigentliche Null-Check-Fix, korrekt, auf Zeile 138, umgeben von allem obigen

Nach den Guidelines (neu ausgefuehrt auf einem frischen Branch vom gleichen Ausgangszustand):

• 1-Zeilen-Diff
• $user->profile?->avatar ?? asset('images/default-avatar.png') auf Zeile 138
• Eine separate Nachricht am Ende: "I noticed four other places in this file where ->profile-> is accessed without a null check. Same pattern, different methods. Want me to address those in a separate commit, or leave them?"

Ein-Zeilen-Fix. Explizites Aufzeigen der angrenzenden Issues. Kein still ausgelieferter Refactor. Das Modell hat die angrenzenden Probleme trotzdem gesehen – dieselbe Intelligenz – aber die Guidelines haben die Antwort von "lass mich das einfach alles mit erledigen" zu "lass mich es flaggen und dich entscheiden lassen" umgebaut.

Das ist das gesamte Value Proposition in einem einzigen Vorher-Nachher. Das Modell wird nicht duemmer. Es wird diszipliniert.

Es gibt einen Grund, warum das Repo in unter einem Monat die 71k-Sterne-Marke geknackt hat. Jeder arbeitende Engineer hat seine eigene Version dieser Dienstagmorgen-Geschichte, und jeder von uns wollte einen Weg, das zu stoppen, ohne 50-Zeilen-System-Prompts zu schreiben, die in eigenen Worten zu erklaeren versuchen, was "don't drive-by refactor" bedeutet. Die Karpathy-Prinzipien tun das in vier benannten Abschnitten, mit einem Wortlaut, der scharf genug ist, dass Claude ihn tatsaechlich befolgt, fuer den Preis eines einzigen curl Befehls. Diesen Deal nehme ich jedes einzelne Mal.

Jetzt ist die einzige Frage, die es sich zu stellen lohnt, die, die du dir stellen solltest, waehrend du diesen Tab schliesst: Wann hat dein AI-Assistent zuletzt eine Aenderung gemacht, die dreimal groesser war als das, worum du gebeten hast? Wenn die Antwort "diese Woche" ist, weisst du schon, was als Naechstes zu tun ist.

Haeufig gestellte Fragen

Was ist das Karpathy CLAUDE.md Skills Plugin?

Das Karpathy CLAUDE.md Skills Plugin ist eine einzige CLAUDE.md Datei (plus ein Plugin-Manifest, ein Skill-Verzeichnis und ein Cursor-Rules-Ordner), die vier Coding-Behavior-Prinzipien in Claude Code laedt, destilliert aus Andrej Karpathys oeffentlichen Beobachtungen zu LLM-Coding-Fallstricken. Es ist MIT-lizenziert, liegt auf github.com/forrestchang/andrej-karpathy-skills und hat rein durch Mundpropaganda 71,5k Sterne erreicht.

Was sind die vier Karpathy-Prinzipien fuer Claude Code?

Die vier Prinzipien sind Think Before Coding (Annahmen offenlegen, bei Unsicherheit nachfragen), Simplicity First (minimaler Code, der das Problem loest, keine spekulativen Features), Surgical Changes (nur anfassen, was noetig ist, keine Drive-by-Refactors) und Goal-Driven Execution (verifizierbare Erfolgskriterien definieren, bis zur Verifikation looped). Das wortwoertliche Breakdown oben zeigt die vollstaendigen Bulletlisten.

Wie installiere ich die Karpathy CLAUDE.md in ein bestehendes Projekt?

Fuehr curl -o .karpathy-skills-temp.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md aus und haeng es dann als neuen "Coding Behavior"-Abschnitt unten an deine bestehende CLAUDE.md an. Ueberschreib niemals eine existierende CLAUDE.md – projektspezifische Regeln muessen oberhalb des Karpathy-Abschnitts bleiben, damit sie jeden Konflikt gewinnen. Der vollstaendige Merge-Workflow ist oben dokumentiert.

Ersetzt das Claude Code Skills oder Superpowers?

Nein. Die Karpathy-Prinzipien sind Meta-Regeln darueber, wie Code-Aenderungen gemacht werden – sie kennen deinen Stack, deine Konventionen oder deine Domain nicht. Stapel sie auf deine bestehende Projekt-CLAUDE.md, Skills und andere Verhaltens-Systeme. Sie ergaenzen, sie ersetzen nicht. Installierst du das als deine einzige Konfiguration, wird Claude diszipliniert, aber domain-blind sein.

Wie pruefe ich, ob die Karpathy-Prinzipien wirklich geladen sind?

Fahr einen Drei-Schritte-Check: (1) bitte Claude, die Coding-Behavior-Prinzipien in seinem Context aufzulisten, und bestaetige, dass alle vier Karpathy-Namen auftauchen, (2) gib ihm einen kleinen Bugfix-Task und pruef, ob der Diff chirurgisch bleibt, (3) gib ihm eine Scope-Creep-Falle ("fix X, while you're there also do Y") und bestaetige, dass es die Tasks mit Verifikationskriterien trennt, statt sie zu kollabieren. Faellt irgendein Schritt durch, hat die Installation nicht gegriffen.

Lass uns zusammenarbeiten

Moechtest du AI-Systeme bauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (Custom-Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Loesungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Security-Services): xcybersecurity.io