Karpathy CLAUDE.md Skills: Ik installeerde het. Het echte oordeel

Afgelopen dinsdag vroeg ik Claude Code om een enkele null-check in een Laravel service class te fixen. Eén regel. Null-coalesce in plaats van een geneste if.

Het kwam terug met een diff van 214 regels.

Nieuwe class-constanten. Een hernoemde methode. Vier ongerelateerde refactors op bestanden die ik niet eens had geopend. Een "nu we hier toch zijn"-blokcommentaar dat uitlegde waarom de vorige auteur het fout had. De null-check stond begraven op regel 138, correct, omringd door een complete reorganisatie van een bestand dat al elf maanden prima werkte.

Dat is precies het gedrag dat de Karpathy CLAUDE.md skills plugin wil stoppen. En na installatie in drie aparte projecten — een Laravel 13 agency-codebase, een persoonlijke Next.js 15 build, en de content-pipeline achter deze blog — ben ik er klaar voor om je te vertellen wat er écht verandert, waar de vangrails het houden, en waar niet.

Als je mijn eerste-build-notities over de Opus 4.7 Claude Routines workflow hebt gelezen, weet je al dat ik voltijds in Claude Code leef. Deze post is de logische vervolg: zodra je dagelijks in Claude Code zit, merk je precies welke gedragingen je ochtenden opvreten — en de Karpathy skills plugin mikt op de vier ergste.

Waarom deze repo in minder dan een maand 71,5k sterren haalde

Het project heet andrej-karpathy-skills. Op het moment dat ik dit schrijf staat het op 71,5k sterren, 6,5k forks, 28 commits en 8 contributors. Dat is een absurde ster-tot-commit-ratio. De meeste repo's die zo trenden zijn frameworks met 50.000 regels code. Deze is in wezen één CLAUDE.md-bestand plus een plugin-manifest, een skills-directory, een Cursor-rules-map en een handvol voorbeelden.

Dat is het hele product. Eén markdown-bestand dat hervormt hoe Claude Code zich gedraagt.

De reden dat het explodeerde is simpel: het benoemt de vier faalmodi waar elke werkende engineer het afgelopen jaar tegen zijn AI-assistent over heeft zitten vloeken, en het verpakt de fix als vier genoemde principes die Claude écht respecteert zodra ze in het contextvenster staan. Andrej Karpathy heeft de repo niet geschreven (die is van forrestchang), maar de principes zijn direct gedistilleerd uit Karpathy's publieke observaties op X over valkuilen bij LLM-coding — het beroemdst is zijn beschrijving van 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."

Dat ene citaat verklaart de hele repo. De intern is briljant. De intern is ook gevaarlijk zonder lijn.

De Karpathy CLAUDE.md skills plugin is die lijn.

Wat er daadwerkelijk in de repo zit

Voor de installatie moet je weten wat je binnenhaalt. Dit is de directory-indeling in de root:

.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 afleveringsmechanismen, dezelfde vier principes:

1. CLAUDE.md — het drop-in bestand voor Claude Code project-roots
2. .claude-plugin/plugin.json — het manifest voor Claude Code's plugin-marketplace-flow
3. skills/karpathy-guidelines/SKILL.md — de skill-formaat-versie compatibel met het skills.sh-ecosysteem dat ik eerder dit jaar behandelde
4. .cursor/rules/karpathy-guidelines.mdc — Cursor's equivalent, toegevoegd in de laatste paar commits

Het plugin-manifest is bewust piepklein. Hier is het woordelijk:

{
  "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"]
}

Eén versie, één skill-referentie, MIT-licentie. Geen dependencies. Geen post-install-scripts. Geen telemetrie. Dit is het soort repo dat ik vertrouw om te installeren zonder elke byte te lezen — maar ik heb toch elke byte gelezen, en jij zou dat ook moeten doen.

Nu het interessante deel. De vier principes zelf.

De vier principes, woordelijk uit de CLAUDE.md

Ik ga deze exact citeren zoals ze in het bronbestand staan, want parafraseren haalt er de scherpte af. De specificiteit is juist het punt.

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.

