225,000 étoiles pour un Markdown : Karpathy en quatre règles

Un dépôt qui ne contient qu'un seul fichier Markdown affiche 225,000 étoiles. Il en a gagné environ 4,000 cette semaine. Pas de code, pas d'étape de build, pas de release, pas de tableau de benchmarks : quatre principes et une série d'instructions sur la façon dont un modèle de langage doit se comporter lorsqu'on lui demande de modifier une base de code.

Le fichier s'appelle CLAUDE.md, dans un dépôt nommé andrej-karpathy-skills, maintenu par forrestchang. Il compresse une série de reproches formulés par Andrej Karpathy sur le comportement des LLM en matière de code, sous une forme qu'un agent lira réellement au début de chaque session. Le nombre d'étoiles est le point de données intéressant, pas le contenu, parce qu'il dit quelque chose de la manière dont le comportement des agents est aujourd'hui corrigé : officieusement, en prose, par des individus.

Les reproches, dans les mots de Karpathy

Trois citations du texte d'origine sur lequel le dépôt est bâti :

« Les modèles font de mauvaises hypothèses à votre place et les suivent sans jamais vérifier. Ils ne gèrent pas leur confusion, ne demandent pas de précisions, ne signalent pas les incohérences, n'exposent pas les compromis, ne contestent pas quand ils le devraient. »

« Ils adorent compliquer le code et les API, gonfler les abstractions, ne nettoient pas le code mort… ils livrent une construction boursouflée de plus de 1,000 lignes là où 100 suffiraient. »

« Ils modifient ou suppriment encore parfois, comme effet de bord, des commentaires et du code qu'ils ne comprennent pas assez, même quand c'est orthogonal à la tâche. »

Quiconque a livré du code écrit par un agent reconnaît les trois. Le deuxième est le plus courant : demandez une fonction de validation, vous recevez une classe de base abstraite, un pattern stratégie, un objet de configuration et quarante lignes de gestion d'erreurs pour des états qui ne peuvent pas se produire.

Ce que disent vraiment les quatre principes

Réfléchir avant de coder. Énoncer explicitement les hypothèses, présenter plusieurs interprétations au lieu d'en choisir une en silence, contester quand une approche plus simple existe, s'arrêter en cas de confusion et nommer ce qui n'est pas clair.

La simplicité d'abord. Le minimum de code qui résout le problème. Aucune fonctionnalité au-delà de la demande, aucune abstraction pour du code à usage unique, aucune configurabilité que personne n'a demandée, aucune gestion d'erreur pour des scénarios impossibles. Le test : un ingénieur senior jugerait-il cela trop compliqué ?

Des modifications chirurgicales. Ne toucher que ce qu'il faut. Ne pas améliorer le code adjacent, ne pas reformater ce que l'on traverse. S'aligner sur le style existant même si l'on ferait autrement. Si l'on repère du code mort sans rapport, le mentionner — ne pas le supprimer. Si vos changements créent des orphelins, ne nettoyer que ceux-là. Le test : chaque ligne modifiée se rattache à la demande.

Une exécution pilotée par l'objectif. Convertir les instructions impératives en critères de réussite vérifiables. Non pas « ajouter une validation » mais « écrire des tests pour les entrées invalides, puis les faire passer ». Non pas « corriger le bug » mais « écrire un test qui le reproduit, puis le faire passer ».

Ce dernier est le seul principe qui ne soit pas une contrainte. C'est un levier, et il s'accompagne de la meilleure phrase du texte source : les LLM sont exceptionnellement doués pour boucler jusqu'à atteindre un objectif précis. Ne lui dites pas quoi faire ; donnez-lui des critères de réussite et regardez-le partir.

L'installation, et le fait qu'elle tienne en deux lignes

Deux voies, toutes deux triviales.

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

Ou, projet par projet :

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

Une règle Cursor est également versionnée dans .cursor/rules/karpathy-guidelines.mdc, de sorte que les mêmes consignes s'appliquent quand le projet s'ouvre dans Cursor. Licence MIT.

L'histoire de la distribution, voilà l'essentiel. Il y a deux ans, corriger « les modèles suringénierisent » aurait supposé un fine-tuning, un prompt système livré par un éditeur, ou un framework. Aujourd'hui, c'est un fichier qu'un utilisateur dépose dans un dépôt, plus une entrée de marketplace qui l'installe dans tous les projets de la machine. La boucle de rétroaction entre la plainte et la correction est bien plus courte, et c'est pourquoi le compteur d'étoiles est ce qu'il est : le fichier est la plus petite unité possible de changement de comportement.

