Le 13 avril, abmedia avait rapporté que Forrest Chang avait transformé les plaintes de Karpathy de janvier concernant Claude en un ensemble de « 4 règles CLAUDE.md », ce qui avait alors accumulé 15 000 étoiles sur GitHub ; le 12 mai, le repo dépassait 126 000 étoiles, soit une croissance de 8 fois en moins d’un mois. La communauté a ensuite vu apparaître de nombreuses tentatives de « version étendue », et parmi elles, le billet de l’ingénieur Mnilax ( @Mnimiy ) du 9 mai, « en ajoutant 8 règles aux 4 de base, pour passer à une version complète de 12 règles », a obtenu 5 968 likes et figure parmi les contenus mono-post les plus discutés récemment dans la communauté Claude Code.
Rappel des 4 règles : Forrest Chang transforme les plaintes de Karpathy en modèles exécutables
Les 4 règles originales de Forrest Chang (chaque règle correspond à un mode d’échec que Karpathy avait pointé du doigt en janvier sur X) :
Think Before Coding（penser avant d’écrire） : ne pas faire d’hypothèses implicites, les formuler explicitement ; exposer les trade-off et les discuter ; en cas d’incertitude, demander directement, ne pas deviner ; s’opposer à des solutions complexes lorsqu’il existe une approche plus simple
Simplicity First（d’abord la simplicité） : écrire le code minimal qui résout le problème ; ne pas ajouter de fonctions spéculatives ; ne pas créer des couches d’abstraction pour du code jetable ; des ingénieurs seniors diraient que lorsque la conception devient trop complexe, il faut simplifier
Surgical Changes（modifications chirurgicales） : ne toucher qu’à ce qui doit être touché, ne pas « améliorer par la bande » du code adjacent, les commentaires, le format ; ne pas refactorer ce qui ne casse pas ; s’aligner sur le style existant
Goal-Driven Execution（exécution guidée par l’objectif） : définir les critères de réussite, itérer jusqu’à validation ; ne pas donner à Claude les étapes, mais lui dire à quoi ressemble un succès, afin qu’il boucle lui-même
La documentation officielle d’Anthropic est en réalité très claire : CLAUDE.md est un fichier « consultatif » (advisory), et Claude obéirait environ 80% du temps ; au-delà de 200 lignes, le taux de conformité chute fortement, car des règles importantes se retrouvent noyées dans le bruit. La proposition de Forrest Chang consiste à compresser les règles à 65 lignes, 4 règles, pour atteindre un « floor » (seuil minimal).
Les 8 règles ajoutées par Mnilax : combler de nouveaux modes d’échec à l’ère des agents de 2026/5
Mnilax soutient : les plaintes de Karpathy de janvier se concentraient sur le contexte « écrire du code avec Claude », mais l’écosystème Claude Code de mai a évolué vers une collaboration multi-agents, des enchaînements de hooks, des conflits de chargement de skills, et des workflows multi-étapes traversant des sessions multiples : il faut donc ajouter des règles. Voici les 8 règles qu’il a ajoutées (réorganisées dans l’ordre original du texte) :
Rule 5 : n’utiliser Claude que pour les tâches qui nécessitent du jugement (classification, rédaction, résumé, extraction), et pour les décisions déterministes (re-tenter 503, routage, traitement des status code, conversions déterministes), utiliser du code standard
Rule 6 : le token budget n’est pas une suggestion — plafond de 4 000 tokens par tâche et 30 000 tokens par session ; lorsqu’on approche du budget, résumer et redémarrer activement, ne pas dépasser silencieusement
Rule 7 : deux patterns de code en conflit doivent « pointer vers un choix » (prendre le plus récent, ou celui avec le plus de tests), expliquer pourquoi ce choix, et marquer l’autre comme à nettoyer ; mélanger les deux patterns est le pire choix
Rule 8 : avant d’écrire du code, il faut d’abord le comprendre — lire les exports, le caller direct, les utilitaires partagés ; « looks orthogonal » est la formulation la plus dangereuse, si vous n’êtes pas sûr, demandez
Rule 9 : les tests doivent valider « l’intention », pas seulement « le comportement » — un test qui échoue lorsque la logique métier change compte ; sinon, vous donnez seulement confiance à Claude, avec une protection réelle nulle
Rule 10 : pour les tâches multi-étapes, faire des checkpoints — à chaque étape terminée, résumer « ce qui a été fait, ce qui a été validé, ce qui reste » ; si vous ne pouvez pas décrire clairement l’état, ne continuez pas
Rule 11 : s’aligner sur les conventions du codebase existant, même si vous n’êtes pas d’accord — snake_case pour snake_case, class component pour class component ; si vous n’êtes pas d’accord, traiter cela comme un autre débat, ne pas bifurquer unilatéralement
Rule 12 : les échecs doivent être bruyants — « migration terminée » n’est pas vrai si vous sautez 30 entrées, « tests passés » n’est pas vrai si vous sautez n’importe quelle entrée ; par défaut, « révéler activement l’incertitude », ne pas « cacher l’incertitude »
Mnilax affirme avoir testé ces 12 règles sur 30 codebases en 6 semaines, déclarant que le taux d’erreur passe de 41% à 3%, et que le taux de conformité ne baisse que légèrement (78% → 76%). Observation de ce média : ces chiffres proviennent des résultats de tests auto-déclarés par l’auteur, non vérifiés de manière indépendante ; toutefois, le contenu des 8 règles est solide et correspond aux douleurs liées aux scénarios d’utilisation actuels de Claude Code multi-agents (par exemple, la gestion multi-sessions de l’Agent View, et le Multi-Agent Layer au sein d’une architecture en six couches).
Contextes d’application et recommandations pragmatiques
Mnilax indique aussi sans détour quelles approches ne devraient pas être tentées :
Plus de 14 règles : le taux de conformité tombe à 52% (chute brutale depuis 76%), et 200 lignes constituent une limite pratique réelle
Utiliser des exemples à la place des règles : le coût token de 3 exemples est équivalent à 10 règles, et Claude risque de sur-apprendre sur un exemple unique
Instructions abstraites comme « Be careful / think hard / really focus » : faible vérifiabilité, et conformité seulement de 30%
Dire à Claude « comme un ingénieur senior » : une instruction d’identité (identity prompt) ne modifie pas le comportement de façon efficace, tandis que les instructions structurées en règles sont efficaces
S’appuyer sur un outil spécifique : « utiliser toujours eslint » échoue silencieusement quand eslint n’est pas installé ; remplacer par des formulations neutres en termes de capacité, comme « s’aligner sur le style existant du codebase »
Méthode pragmatique recommandée par ce média : CLAUDE.md est un « contrat de comportement », pas une liste de souhaits — chaque règle doit répondre à « quelle erreur concrète cette règle évite ». Si votre travail ne concerne pas des pipelines multi-étapes, la Rule 10 (checkpoint) n’a pas d’intérêt ; si le codebase a déjà un lint forçant un style unique, la Rule 11 (s’aligner sur les conventions) est superflue. Après avoir lu les 12 règles, conservez une version qui correspond aux pièges réels que vous avez rencontrés, et supprimez le reste.
Les événements à suivre ensuite incluent : si, officiellement, Anthropic va standardiser les règles de CLAUDE.md (pour l’instant, ce n’est que « advisory »), si le repo de Forrest Chang entre dans des modèles officiellement recommandés, si la communauté publie des versions personnalisées pour des domaines spécifiques (front-end / back-end / data engineering), et si le taux de conformité évolue après la mise à jour de la version des modèles de Claude.
Cet article « Karpathy CLAUDE.md bat 126K étoiles : compilation de règles avancées en 12 pour la communauté » apparaît pour la première fois sur ABMedia dans la rubrique « chaîne de nouvelles ».
