Claude Code va vite. Mais va-t-il assez loin ?

Hypothèses et observations sur la compression du chain-of-thought dans les workflows de développement intensif.

En ce mi-mars 2026, les retours des utilisateurs intensifs de Claude Code ont évolué. Les discussions initiales autour d’Opus 4.6 portaient sur un modèle « moins profond » ; depuis le lancement de Sonnet 4.6 en février, elles se sont affinées. Ce que documentent aujourd’hui plusieurs power-users : des régressions perceptibles en Plan Mode — plans plus superficiels, détection de dépendances croisées moins systématique — et une tendance des sessions longues à dériver vers des réponses génériques, au détriment des conventions de tests ou des invariants d’architecture définis en contexte.

Ces observations ne sont pas universelles, mais elles reviennent avec une régularité suffisante pour former un motif. Utilisateur intensif de l’outil (voir ma Stack IA 2026), j’ai voulu creuser la mécanique probable. Ce qui suit est une analyse fondée sur mes propres observations et sur des indices publics — pas une démonstration rigoureuse. Mais les patterns sont suffisamment cohérents pour mériter d’être discutés.

Autopsie d’une directive : l’exécution avant la réflexion

Le System Prompt de Claude Code contient une section « Output efficiency » qui pousse explicitement vers la concision. Ce n’est pas une supposition : le repo communautaire Piebald-AI/claude-code-system-prompts extrait ces prompts directement depuis le code compilé de Claude Code à chaque release. Dans la version v2.1.74 (11 mars 2026), ce bloc de 177 tokens est décrit comme instruisant Claude à « être concis et direct, privilégier les réponses sur le raisonnement, et limiter les sorties à l’information essentielle ». Le CHANGELOG du repo révèle une donnée intéressante : ce bloc a été introduit en v2.1.64, puis supprimé dans une version plus récente — ce qui confirme qu’il s’agit d’un levier que l’équipe Anthropic manipule activement, pas d’un invariant figé.

La directive orienterait le modèle vers quelque chose comme :

Aller droit au but. Commencer par la réponse ou l’action. Si c’est dit en une phrase, ne pas le dire en trois.

L’effet mécanique probable : Ce type d’instruction, placé tôt dans le System Prompt, crée un biais d’encodage de position : le modèle est poussé à « committer » rapidement sur un token de sortie avant d’avoir exploré les dépendances transversales. En d’autres termes, le raisonnement interne — ce qu’Anthropic appelle le « Thinking Budget » dans son API (soit le budget de tokens internes alloués au raisonnement avant la réponse visible) — est comprimé volontairement au profit de la latence.

Exemple concret : un refactoring de middleware d’authentification. Le type User gagne un champ optionnel. Un modèle avec un budget de raisonnement suffisant identifiera que le décorateur de réponse dans api.ts ne gère pas ce nouveau champ. Un modèle sous pression de brièveté modifie le middleware, conclut « C’est fait », et vous découvrez la 500 en staging. Ce n’est pas une hypothèse : c’est un pattern que je retrouve régulièrement dans mes propres sessions, sur des refactorings de complexité moyenne.

Votre CLAUDE.md n’est qu’une loi locale

Beaucoup conseillent d’optimiser son CLAUDE.md pour compenser. C’est oublier la hiérarchie structurelle : le System Prompt est une contrainte physique ; votre fichier de contexte est une convention locale. En cas de tension entre les deux, le System Prompt gagne — et cette tension existe dès que votre CLAUDE.md demande de l’explicitation là où le système pousse à la concision.

Dans mes propres sessions longues (50+ tours sur des projets complexes), j’observe une dérive progressive : les instructions de contexte projet — « explique l’impact avant de modifier », « liste les fichiers affectés » — perdent de leur influence à mesure que la session avance. Le System Prompt, lui, reste constant.

C’est d’ailleurs ce qui rend la couche MEMORY.md d’autant plus précieuse : pas pour contrer le System Prompt, mais pour maintenir la cohérence du contexte projet sur des sessions longues où la dérive s’accélère.

D’autres utilisateurs rapportent des patterns similaires, notamment dans des fils de discussion sur des forums spécialisés et des espaces Slack privés de développeurs — sans logs publics, cela reste un faisceau de signaux faibles, pas une donnée.

La mécanique de l’attention : une intuition ML

Note : ce qui suit est une modélisation intuitive, pas une description de l’architecture interne d’Anthropic.

L’encodage de position précoce des directives de brièveté fonctionne vraisemblablement comme un a priori fort dans le processus de génération : le modèle est conditionné à favoriser les sorties courtes dès les premières décisions d’échantillonnage. Pour une analogie ML : c’est l’effet d’une régularisation qui pénalise les sorties longues, indépendamment de leur pertinence contextuelle.