Faalmodus die dit voorkomt: stilzwijgende aannames. Het allerergste gedrag in AI-assisted coding. Je vraagt om "een user export endpoint" en krijgt een CSV-download terug die elk veld uit de database serveert, omdat het model besloot dat jij dat wilde. Zonder dit principe gokt Claude. Mét dit principe vraagt Claude of de export scoped moet zijn, welke velden gevoelig zijn, en of je JSON of CSV nodig hebt voordat er ook maar één regel wordt geschreven.

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.

Faalmodus die dit voorkomt: het strategy-pattern-voor-een-enkele-if-statement-probleem. Je vraagt om een kortingsberekening en krijgt een abstracte DiscountStrategyFactory terug met configureerbare afrondingsregels, een enum van promotietypen en een DiscountContext dataclass. Het echte probleem was price * 0.1. Dit principe is waarom mijn testprojecten van overdreven implementaties van 180 regels naar 30 regels zakten zonder een enkele echte feature te verliezen. Het is hetzelfde over-engineering-patroon dat ik aanstipte bij drie van de modellen in mijn AI-tool-roundup van april 2026 — bijna elk frontier-model bouwt met plezier een kathedraal als je om een schuurtje vroeg.

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.

Faalmodus die dit voorkomt: de drive-by refactor. Precies het gedrag dat mijn dinsdagochtend opvrat. Dit is het principe met de grootste voelbare impact. Met dit principe actief wordt de diff van 214 regels een diff van 1 regel, en vertelt Claude je aan het eind "I noticed the class has three unused imports from a refactor two commits ago — want me to address those separately?" in plaats van ze gewoon te verwijderen.

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

Faalmodus die dit voorkomt: de op-gevoel-gebaseerde "volgens mij is het klaar"-afronding. Karpathy's eigen framing hierop is de pittigste regel in de hele 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." Zodra dit principe geladen is, zegt Claude niet meer "I've added rate limiting, let me know if anything else" maar "Rate limiting added. Verification plan: (a) curl 10 requests under the limit and expect 200s, (b) curl 11 and expect a 429 on the last, (c) run the existing test suite. Running now."

Die vier bullets zijn het hele framework. Al het andere in deze post gaat over hoe je ze geladen krijgt, hoe je ze geladen houdt, en hoe je weet dat ze werken.

De drie installatiepaden — en welke je écht wilt

De repo biedt drie installatiepaden omdat er drie verschillende contexten zijn waarin je deze principes actief zou willen hebben. Ik heb alle drie getest. Elk heeft een specifiek toepassingsgebied, en ze door elkaar halen verspilt tokens en veroorzaakt regelbotsingen.

Pad A — De Claude Code plugin-installatie

Dit is het schoonste pad als je de richtlijnen beschikbaar wilt hebben in elke Claude Code-sessie op je machine, onafhankelijk van enig project. Twee commando's:

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

Dat zijn slash-commands die je in Claude Code zelf plakt, geen bash. De eerste voegt de repo toe als plugin-marketplace-bron. De tweede installeert de plugin, die het skills/karpathy-guidelines/SKILL.md-bestand registreert als een beschikbare skill. Claude zal het automatisch laden wanneer de sessie overeenkomt met de activation description van de skill.

Waar de bestanden daadwerkelijk terechtkomen: Claude Code slaat geïnstalleerde plugins op onder ~/.claude/plugins/andrej-karpathy-skills/. Het skill-manifest staat op ~/.claude/plugins/andrej-karpathy-skills/skills/karpathy-guidelines/SKILL.md. Je kunt het verifiëren met:

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

Wanneer gebruiken: je wilt de principes globaal actief, over elke repo, zonder projectbestanden aan te raken. Het beste voor solo-ontwikkelaars op machines waar jij de enige gebruiker bent.

Wanneer overslaan: je zit op een team-codebase. Skill-level loading is per gebruiker, dus je teamgenoten krijgen niet hetzelfde gedrag. Voor team-consistentie wil je Pad B.

Pad B — De project-root CLAUDE.md drop-in (of merge)

Dit is het pad dat ik in elk echt klantproject gebruik. De richtlijnen leven in de repo, worden met de code meeversion-controlled, en elke teamgenoot die Claude Code op die checkout draait krijgt automatisch hetzelfde gedrag.

Als het project nog geen CLAUDE.md heeft, is het één commando:

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

