Un agent casse quelque chose. On ajoute une ligne dans CLAUDE.md pour qu’il ne recommence pas. Trois mois plus tard, personne ne sait exactement pourquoi cette règle existe, donc personne n’ose la supprimer.

Puis une deuxième arrive. Puis quarante.

Kushal Chakrabarti donne un nom à ce phénomène : « catastrophic remembering », la mémoire catastrophique. Son étude suit 247 694 vies d’instructions dans 1 867 dépôts et observe un effet de cliquet très net dans les fichiers de consignes destinés aux agents.1

Les fichiers triplent, puis quelqu’un bulldoze tout

Dans le corpus GitHub étudié, le nombre d’instructions augmente de 226 % sur la durée de vie d’un fichier. L’âge joue aussi contre la suppression : plus une règle est ancienne, moins elle a de chances de disparaître.1

Le détail le plus parlant est la manière dont elles finissent par mourir. Selon l’étude, 76,8 % des disparitions d’instructions arrivent dans un commit qui réécrit massivement le fichier. Après cette remise à zéro, la croissance reprend.1

Cela ressemble beaucoup à nos placards numériques. Jeter un objet demande de décider s’il sert encore. Vider tout le carton pendant un déménagement demande seulement un moment de violence administrative.

Le papier propose une explication. Ajouter une instruction après un échec coûte peu : le contexte du problème est encore présent. La supprimer plus tard exige de reconstruire la raison de son existence et les régressions qu’elle empêchait. Cette information a souvent disparu.1

Le résultat est asymétrique. L’ajout paraît sûr immédiatement. La suppression porte un risque visible. Le coût des règles inutiles, lui, est diffus.

Une règle devrait avoir un commentaire

La proposition du papier est presque embarrassante de simplicité : conserver la raison avec la règle.

Les auteurs construisent des environnements synthétiques où la liste minimale d’instructions nécessaires est connue. Sans commentaires utiles, les prompts s’épaississent. Avec des commentaires qui enregistrent le raisonnement ayant conduit à chaque règle, l’excès d’instructions rapporté passe de +211,3 % à +1,4 % dans cette expérience.1

Le commentaire ne dit pas seulement « ne fais pas X ». Il conserve le contexte : quel échec a déclenché la règle, pourquoi une formulation plus générale ne suffisait pas, quel comportement elle protège.

Cela transforme une consigne en objet maintenable.

Dans une autre expérimentation construite à partir de WildIFEval, le papier rapporte jusqu’à 23,1 % d’amélioration de suivi d’instructions avec cette approche.1

Il faut résister à la tentation de transformer immédiatement ces chiffres en loi du développement agentique. Le mécanisme causal est testé dans des mondes construits pour rendre le minimum observable. Le corpus GitHub, lui, montre la croissance réelle mais ne peut pas prouver à lui seul pourquoi chaque mainteneur garde chaque ligne. Le papier vient aussi de sortir et n’est pas encore un résultat peer-reviewed.1

Le problème n’est pas la taille en caractères

On pourrait répondre avec un script qui coupe CLAUDE.md à 200 lignes. Ce serait rater le sujet.

Une instruction peut être longue et indispensable. Une autre peut tenir en six mots et survivre six mois après la disparition du bug qui l’a créée. Le problème est la perte de provenance.

Les développeurs ont déjà inventé des outils pour ça. Un commentaire explique une décision locale. Un commit raconte un changement. Une ADR conserve un choix d’architecture. Un test de régression transforme un ancien accident en contrainte exécutable.

Les fichiers d’instructions d’agents sont encore souvent traités comme une liste magique à laquelle on ajoute des incantations après chaque incident.

L’étude suggère une discipline plus intéressante : chaque règle importante devrait arriver avec son « pourquoi », et idéalement avec une manière de vérifier qu’elle sert encore.

Cela change aussi la manière de faire évoluer un agent. Au lieu de demander « quelle règle manque ? » après chaque erreur, on peut demander si le comportement devrait vivre dans un test, un outil, un type, une permission ou une contrainte mécanique plutôt que dans davantage de prose.

Le meilleur CLAUDE.md n’est probablement pas celui qui se souvient de tout. C’est celui qui sait encore pourquoi il se souvient.