AIDiveSupprimé, mesuré, une règle a cassé
Supprimer un CLAUDE.md, c'est retirer le fichier d'instructions que Claude Code lit au début de chaque conversation. Boris Cherny, le créateur de Claude Code, a dit sur scène de le supprimer tous les six mois. Vingt-deux vidéos l'ont répété en sept semaines. Aucune n'a ouvert de dépôt.
Cet article fait ce que les vidéos n'ont pas fait : il prend une vraie application avec un CLAUDE.md de 177 lignes, trois skills, quatre commandes et un hook, lance cinq tâches du quotidien avec et sans le fichier, et compte. Quarante-quatre runs plus tard, exactement une règle a cassé. Le fichier a coûté des tokens sur chaque tâche, jamais le même montant, et une de ses lignes, personne ne pouvait la suivre.
Le clip, mot pour mot, et les deux lignes qui ne sont pas de lui
Le clip vient de la conférence de Boris Cherny au YC Startup School, enregistrée le lendemain de la sortie d'Opus 5. Ses mots : tous les six mois, supprimez votre CLAUDE.md, supprimez vos skills, supprimez vos hooks. Regardez ce que fait le modèle, ça pourrait vous surprendre. Pour Opus 5, dit-il, Anthropic recommande vraiment d'essayer : le modèle n'a peut-être plus besoin de toutes ces instructions.
Trente secondes plus tôt vient la réserve que personne ne cite. Anthropic ne supprime pas toute la base de code. Ça en supprime beaucoup, et ça s'appelle une ablation. La transcription écrite porte cette ligne en entier aujourd'hui. Quatre-vingts pour cent du prompt système de Claude Code sont partis ainsi : tout supprimer, le ramener ligne par ligne, mesurer chaque ligne.
Deux phrases que les vidéos de réaction lui prêtent ne sont pas dans la conférence. « Contexte, objectifs et définition du fini » n'apparaît nulle part ; le plus proche qu'il dise est tâche, garde-fous, critères de sortie. « Soixante-quatre agents réécrivant Bun » n'est pas non plus son chiffre : c'est celui de Jarred Sumner, dans le billet Bun. Cherny parle de onze jours et, quand on lui demande un compte, avance des milliers.
Vingt-deux vidéos en sept semaines ont cité le clip. Aucune n'a fait le test. Donc celle-ci fait ce qu'il a réellement décrit : supprimer, ramener un élément à la fois, mesurer.
L'instrument : l'ablation, pas la suppression
Une ablation retire un élément d'une configuration à la fois et mesure l'effet, au lieu de tout supprimer et de deviner. Le CLAUDE.md est lu au début de chaque conversation et à nouveau à chaque tour ; les skills ne se chargent que lorsqu'on les invoque. Cette différence est ce qui a été mesuré.
Anthropic fournit l'interrupteur de suppression : un simple flag, la même variable que Cherny cite sur scène. Le dépôt est une vraie application à moi : 177 lignes d'instructions, trois skills, quatre commandes, et un hook qui se déclenche à chaque recherche.
| Dimension | Valeur |
|---|---|
| Tâches du quotidien | 5 (nouveau composant, édition, refactor, changement de store, question d'architecture) |
| Configurations | 5 (complet, sans fichier, sans skills, sans hook, rien) |
| Modèle | un seul, figé |
| Environnement | répertoire de config vide, clone neuf avant chaque run |
| Runs | 44 |
| Coût | 39 $ |
Chaque run a été noté de la même façon, sur le même clone, par un script plutôt qu'à la main. Ce qui compte comme cassé : les propres règles du dépôt (imports, types, design tokens, traductions) plus le typecheck et le lint.
Le seul outil conçu pour ce genre d'ablation, Caliper, retire des skills et des serveurs MCP mais ne touche jamais au fichier ; le retrait du CLAUDE.md a été fait à la main. Les limites, énoncées une fois : un dépôt, un modèle, deux runs par cellule, pas de transcript. Le premier résultat a donné le ton : la tâche de refactor est revenue identique, soixante-quatre cents avec le fichier et soixante-trois sans.
Ce qui a cassé : une règle, sur les nouveaux fichiers
La règle qui a cassé est une règle d'internationalisation, dans les mots du fichier lui-même : toujours ajouter l'anglais et le français, jamais coder en dur une chaîne visible par l'utilisateur. Sur la tâche du nouveau composant, avec le fichier, les quatre runs ont écrit le fichier de traduction. Sans lui, trois runs sur quatre ont codé le titre en dur. Même tâche, même dépôt, même modèle, même prompt.
| Nouveau composant | A écrit le fichier de traduction |
|---|---|
| Avec CLAUDE.md | 4 sur 4 |
| Sans CLAUDE.md | 1 sur 4 |
La tâche d'édition raconte l'autre moitié. Toutes les configurations ont réussi, même sans rien, parce que les voisins l'enseignent : chaque composant à côté de celui édité a déjà un fichier de traduction. Tout le reste a tenu dans les quarante-quatre runs : l'alias d'import, type plutôt qu'interface, les design tokens, le pattern du store. Le code montre ces règles ; le fichier les répète.
Une étude de l'ETH Zurich a mesuré la même chose sur 138 vrais tickets. Son résultat : les fichiers de contexte n'améliorent pas le taux de réussite et coûtent environ vingt pour cent de plus, et le modèle suit bien les instructions. Une réserve : un run sans le fichier a quand même écrit le fichier de traduction. La règle n'est pas impossible sans le fichier, elle est juste peu fiable. Une règle a cassé, celle que le code ne pouvait pas enseigner. Et le run qui a sauté ce travail était aussi le moins cher.
Ce que le fichier a coûté, tâche par tâche
Le coût en tokens d'un CLAUDE.md est la différence de tokens lus entre un run avec le fichier et le même run sans lui.
| Tâche | Tokens lus en moins sans le fichier |
|---|---|
| Nouveau composant | 61 % |
| Édition | 15 % |
| Refactor | 5 % |
| Changement de store | 4 % |
| Question d'architecture | 14 % |
| Sur les dix runs | 32 % de tokens, 22 % d'argent |
Trente-deux pour cent, c'est le chiffre que toute vidéo mettrait en titre, et c'est le mauvais. La plus grosse économie vient du run qui n'a pas écrit le fichier de traduction : moins cher parce qu'il a fait moins. Là où le résultat était identique, le fichier a coûté de quatre à quatorze pour cent. C'est son vrai prix, et les vingt pour cent de l'étude tombent pile entre ces deux chiffres.
Le mécanisme fait environ 1 800 tokens, relus à chaque tour. Les skills, le hook et le knowledge graph n'ont rien produit de mesurable, présents ou absents. Le bruit est plus grand que la plupart de ces effets : la même tâche avec le même fichier a coûté 2,11 $ sur un run et 1,33 $ sur l'autre. Deux runs ont atteint le plafond de tours, un avec le fichier et un sans. Donc le fichier coûte un peu partout et ne se justifie qu'une fois, sauf s'il ment aussi.
Les lignes qui mentaient
Une ligne qui ment est une instruction que le modèle ne peut pas suivre ou qui ne change rien. La ligne évoquée en introduction : importer le thème depuis l'alias design-tokens. L'alias n'existe pas : la config TypeScript ne mappe qu'un préfixe, et le dossier des tokens n'a pas de fichier theme. Chaque run, avec le fichier ou sans, a fait ce que font les voisins, la même ligne d'import quarante-quatre fois.
Le fichier contient quatre-vingt-deux lignes de vue d'ensemble d'architecture. Même question, six réponses : les six ont trouvé les mêmes neuf fichiers, du backend à l'écran, dans le même ordre, avec la vue d'ensemble et sans. Un bloc pointe vers un knowledge graph que le clone n'a pas. Avec le graphe présent, la question coûtait pareil.
| Mesure | Valeur |
|---|---|
| Règle de taille d'Anthropic | moins de 200 lignes |
| Ce fichier | 177 lignes |
| Fichier médian du jeu de données reporails, 30 000 dépôts | 50 éléments, 12 directives |
| Lignes de directive dans ce fichier | 24 sur 177 |
La position décide laquelle de deux règles contradictoires l'emporte, et le modèle ne le dit jamais, environ quatre-vingt-dix points dans le test d'un éditeur. La vue d'ensemble pourrait aider une tâche non testée ici : une sonde, une réponse. Trois types de lignes, donc : celle qui a mérité sa place, celles que le code enseigne, celles qui mentent.
Garder, déplacer, supprimer : la liste courte
Trois piles, et la mesure derrière chacune.
| Pile | Ce qui y va | Mesure |
|---|---|---|
| Garder | La règle que le code ne peut pas montrer | 6 lignes qui ont sauvé 4 runs |
| Déplacer | La vue d'ensemble d'architecture et les commandes | 107 lignes sans gain mesuré |
| Supprimer | Les lignes qui mentent, et les lignes que l'arborescence montre déjà | 44 runs identiques |
Garder ce que le modèle a raté deux fois : c'est le propre critère d'Anthropic pour le fichier. Déplacer la vue d'ensemble et les commandes dans une arborescence de fichiers chargés au besoin ; le billet de juillet d'Anthropic qualifie le dépôt central de mythe. Les hooks restent : un garde-fou n'expire pas quand le modèle s'améliore. Couper la prose dépassée, garder le garde-fou.
Le fichier après : environ soixante-dix lignes, les six qui l'ont mérité en plus. C'est la méthode de Cherny, lue en entier : supprimer, ramener ligne par ligne, mesurer. Un dépôt, un modèle, deux runs par cellule ; vos piles seront différentes, la méthode non. Supprimer a coûté une règle et économisé peu. Trouver les lignes qui mentent, c'était ça la victoire.