Commit het. Klaar. De volgende claude-sessie in die directory laadt de vier principes in de system-context voordat je eerste bericht komt.

Als het project al een CLAUDE.md heeft — wat waarschijnlijk zo is — overschrijf het dan niet. Ik deed dit één keer op de ai-agents-team repo (die achter deze blog) en was zo'n negentig seconden lang mijn volledige content-generation-configuratie kwijt voordat ik doorhad wat er gebeurd was en het uit git terughaalde. Wees niet zoals ik.

Merge in plaats daarvan. Hier is de exacte workflow die ik nu gebruik:

# 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

De regel over sectievolgorde is belangrijk. Claude behandelt eerdere regels in CLAUDE.md als hogere prioriteit wanneer regels conflicteren. Je wilt projectspecifiek gedrag (je content-templates, je Laravel-conventies, je deployment-regels) bovenaan, en de Karpathy-principes als een algemene coding-behavior-sectie lager in het bestand. Het zijn meta-regels over hoe Claude code moet benaderen — geen domeinregels over wat Claude moet bouwen — dus horen ze achterin het bestand, niet vooraan.

Wanneer gebruiken: elke team-codebase, elk project waar je langetermijn om geeft, elke repo waar je version-controlled agent-gedrag wilt.

Pad C — De Cursor-installatie

Als je Cursor gebruikt in plaats van Claude Code, levert de repo een .cursor/rules/karpathy-guidelines.mdc-bestand dat werkt met Cursor's rules-systeem. Installeer door het bestand in je project te kopiëren:

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

Cursor's rules-engine laadt automatisch elk .mdc-bestand in .cursor/rules/ bij het openen van een project, dus dit activeert bij de volgende sessie. De inhoud is dezelfde vier principes in Cursor's rule-formaat — een .mdc-bestand is gewoon markdown met een korte frontmatter-blok die aangeeft wanneer de regel moet gelden.

Wanneer gebruiken: je zit voornamelijk in Cursor. Ik draai nog steeds Claude Code voor agentisch werk, dus installeer ik beide — de bestanden botsen niet omdat ze in verschillende tool-specifieke directories staan.

Hoe verifieer je dat het daadwerkelijk actief is

Installeren is één ding. Weten dat het ook iets doet is iets anders. Elk skill/plugin-systeem dat ik heb gebruikt heeft een "is dat ding überhaupt geladen?"-probleem, en het antwoord is nooit om simpelweg het installatiebericht te vertrouwen.

Dit is mijn driestappen-verificatie die ik na elke installatie doorloop:

Stap 1 — Read-back-test. Open een verse Claude Code-sessie in het project en vraag:

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

Als de installatie werkte, noemt Claude de vier Karpathy-principes bij naam — Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution — en verwijst naar het CLAUDE.md-bestand of de plugin-skill als bron. Als het generieke "good coding practices" opsomt zonder de Karpathy-namen, is er iets mis: of het bestand is niet opgeslagen, of de plugin is niet geïnstalleerd, of je bevindt je in een directory die Claude niet als project-root herkent.

Stap 2 — Gedragstest. Geef het een taak die specifiek is ontworpen om het oude slechte gedrag uit te lokken:

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

Zonder de richtlijnen: uitdijende diff, ongevraagde refactor, stijlwijzigingen, de volledige dinsdagochtend-ervaring. Mét de richtlijnen: Claude zou precies moeten doen wat je vroeg, de minimale edit maken, en alles wat het verder opmerkt in een apart bericht flaggen in plaats van te shippen.

Stap 3 — Scope-creep-val. Dit is degene die het je echt vertelt.

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

Zonder de richtlijnen: Claude doet allebei, framet ze als één wijziging, en gooit er waarschijnlijk een refactor van de auth-middleware bovenop voor de goede zaak. Met Goal-Driven Execution actief zou Claude de taken moeten splitsen, succescriteria voor elk moeten stellen, en — dit is de tell — verificatiechecks voor de rate limit specifiek moeten voorstellen voordat de logging-taak wordt aangeraakt. Als het alles samenperst tot één grote ongeverifieerde wijziging, zijn de principes niet goed geladen.