Ce qui est documenté côté API : Anthropic expose bien un mécanisme de contrôle du raisonnement pour ses modèles récents. Pour Opus 4.6 et Sonnet 4.6, c’est désormais l’adaptive thinking — Claude décide lui-même si et quand « penser » selon la complexité du problème, avec un paramètre effort (low / medium / high / max). Sur les versions antérieures, c’était un budget_tokens numérique explicite. Dans les deux cas, cette capacité existe côté API et est absente de l’interface Claude Code — alors que la complexité des tâches de développement la justifierait pleinement.

Cela rejoint ce que j’analysais dans mon article sur l’ablitération et la conscience géométrique : l’alignement opère comme une torsion vectorielle dans l’espace latent, et ici cette torsion privilégie systématiquement la latence sur la profondeur. Comme l’explique également mon article sur les modèles IA qui débattent entre eux, la qualité du raisonnement n’est pas une propriété fixe du modèle : c’est une ressource qu’on peut allouer ou contraindre.

Le coût caché : dette cognitive et fausse vélocité

J’en ai parlé dans mon article sur le vibe coding et la revanche du bas-niveau : la brièveté forcée produit un code qui semble correct sur le chemin nominal, mais qui est structurellement fragile sur les edge cases. L’économie initiale de tokens se retourne : un bug non détecté à cause d’une analyse bâclée génère 4 à 5 allers-retours correctifs. La vélocité apparente devient un déficit réel.

C’est aussi ce que pointe mon article sur la grande dépossession des développeurs par l’IA : on transfère la responsabilité cognitive à un outil, mais sans transférer la rigueur. Le résultat n’est ni l’autonomie promise ni la maîtrise conservée — c’est un angle mort structurel.

Sur X et dans les communautés de power-users, les compensations empiriques prolifèrent : Plan Mode (activé via shift+tab, au moment où j’écris ces lignes) combiné à des transcriptions orales pour densifier le contexte, ou encore des hooks de pré-modification personnalisés. Ces workarounds fonctionnent — partiellement — mais ils signalent un problème de design, pas des solutions pérennes. L’outil tweakcc, mentionné dans le repo Piebald, permet d’ailleurs de patcher certains blocs du System Prompt dans son installation locale — une soupape de contournement, mais une soupape tout de même.

Deux dettes s’accumulent :

1. Dette cognitive : Claude est devenu un exécutant très rapide qui ne signale plus ce qu’il ne comprend pas. Ce silence n’est pas de la compétence.
2. Dette de débogage : L’économie de tokens en amont se paie en cycles de correction en aval. Le calcul économique est défavorable sur des tâches complexes.

Ce qui aiderait : vers un contrôle du budget de raisonnement

Anthropic propose déjà en API un contrôle fin du raisonnement — la capacité technique existe donc, elle est simplement retenue côté interface. Sur Claude Code spécifiquement, une issue ouverte dans le repo communautaire documente cette attente. La demande est simple : rendre ce contrôle accessible à l’utilisateur dans Claude Code.

Deux modes suffiraient :

• Mode Concis : pour les questions de syntaxe, les recherches rapides, les micro-corrections.
• Mode Raisonné : avec un budget de thinking explicitement alloué à un brouillon interne avant toute modification de fichier — détection d’impact, edge cases, tests requis.

En attendant, le workaround le plus efficace que j’utilise : un hook de pré-modification (voir mon guide complet des hooks Claude Code) qui force une étape d’analyse d’impact explicite avant tout write_file. C’est artisanal, mais ça récupère une partie du raisonnement que le système comprime. Mon article sur les SKILL.md documente une approche complémentaire : encapsuler les conventions de raisonnement dans des skills réutilisables plutôt que de les répéter dans chaque CLAUDE.md.

Conclusion

La brièveté a sa place. Pour une question de syntaxe ou un débogage ponctuel, elle est une vertu. Pour un refactoring multi-fichiers ou une architecture distribuée, elle est un risque.

Le problème n’est pas que Claude Code soit concis. C’est qu’il ne soit pas ajustable selon la complexité de la tâche. Un partenaire de développement qui ne sait faire qu’un seul débit n’est pas un partenaire — c’est un outil.

Les utilisateurs qui ont besoin de profondeur vont soit développer des workarounds de plus en plus complexes, soit migrer vers des alternatives — modèles reasoning-first, agents locaux — dès que leur maturité opérationnelle le permet. Ce n’est pas une prédiction catastrophiste : c’est la logique ordinaire de l’adéquation outil/besoin. Comme je l’analysais dans Anthropic n’a pas sorti un modèle — il a publié un avis de liquidation, les choix de design d’Anthropic ont des conséquences réelles sur la fidélité des utilisateurs avancés.

La question posée à Anthropic est simple : la profondeur de raisonnement est-elle un paramètre configurable — comme elle l’est déjà en API via l’adaptive thinking — ou un sacrifice permanent sur l’autel de la latence ?