Andrej Karpathy-skills: vier regels tegen AI-code die te veel doet

Vraag een AI-codeerassistent om een knop blauw te maken, en de kans is reëel dat je een diff terugkrijgt met een nieuwe componentstructuur, een CSS-refactor en twee helperfuncties waar niemand om vroeg. Andrej Karpathy beschreef dat gedrag in januari 2026 op X. Forrest Chang maakte er vier gedragsregels van en zette ze op GitHub als andrej-karpathy-skills. Wat staat erin, wat lost het op en waar houdt het op?

Wat is andrej-karpathy-skills?

andrej-karpathy-skills is geen softwarebibliotheek, geen framework en geen AI-model. Karpathy heeft het ook niet zelf geschreven. Het is in de kern één instructiebestand, CLAUDE.md, met vier gedragsregels voor AI-codeerassistenten, afgeleid uit Karpathy's kritiek op hoe taalmodellen code schrijven.

De repository levert dezelfde regels in drie vormen: als plugin voor Claude Code, als los CLAUDE.md-bestand voor in je project en als regelbestand voor Cursor. De licentie is MIT.

Waarom Karpathy's naam gewicht heeft: hij was een van de oprichters van OpenAI en leidde van 2017 tot 2022 het computer-visionteam van Tesla Autopilot. In zijn bericht van 26 januari 2026 beschreef hij zijn eigen omslag. In november deed hij nog zo'n 80 procent van zijn programmeerwerk zelf (met autocomplete) en 20 procent met agents. Toen hij het schreef, was dat omgedraaid: 80 procent agents, 20 procent bijwerken en afwerken.

Welke fouten Karpathy zag

Zijn klachten over AI-agents die code schrijven komen neer op drie dingen.

Stille aannames. Volgens Karpathy maken de modellen namens jou verkeerde aannames en gaan ze daar zonder controle mee verder. Ze vragen niet om verduidelijking, benoemen geen tegenstrijdigheden, leggen geen afwegingen voor en spreken je niet tegen als dat nodig is. Een herkenbaar voorbeeld:

Vraag:
"Voeg authenticatie toe"

AI:
- kiest zelf JWT
- maakt middleware
- bouwt refresh tokens
- verandert de databasestructuur

Zonder eerst te vragen wat je eigenlijk bedoelde.

Te veel code. Modellen maken code en API's graag ingewikkelder dan nodig, stapelen abstracties en ruimen dode code niet op. Karpathy's voorbeeld: een opgeblazen constructie van duizend regels waar honderd hadden volstaan.

Bijschade. Ze wijzigen of verwijderen soms commentaar en code die ze niet goed begrijpen, ook als dat niets met de taak te maken heeft.

Daar tegenover zette hij één sterk punt: taalmodellen zijn goed in blijven proberen tot een concreet doel gehaald is. Zijn advies: vertel het model niet wat het moet doen, geef het succescriteria en kijk wat het ermee doet.

De vier regels

De vier regels in het bestand zijn een vrij directe vertaling van die klachten.

1. Think Before Coding: eerst de aannames op tafel

De assistent moet zijn aannames uitspreken. Kan een vraag op meerdere manieren worden gelezen, dan legt hij de opties voor in plaats van er stilletjes één te kiezen. Is iets onduidelijk, dan stopt hij en vraagt hij het.

Slecht:

User:
"Maak een loginsysteem"

AI:
- maakt JWT
- gebruikt Redis
- bouwt OAuth
- zet een complete auth-structuur neer

Goed:

AI:
"Wil je:
- een simpele sessie-login?
- JWT-authenticatie voor een API?
- social login?
- Laravel Breeze of Fortify?"

2. Simplicity First: de kleinste oplossing die werkt

Geen functies buiten de vraag, geen abstracties voor code die maar één keer wordt gebruikt, geen configureerbaarheid waar niemand om vroeg. Het bestand geeft er een toetsvraag bij: zou een senior engineer dit overgecompliceerd vinden? En een vuistregel: schrijf je tweehonderd regels terwijl het er vijftig hadden kunnen zijn, herschrijf het dan.