Ik heb deze driestappentest bij elke installatie gedraaid. Het kost ongeveer vier minuten. Sla het over en je vertrouwt op de zelfrapportage van het model over of de vangrails overeind staan, en zelfrapportage is precies het ding waar deze principes voor ontworpen zijn om te wantrouwen.

Mergen met een bestaande setup (het echte-wereld-geval)

Alles hierboven gaat uit van een schone installatie. Het moeilijkere geval — en degene die de meeste engineers die ik ken echt tegenkomen — is het mergen van deze principes in een project dat al een eigenwijze CLAUDE.md met eigen regels heeft.

De repo van deze blog is een goed voorbeeld. Het ai-agents-team-project heeft een content-generation CLAUDE.md die Aria's stemregels definieert, merkconfiguraties, bestandsnaamconventies en een stapel harde constraints ("no AI filler phrases", "3,000+ words minimum", "no YAML frontmatter in posts"). Karpathy's principes gaan over coding-gedrag, niet content-gedrag, maar ik wilde ze toch geladen hebben voor wanneer Aria's werk overloopt in daadwerkelijke code — wanneer ik de repo vraag een agent-definitie te refactoren, een hook te updaten of een nieuw skill-bestand toe te voegen.

De structuur waar ik na een paar iteraties op uitkwam:

# 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>

De horizontale regel voor de coding-behavior-sectie is bewust. Het geeft Claude een visuele structurele aanwijzing dat de volgende sectie een andere zorg is — meta-regels over hoe je code schrijft, in tegenstelling tot domeinregels over wat het project doet. In mijn testen respecteert Claude deze scheiding: als ik content bewerk, volgt het de content-regels bovenaan; als ik code bewerk, trekt het de Karpathy-sectie erbij en past die toe.

Drie regels voor mergen zonder je bestaande setup te breken:

1. Projectspecifieke regels blijven bovenaan. Je merk-stem, je framework-keuzes, je bestandsnaamconventies, je lijst met verboden zinnen — dit zijn domeinregels en ze moeten elk conflict winnen. Zet ze boven de Karpathy-sectie.

2. Behoud de bronvermelding. Eén regel: Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT. Het is MIT-gelicenseerd dus je mag het vrij droppen, maar de vermelding is om twee redenen belangrijk: het laat toekomstige-jij weten waar de principes vandaan kwamen als ze ooit verkeerd voelen, en het signaleert aan Claude (dat dit soort dingen wél leest) dat deze sectie externe herkomst heeft.

3. Meng de principe-bewoording nooit met je projectregels. Als je Simplicity First wilt noemen binnen een projectspecifieke regel ("apply Simplicity First here — no speculative abstractions"), is dat prima. Wat niet prima is, is de principes parafraseren in je eigen projectsectie en de woordelijke bewoording laten vallen. De specificiteit van de originele bewoording is wat de principes laat werken, en ze in je eigen taal herformuleren blunt de scherpte die Claude nodig heeft om ze te herkennen.

Dit vervangt geen superpowers, skills of enige andere gedragssystemen die je al geladen hebt. Het vult ze aan. De Karpathy-principes zijn smal — ze bepalen hoe codewijzigingen worden gemaakt, niet wat het project is, niet welke tools worden gebruikt, niet wat je domeinconventies zijn. Gestapeld bovenop een sterke project-CLAUDE.md zijn ze netto een upgrade. Gestapeld in plaats van één, laten ze Claude zonder enige domeincontext en zul je het resultaat haten.

Een concreet voorbeeld uit mijn eigen stack: de pipeline van deze blog gebruikt de Claude programmatische SEO skill die ik eerder bouwde voor geautomatiseerde on-page optimalisatie. Die skill staat boven de Karpathy-sectie in mijn CLAUDE.md omdat het een domeinregel is — het definieert wat er wordt geschreven. De Karpathy-principes zitten eronder omdat het meta-regels zijn — ze definiëren hoe de code achter die skill wordt bewerkt als ik hem refactor. Gescheiden zorgen, gescheiden secties, geen botsingen.

Mijn eigenwijze kijk — waar dit wint, waar niet

Ik bespaar je de diplomatieke versie. Hier is het rechttoe-rechtaan oordeel na een week gebruik:

