Utiliser Claude Code depuis plus de deux mois, d’un simple fichier de configuration, il est devenu un véritable système d’exploitation.
Le piège le plus douloureux : les fichiers du répertoire rules/ sont chargés en totalité à chaque conversation. J’y ai inséré 17KB de règles, ce qui a littéralement saturé la fenêtre de contexte — 125 996 / 125 999 tokens, Claude ne pouvait plus répondre. Je l’ai réduit à 6.6KB pour qu’il retrouve un fonctionnement normal. Cette expérience m’a enseigné un principe de conception : chaque byte a un coût, le chargement à la demande est la bonne solution. Ma structure actuelle comporte trois niveaux : (Chargement permanent, <200 lignes, uniquement des pointeurs) → rules/ (chargement automatique, normes de comportement, processus de débogage, règles de capture) → docs/ (chargement à la demande, documents volumineux, lus uniquement si nécessaire) Au-dessus, j’ai mis en place quatre mécanismes : Couche de données chaudes — Enregistre la progression du jour, écrit automatiquement avant de fermer la fenêtre, sans attendre que vous disiez "enregistrer". Lors de la prochaine conversation, Claude peut reprendre à partir du point de rupture. Routage des tâches — Sonnet gère le quotidien, les mises à jour automatiques des fonds/stratégies vers Opus, pour la validation croisée, externalise à Codex ou Gemini. Quatre niveaux de planification, chaque niveau ayant des conditions de déclenchement précises. Retour d’expérience — En cas de bug, la première étape consiste à consulter la mémoire, ne pas le faire, c’est violer le processus de débogage. Les erreurs corrigées sont immédiatement enregistrées. Validation finale — Avant de déclarer "c’est corrigé", il faut exécuter des tests, lire les sorties, confirmer la réussite. Interdiction de dire "ça devrait aller". Après deux mois d’utilisation, la plus grande sensation : ce n’est pas un fichier de configuration à écrire une fois pour toutes, mais un système vivant. Lorsqu’on le corrige, il s’en souvient ; lorsqu’on tombe dans un piège, il s’enracine ; lorsqu’on ferme la fenêtre, il sauvegarde automatiquement. Plus on l’utilise, plus il devient fluide, car il évolue avec vous. À quoi ressemble votre système ?
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Utiliser Claude Code depuis plus de deux mois, d’un simple fichier de configuration, il est devenu un véritable système d’exploitation.
Le piège le plus douloureux : les fichiers du répertoire rules/ sont chargés en totalité à chaque conversation. J’y ai inséré 17KB de règles, ce qui a littéralement saturé la fenêtre de contexte — 125 996 / 125 999 tokens, Claude ne pouvait plus répondre. Je l’ai réduit à 6.6KB pour qu’il retrouve un fonctionnement normal.
Cette expérience m’a enseigné un principe de conception : chaque byte a un coût, le chargement à la demande est la bonne solution.
Ma structure actuelle comporte trois niveaux :
(Chargement permanent, <200 lignes, uniquement des pointeurs)
→ rules/ (chargement automatique, normes de comportement, processus de débogage, règles de capture)
→ docs/ (chargement à la demande, documents volumineux, lus uniquement si nécessaire)
Au-dessus, j’ai mis en place quatre mécanismes :
Couche de données chaudes —
Enregistre la progression du jour, écrit automatiquement avant de fermer la fenêtre, sans attendre que vous disiez "enregistrer". Lors de la prochaine conversation, Claude peut reprendre à partir du point de rupture.
Routage des tâches — Sonnet gère le quotidien, les mises à jour automatiques des fonds/stratégies vers Opus, pour la validation croisée, externalise à Codex ou Gemini.
Quatre niveaux de planification, chaque niveau ayant des conditions de déclenchement précises.
Retour d’expérience — En cas de bug, la première étape consiste à consulter la mémoire, ne pas le faire, c’est violer le processus de débogage. Les erreurs corrigées sont immédiatement enregistrées.
Validation finale — Avant de déclarer "c’est corrigé", il faut exécuter des tests, lire les sorties, confirmer la réussite. Interdiction de dire "ça devrait aller".
Après deux mois d’utilisation, la plus grande sensation : ce n’est pas un fichier de configuration à écrire une fois pour toutes, mais un système vivant. Lorsqu’on le corrige, il s’en souvient ; lorsqu’on tombe dans un piège, il s’enracine ; lorsqu’on ferme la fenêtre, il sauvegarde automatiquement. Plus on l’utilise, plus il devient fluide, car il évolue avec vous.
À quoi ressemble votre système ?