Slecht:
- service layer
- repository
- adapter
- factory
- interface
  ... voor één berekening

Goed:
- één functie
- duidelijke naam
- werkt direct

3. Surgical Changes: alleen aanraken wat nodig is

Misschien wel de belangrijkste regel. De assistent past alleen aan wat voor de opdracht nodig is: geen ongevraagde refactors, geen herformattering, geen "verbeteringen" aan code ernaast. Hij volgt de bestaande stijl, ook als hij het zelf anders zou doen. Dode code die hij tegenkomt noemt hij, maar hij verwijdert die niet. Wat door zijn eigen wijziging overbodig wordt (een import, een variabele) ruimt hij wel op.

De toets uit het bestand: elke gewijzigde regel moet terug te voeren zijn op het verzoek.

Vraag: "Voeg een veld voor telefoonnummer toe"

Te veel:
- hele formuliercomponent herschreven
- nieuwe validatielaag
- nieuwe UI-bibliotheek

Genoeg:
+ invoerveld
+ databasemigratie
+ validatieregel

4. Goal-Driven Execution: werk naar een controleerbaar doel

Hier zit Karpathy's positieve punt. Een vage opdracht wordt een doel dat je kunt controleren. "Fix de bug" wordt "schrijf een test die de bug reproduceert en zorg dat hij slaagt". "Voeg validatie toe" wordt "schrijf tests voor ongeldige invoer en laat ze slagen". Bij een taak van meerdere stappen hoort bij elke stap een controle.

Succescriteria:
- gebruiker kan inloggen
- sessie blijft bestaan na herladen
- uitloggen werkt
- tests slagen

Met zulke criteria kan de assistent zelf doorwerken tot het klopt. Met "zorg dat het werkt" blijft hij bij jou terugkomen.

Waarom een instructiebestand geen garantie is

Een CLAUDE.md is een verzoek, geen slot op de deur. Anthropic schrijft in de documentatie van Claude Code dat Claude zulke bestanden als context behandelt, niet als afgedwongen configuratie. Wie iets echt wil blokkeren, gebruikt een hook: een script dat Claude Code op een vast moment uitvoert en dat een actie kan tegenhouden. De documentatie waarschuwt ook dat een te lang instructiebestand averechts werkt: regels raken dan ondergesneeuwd. Vier korte regels passen daar goed bij.

De regels hebben ook een prijs, en de repository zegt dat zelf: ze kiezen voor voorzichtigheid boven snelheid. Bij een typfout of een wijziging van één regel hoef je geen vragenronde. En omdat de assistent gevonden dode code alleen noemt, blijft die liggen tot jij vraagt om op te ruimen. Dat is een bewuste keuze: liever een kleine diff die je kunt nalezen dan een grote die je moet vertrouwen.

Regel 4 werkt alleen als er iets te controleren valt. Heeft je project geen tests, dan is "tests slagen" geen succescriterium maar een wens.

Zijn dit eigenlijk skills?

Niet helemaal. In Claude Code is een skill een map in .claude/skills/ met een SKILL.md-bestand. Claude laadt die alleen als hij relevant is, terwijl CLAUDE.md in elke sessie wordt geladen. OpenAI gebruikt het woord ook: skills in ChatGPT zijn herbruikbare, deelbare workflows die instructies, voorbeelden en code kunnen bevatten, beschikbaar voor Business-, Enterprise- en Edu-accounts.

De Karpathy-regels zijn geen taakgerichte workflow maar algemene gedragsregels die altijd gelden. Ze horen dus eerder in CLAUDE.md. De naam "skills" is vooral verpakking; de pluginversie voor Claude Code levert ze wel als skill.

Zelf proberen

Zet de vier regels in de CLAUDE.md van een project waar je al met een AI-assistent werkt en let bij de volgende diff op één ding: is elke gewijzigde regel terug te voeren op wat je vroeg? Dat is ook meteen waarom ik deze kleine repository interessant vind. De beste AI-assistent is niet de assistent die het meeste doet, maar de assistent die precies doet wat nodig is en niets meer.