Waar dit wint — en het wint groot: de exacte vier faalmodi die AI-assisted coding het afgelopen jaar van "fantastisch" naar "frustrerend" veranderden. Stilzwijgende aannames. Over-engineering. Drive-by refactors. Op-gevoel-gebaseerd "ik denk dat ik klaar ben." Alle vier komen meetbaar minder vaak voor in mijn sessies. Het dinsdagochtend-incident met de 214-regelige null-check is niet meer teruggekomen sinds ik het installeerde. Mijn gemiddelde diff-grootte voor kleine bugfix-taken zakte merkbaar — het consistente patroon in de drie projecten is iets als een derde van het aantal regels voor dezelfde taak, zonder verlies aan correctheid.

Het Goal-Driven Execution-principe is de sleeper. Het klinkt als het saaie van de vier, maar het is degene die je workflow het meest verandert. Zodra Claude begint vooraf verificatiecriteria te stellen, stop je met prompts schrijven als "add validation" en begin je met prompts als "add validation for empty emails — success = test case X passes." Die verschuiving alleen al maakte me een meetbaar betere prompter, wat een raar neveneffect is om te krijgen van iemand anders z'n markdown-bestand installeren.

Waar dit beperkt is: vier principes zijn geen vervanging voor domeinkennis. Claude mét de Karpathy-richtlijnen geladen weet nog steeds niet dat jouw Laravel-codebase form requests gebruikt in plaats van inline-validatie, of dat je React-project overal server components gebruikt, of dat je API in dit ene endpoint snake_case teruggeeft om legacy-redenen. De principes voorkomen dat Claude dingen erger maakt — ze maken Claude niet slimmer over jouw specifieke stack. Je hebt nog steeds een projectspecifieke CLAUDE.md nodig. Je hebt nog steeds skills nodig. Je hebt nog steeds goede prompts nodig.

Waar het me actief irriteert: voor triviale taken voegen de principes wrijving toe. Claude vragen om een variabele te hernoemen levert me nu af en toe een drie-regelige bevestiging over scope op voordat de rename gebeurt. De richtlijnen erkennen dit zelf ("the guidelines bias toward caution over speed — useful for non-trivial work while maintaining judgment for simple tasks"), maar in de praktijk maakt het model niet altijd onderscheid. Ik heb een persoonlijke gewoonte ontwikkeld om "single trivial change, no verification needed" toe te voegen aan prompts waarvan ik weet dat de scope twee karakters is. Dat werkt. Maar het is een workaround, geen fix.

Installeren als: je echte code voor echte projecten schrijft, dagelijks met AI-coding-assistenten werkt, en in de laatste maand bent gebeten door scope creep, stilzwijgende aannames of drive-by refactors. De lat voor waarde hier ligt laag genoeg dat iedereen die productiecode shipt dit eigenlijk al geïnstalleerd zou moeten hebben.

Overslaan als: je Claude Code puur gebruikt voor wegwerp-prototyping, spike-werk of vibe coding waarbij snelheid belangrijker is dan scope-discipline. De richtlijnen zitten je in de weg. Ze zijn niet ontworpen voor de modus die Karpathy zelf beschreef als "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Ze zijn ontworpen voor de modus die hij later beschreef — die waarin je "slow, defensive, careful, paranoid" bent over code waar je echt om geeft.

Voor de pipeline van deze blog en elk klantproject dat ik op dit moment ship, staan ze erin. Voor weekend-experimenten staan ze eruit. Dat is de eerlijke splitsing.

Voor en na — de null-check herbekeken

Laat ik de lus sluiten die ik aan het begin van deze post opende.

Ik draaide de dinsdagochtend-taak opnieuw na het installeren van de richtlijnen. Dezelfde codebase, hetzelfde bestand, dezelfde regel, dezelfde 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."

Voor de richtlijnen (representatief voor wat er de eerste keer gebeurde):

• Diff van 214 regels
• Nieuwe class-constante DEFAULT_AVATAR
• Methode hernoemd van getAvatar() naar resolveAvatar() voor "duidelijkheid"
• Vier ongerelateerde null-coalesce-fixes in methoden die ik niet had genoemd
• Een blokcommentaar dat uitlegde waarom de aanpak van de oorspronkelijke auteur suboptimaal was
• De daadwerkelijke null-check-fix, correct, op regel 138, omringd door al het bovenstaande

