La quatrième fois, c'est trop tard
Dans l'épisode précédent ([CANONICAL URL #52: à compléter après push de over-engineering-3-recadrages]), je raconte trois recadrages dans la même session — plus simple, plus simple, plus simple — avant que Claude finisse par proposer la version d'une fonction qui tient en huit lignes plutôt que celle avec interface, registry et trois fichiers. Le lendemain matin je rouvre le projet, je demande un correctif mineur dans le même module, et la réponse arrive architecturée exactement comme la veille. Strategy pattern, registry, trois tests d'intégration. Le recadrage n'a pas survécu au /clear. Il n'avait aucune raison de survivre. Aucun fichier ne le portait, aucun mécanisme ne le déclenchait quand le réflexe revenait.
La quatrième fois, c'est trop tard. Il faut graver à la troisième.
La ligne
J'ai ajouté ceci dans CLAUDE.md, section Conventions, un bloc au-dessus de la règle Server Components :
Default to the smallest change that fits. Add abstractions only after the second occurrence, never the first.
Quatre choix dans deux phrases. Chacun a coûté plusieurs essais avant de tenir.
Pourquoi ces quatre
Default to, pas avoid. La première version que j'avais essayée disait Avoid premature abstraction et n'a strictement rien changé en pratique. Le négatif active l'objet qu'il vise. L'agent lit premature abstraction et active la catégorie abstraction, contre laquelle il a un défaut entraîné qui le pousse à en produire. Le positif pose une direction sans nommer le réflexe inverse. C'est le détail le moins évident de l'exercice, et c'est celui qui a fait basculer le test.
That fits, pas seulement smallest. The smallest change tout seul pousse au hack. The simplest solution ouvre un débat sur la simplicité. That fits précise la mesure : couvrir le besoin, pas l'élégance.
Deuxième occurrence, pas la troisième. La règle des trois de Martin Fowler, dans Refactoring, dit « the third time you do something similar, refactor ». Je l'ai abaissée à deux pour une raison qui ne vaut probablement que pour le dev solo Claude Code : pas de PR review, donc la deuxième occurrence est le dernier moment où je suis encore lucide sur l'abstraction que je m'apprête à acter. À la troisième, Claude propose spontanément et je signe sans regarder, parce que la pression session m'a déjà usé.
Never the first. Le never est volontaire et probablement excessif. Mais un défaut formulé avec une exception devient une exception cherchée. Never coupe la négociation interne. Quand le cas vraiment exceptionnel arrive — et il arrive — je dois argumenter contre la règle explicitement, ce qui est exactement la friction que je veux.
Ce que j'ai vu jusqu'ici
Trois sessions, trois sujets, trois modules différents. Claude a proposé une abstraction prématurée que j'ai relevée et qu'il a retirée en un échange, contre trois ou quatre fois par session la semaine d'avant. Pas une étude. Un observateur, biais de confirmation possible, échantillon ridicule. Mais la ligne se charge avec CLAUDE.md à chaque démarrage, et la pression baseline pointe maintenant contre le défaut entraîné. Un vrai A/B test sur la sortie Claude Code fera l'objet d'un article ultérieur de la série.
Coda
La doctrine en CLAUDE.md, ce n'est pas une liste de bonnes pratiques. C'est l'empilement matériel des leçons qu'on a refusé de répéter une quatrième fois. La règle des trois (Fowler, sur les abstractions) appliquée à la règle des trois (la mienne, sur les corrections orales en session). À la troisième fois où je me retrouve à dire la même chose à Claude, ça part en ligne dans CLAUDE.md. Sinon je la redirai dans la session suivante, et l'enseignement partira avec le contexte.
Suite de [CANONICAL URL #52: à compléter après push de over-engineering-3-recadrages]. A/B test de l'effet CLAUDE.md sur la sortie Claude Code : sujet d'un article ultérieur de la série.
Top comments (0)