Pourquoi je reste sceptique face à ce cadrage

Trois réserves, formulées dans l'esprit du fichier lui-même.

Les principes ne sont pas des tests. « La simplicité d'abord » est une préférence, pas un critère. Un agent qui le lit produira quand même une solution de 300 lignes là où 80 suffiraient, parce que le modèle n'a aucun moyen de mesurer la complexité. Le seul principe du fichier qui fonctionne vraiment — l'exécution pilotée par l'objectif — fonctionne précisément parce qu'il remplace une préférence par une vérification : un test qui passe ou qui ne passe pas.

« Modifications chirurgicales » combat ce en quoi les agents sont bons. Si vous demandez une petite modification et qu'il en sort une petite modification, vous avez utilisé un outil coûteux pour économiser des frappes. La valeur d'un agent, c'est de pouvoir restructurer ce que vous ne vouliez pas toucher. La réponse du fichier : la restructuration doit être demandée, pas proposée spontanément. C'est raisonnable, mais cela signifie que les consignes optimisent pour un type d'utilisateur précis : celui qui a déjà une base de code et une opinion ferme sur les diffs.

Personne ne mesure si ça marche. Le dépôt liste des signaux : moins de changements inutiles dans les diffs, moins de réécritures, des questions de clarification avant l'implémentation plutôt qu'après. Ils sont réels et observables. Mais il n'y a pas de condition de contrôle. Vous installez un fichier qui dit « demandez avant de supposer », et l'agent se met à demander avant de supposer. Est-ce le fichier qui l'a provoqué, ou l'acte de l'écrire qui vous a fait remarquer un comportement déjà présent ?

L'auteur assume le compromis, ce qui lui fait honneur : les consignes penchent vers la prudence plutôt que vers la vitesse, et pour les tâches triviales il faut user de jugement. C'est la bonne mise en garde, et c'est aussi la tension. Un agent qui s'arrête pour poser une question sur une faute de frappe d'une ligne est pire qu'un agent qui la corrige.

La version que j'écrirais, moi

Si la faiblesse du fichier est que trois de ses quatre principes sont des préférences, le remède est de les convertir en vérifications. Concrètement, quatre lignes qui survivent au contact d'un vrai dépôt :

Avant d'éditer, listez les fichiers que vous comptez toucher, et arrêtez-vous si la liste est plus longue que la demande ne l'implique. Cela transforme « modifications chirurgicales » en garde-fou plutôt qu'en humeur.

Avant de terminer, lancez les tests et collez la sortie. C'est « exécution pilotée par l'objectif » rendue non négociable, et c'est l'instruction au plus fort levier que vous puissiez placer devant un agent.

Si une tâche admet plus d'une interprétation plausible, écrivez les deux et demandez laquelle. Cela convertit « réfléchir avant de coder » d'une aspiration en un tour de conversation.

Et un budget de diff : si la modification ajoute plus d'environ 150 lignes pour une correction de bug, arrêtez-vous et justifiez chaque abstraction. Brutal, mais cela attrape le mode de défaillance décrit par Karpathy, celui qui coûte réellement du temps.

Rien de tout cela n'est dans le fichier, et ce n'est pas nécessaire. Le rôle du fichier est de fixer une posture. Les vérifications sont le rôle de celui qui possède le dépôt.

Ce que dit vraiment le compteur d'étoiles

L'essentiel de l'outillage pour agents sorti cette année porte sur la capacité : contexte plus long, plus d'outils, exécution parallèle. Ce fichier porte sur la retenue, et il a attiré plus d'attention que la plupart des annonces de capacité.

Cet écart est instructif. Ceux qui paient pour ces outils ont conclu que le goulot d'étranglement n'est plus ce que le modèle sait faire, mais le fait de l'amener à cesser de faire ce qu'on ne lui a pas demandé. Un fichier Markdown à 225,000 étoiles est un signal inhabituellement clair sur l'endroit où se situe réellement la frustration.

C'est aussi un signal légèrement gênant pour les laboratoires. Le dépôt le plus étoilé de cette catégorie est une liste de quatre choses que les modèles devraient déjà faire.