Quand votre fichier de instructions devient un foutoir sans fin

Imaginez la scène : vous créez un nouveau projet avec un CLAUDE.md tout neuf. Quelques tips utiles, deux-trois notes de contexte, une alerte sur ce cas bizarre dans votre authentification. Quelques mois plus tard, vous rouvrez le fichier et c'est devenu un roman de 400 lignes avec des instructions contradictoires, des rappels obsolètes, et des annexes que plus personne ne comprend vraiment.

Ce n'est pas qu'une impression. C'est un phénomène universel.

Des chercheurs ont analysé 247 694 durées de vie d'instructions across 1 867 dépôts GitHub. Le résultat ? Les prompts pour agents IA ne grossissent pas juste un peu : ils explosent, triplant largement au fil du temps (+226%). Concrètement, ces fichiers gagnent +4,9 instructions nettes à chaque commit. Ils ne rétrécissent jamais. Ils ne font que gonfler.

Et le plus dingue : plus une instruction est vieille, moins elle a de chances d'être supprimée. Les données montrent un hazard log de -0,032 par commit. Autrement dit, les instructions deviennent de plus en plus immortelles avec le temps. Ce n'est pas qu'on n'a pas envie de ranger. C'est qu'on ne sait tout simplement pas si on peut安全 supprimer quoi que ce soit.

Le problème O(2^|D|)

Pourquoi ça se passe comme ça ? Les chercheurs parlent de "catastrophic remembering" — l'inverse du famous "catastrophic forgetting" en machine learning. Mais pas besoin d'un PhD pour comprendre.

Pensez au calcul coût-bénéfice. Ajouter une instruction, c'est pas cher. Vous voyez un problème, vous écrivez une solution, vous passez à autre chose. Coût immédiat faible, bénéfice immédiat clair.

Supprimer une instruction ? C'est une tout autre histoire. Vous devez comprendre chaque endroit où cette instruction pourrait compter. Raisonner sur les interactions avec toutes les autres instructions. Vérifier que la suppression ne va pas casser quelque chose de subtil mais important. Les chercheurs ont calculé ce coût cognitif comme O(2^|D|) pour un prompt avec |D| instructions — ça grossit exponentiellement avec le nombre d'instructions existantes.

Du coup, les développeurs font ce que font les gens rationnels : ils arrêtent d'essayer. Nouvelles instructions en append. Anciennes instructions restent. Le fichier grossit.

Les commentaires : le vrai héros silencieux

Là où ça devient vraiment intéressant, c'est que la solution n'est pas des techniques de prompting plus sophistiquées ou des modèles plus smarts. C'est quelque chose que les développeurs utilisent depuis l'aube de la programmation : les commentaires.

Les chercheurs ont pris une approche originale — ils ont inverti IFEval, un benchmark standard, pour créer des "mondes vérifiables" où les prompts optimaux sont réellement connus. Quand ils ont ajouté des commentaires encodant le raisonnement latent dans les prompts, la croissance excédentaire des instructions est tombée de +211,3% à juste +1,4%.

C'est une réduction de 99,3%.

Mais le vrai kicker ? Ces commentaires ne contrôlaient pas juste la croissance — ils ont amélioré la performance réelle de suivi d'instructions de jusqu'à 23,1% sur des tâches du monde réel. Les commentaires ne sont pas du désordre organisationnel. Ce sont des structures porteuses qui aident les assistants IA à raisonner correctement sur le contexte.

Pourquoi c'est important maintenant

On traverse un changement fondamental dans ce que "code" veut dire. Les chercheurs posent une question provocante : "Si l'anglais est le nouveau code, pourquoi on n'a pas encore de commentaires ?"

C'est une question légitime. Pendant des décennies, les développeurs ont compris que du code sans commentaires, c'est de la dette technique. Les commentaires expliquent le "pourquoi", pas juste le "quoi". Ils capturent l'intention, les cas limites, et la connaissance institutionnelle qu'on ne peut pas déduire de la syntaxe seule.

Pourtant, dans notre rush pour déléguer toujours plus aux assistants IA, on a traité les instructions en langage naturel différemment. On écrit des impératifs — fais ci, ne fais pas ça, pense à vérifier X — sans expliquer notre raisonnement.

Le résultat, ce sont ces fichiers CLAUDE.md qui explosent : des instructions que personne ne comprend vraiment, qui peuvent se contredire, et qui grossissent sans aucun mécanisme de rationalisation.

Le chemin à suivre

Si vous maintenez un fichier CLAUDE.md ou un prompt agentique similaire, voici ce que la recherche suggère :

1. Commentez vos instructions, pas juste votre code. Expliquez pourquoi une règle existe. Documentez les cas limites. Capturez le raisonnement derrière les décisions.

2. Adoptez la rationalisation périodique. Ne faites pas juste des appends — réécrivez. La recherche note explicitement que les réécritures complètes sont une des seules choses qui arrêtent la croissance.

3. Traitez vos instructions IA comme de la documentation d'onboarding. Vous ne donneriez pas à un nouveau développeur un fichier de 400 lignes de règles indifférenciées ? Votre assistant IA mérite la même clarté.

La trajectoire sur laquelle on est n'est pas tenable. Chaque nouveau projet commence avec de bonnes intentions et finit en bordel ingérable. Mais la solution est peut-être plus simple qu'on ne pensait : écrivez pour l'humain (ou l'IA) qui lira vos instructions dans six mois, pas juste celui qui répond à votre question aujourd'hui.

Les commentaires ne sont pas du désordre. Ils sont l'architecture de la compréhension.