Andrej Karpathy (l’ancien director of AI chez Tesla, founder de Andrej Karpathy) a un fichier CLAUDE.md qu’il utilise avec Claude Code. Et ouais, c’est un peu le guru reference pour tout ce qui est AI coding.
Le fichier
C’est des “behavioral guidelines to reduce common LLM coding mistakes”. Le tradeoff : ces guidelines bias vers la prudence plutôt que la vitesse.
Les 4 règles
1. Think Before Coding
Don’t assume. Don’t hide confusion. Surface tradeoffs.
Avant d’implémenter :
- State tes assumptions explicitement. Si incertain, demande.
- Si plusieurs interprétations existent, présente-les — pas silencieusement choisir.
- Si une approche plus simple existe, dis-le. Push back quand justifié.
- Si quelque chose est unclear, stop. Nommer ce qui est confus. Demande.
2. Simplicity First
Minimum code that solves the problem. Nothing speculative.
- Pas de features au-delà de ce qui était demandé
- Pas d’abstractions pour du code single-use
- Pas de “flexibilité” ou “configurability” non demandée
- Pas de error handling pour des scénarios impossibles
- Si tu écris 200 lignes et que 50 suffiraient, rewrite
La question à se poser : “Est-ce qu’un senior engineer dirait que c’est overcomplicated ?” Si oui, simplify.
3. Surgical Changes
Touch only what you must. Clean up only your own mess.
Quand tu édites du code existant :
- Pas de “improvements” sur du code adjacent, comments, ou formatting
- Pas de refactor de choses qui marchent
- Match le style existant, même si tu ferais différemment
- Si tu remarques du dead code non lié, mentionne-le — pas le supprimer
Le test : Every changed line should trace directly to the user’s request.
4. Goal-Driven Execution
Define success criteria. Loop until verified.
Transformer les tâches en goals vérifiables :
- “Add validation” → “Write tests for invalid inputs, then make them pass”
- “Fix the bug” → “Write a test that reproduces it, then make it pass”
- “Refactor X” → “Ensure tests pass before and after”
Pour les tâches multi-steps, state un brief plan :
1. [Step] → verify: [check]2. [Step] → verify: [check]3. [Step] → verify: [check]Le trick
Ces guidelines marchent si :
- Fewer unnecessary changes in diffs
- Fewer rewrites due to overcomplication
- Clarifying questions come before implementation rather than after mistakes
Le fichier est sur GitHub : forrestchang/andrej-karpathy-skills
Source : GitHub