Na de richtlijnen (opnieuw gedraaid op een verse branch vanuit dezelfde startstaat):

• Diff van 1 regel
• $user->profile?->avatar ?? asset('images/default-avatar.png') op regel 138
• Een apart bericht aan het eind: "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?"

Eén-regelige fix. Expliciete signalering van het aangrenzende probleem. Geen stilzwijgend geshipte refactor. Het model zag de aangrenzende problemen nog steeds — dat is dezelfde intelligentie — maar de richtlijnen converteerden het antwoord van "let me just handle it all" naar "let me flag it and let you decide."

Dat is de hele waardepropositie in één voor-en-na. Het model wordt niet dommer. Het wordt gedisciplineerd.

Er is een reden dat de repo in minder dan een maand de 71k sterren passeerde. Elke werkende engineer heeft een versie van dat dinsdagochtend-verhaal, en ieder van ons heeft willen stoppen zonder systeem-prompts van 50 regels te schrijven die in onze eigen woorden proberen uit te leggen wat "don't drive-by refactor" betekent. De Karpathy-principes doen het in vier genoemde secties, met bewoordingen scherp genoeg dat Claude ze ook echt volgt, voor de prijs van één enkel curl-commando. Die deal neem ik elke keer.

Nu is de enige vraag die het stellen waard is de vraag die je jezelf zou moeten stellen terwijl je dit tabblad sluit: wanneer heeft je AI-assistent voor het laatst een wijziging gemaakt die drie keer groter was dan wat je had gevraagd? Als het antwoord "deze week" is, weet je al wat je nu moet doen.

Veelgestelde vragen

Wat is de Karpathy CLAUDE.md skills plugin?

De Karpathy CLAUDE.md skills plugin is een enkel CLAUDE.md-bestand (plus een plugin-manifest, een skill-directory en een Cursor-rules-map) dat vier coding-behavior-principes in Claude Code laadt, gedistilleerd uit Andrej Karpathy's publieke observaties over valkuilen bij LLM-coding. Het is MIT-gelicenseerd, te vinden op github.com/forrestchang/andrej-karpathy-skills en bereikte 71,5k sterren puur op mond-tot-mondreclame.

Wat zijn de vier Karpathy-principes voor Claude Code?

De vier principes zijn Think Before Coding (aannames expliciet maken, vragen bij twijfel), Simplicity First (minimum code dat het probleem oplost, geen speculatieve features), Surgical Changes (raak alleen aan wat je moet aanraken, geen drive-by refactors) en Goal-Driven Execution (definieer verifieerbare succescriteria, loop tot verificatie). Zie de woordelijke uitsplitsing hierboven voor de volledige bullet-lijsten.

Hoe installeer ik de Karpathy CLAUDE.md in een bestaand project?

Draai curl -o .karpathy-skills-temp.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md en voeg het dan toe aan je bestaande CLAUDE.md als een nieuwe "Coding Behavior"-sectie onderaan. Overschrijf nooit een bestaande CLAUDE.md — projectspecifieke regels moeten boven de Karpathy-sectie blijven zodat ze elk conflict winnen. De volledige merge-workflow is hierboven gedocumenteerd.

Vervangt dit Claude Code skills of superpowers?

Nee. De Karpathy-principes zijn meta-regels over hoe codewijzigingen worden gemaakt — ze kennen je stack, je conventies of je domein niet. Stapel ze bovenop je bestaande project-CLAUDE.md, skills en andere gedragssystemen. Ze vullen aan, ze vervangen niet. Als je dit als je enige configuratie installeert, is Claude gedisciplineerd maar domein-blind.

Hoe verifieer ik dat de Karpathy-principes daadwerkelijk geladen zijn?

Draai een driestappencheck: (1) vraag Claude om de coding-behavior-principes in zijn context op te sommen en bevestig dat alle vier de Karpathy-namen verschijnen, (2) geef het een kleine bugfix-taak en controleer dat de diff chirurgisch blijft, (3) geef het een scope-creep-val ("fix X, while you're there also do Y") en bevestig dat het de taken splitst met verificatiecriteria in plaats van ze samen te persen. Als een stap faalt, is de installatie niet aangeslagen.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk-builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security-diensten): xcybersecurity.io