L'état d'esprit expérimental

Le problème : tu utilises les mêmes patterns de prompting à chaque session. Tu ne sais pas s'ils sont les meilleurs, ni s'ils te coûtent silencieusement des heures.

Gain rapide : lance cette expérience maintenant et regarde comment le style de prompt change la sortie de Claude :

Prompt A: "Fix the bug in auth.ts"
Prompt B: "Let's work through auth.ts together. What might be wrong?"
Prompt C: "Review auth.ts like a senior engineer. List every issue you find."

Compare les trois résultats. La version collaborative produit généralement une analyse plus profonde et repère les cas limites que la version directe laisse passer. C'est la boucle expérimentale en action.

Expérience 1 : L'impact du style de prompt

La même tâche donne des résultats différents selon la façon dont tu la formules. Teste ces trois styles sur n'importe quelle tâche de débogage :

Style 1 (Command): "Fix the bug in login.ts"
Style 2 (Teaching): "Walk me through login.ts and help me find what's wrong"
Style 3 (Review): "Act as a code reviewer. Analyze login.ts for bugs, security issues, and edge cases."

Ce que tu vas trouver : le style 3 (mode review) a tendance à faire remonter plus de problèmes parce qu'il cadre le travail comme une analyse plutôt qu'une correction rapide.

Voici le pattern dans la vraie vie. Lance les trois styles contre un handler de login qui a un bug null-check évident plus une faille de timing subtile dans le rate limiter. Le style 1 (command) corrige le null check et s'arrête. Le style 2 (teaching) corrige le null check et explique pourquoi c'est important, mais rate quand même le problème de timing. Le style 3 (review) repère le null check, la vulnérabilité de timing, et signale que les messages d'erreur exposent l'état interne au client.

Le pattern tient sur tous les types de tâches, mais l'écart varie. Pour le code sensible à la sécurité, le mode review repère nettement plus. Pour les bugs UI simples, l'écart se réduit et le style command convient bien. Pour les refactors, le mode teaching produit souvent les résultats les plus propres parce qu'il force Claude à expliquer chaque changement au fur et à mesure.

Note quel style gagne pour chaque type de tâche dans tes projets. Après quelques sessions, tu auras ta propre table de référence : la sécurité avec le mode review, les corrections simples avec le mode command, les refactors avec le mode teaching.

Expérience 2 : L'impact du contexte de fichiers

La qualité du code de Claude varie selon les fichiers que tu lui fournis en contexte. Teste toi-même :

Experiment A: "Refactor errors.ts to use a cleaner pattern"
Experiment B: "Refactor errors.ts. Reference utils/errors.ts and AuthController.ts for the existing pattern."

La seconde version produit des refactors qui s'intègrent à tes patterns existants. Sans contexte, Claude invente des patterns qui peuvent se battre avec ta codebase.

Essaie ça sur un vrai projet avec une hiérarchie d'erreurs personnalisée. Dans l'expérience A, Claude écrit un try/catch générique avec des appels new Error(). Code propre, mais il ignore les classes AppError, ValidationError, et NotFoundError déjà dans le repo. Le fichier refactorisé ne compilera même pas à côté du reste du code sans erreurs de type.

Dans l'expérience B, Claude trouve les classes d'erreur dans utils/errors.ts, lit comment AuthController.ts les utilise déjà, et produit un refactor qui correspond au pattern existant. Même tâche, même modèle, même session. La seule différence était trois références de fichiers supplémentaires.

La vraie leçon va plus loin que "donne plus de fichiers à Claude." Il y a un point idéal. Inclure 2-4 fichiers étroitement liés améliore constamment la qualité de sortie. Au-delà de 6-7 fichiers, tu atteins des rendements décroissants parce que Claude répartit son attention sur trop de patterns. Commence avec le fichier de définition de type et un fichier qui implémente déjà le pattern que tu veux.

Expérience 3 : Mode planification vs exécution directe

Le mode planification (Shift+Tab deux fois) change la façon dont Claude aborde les problèmes. Lance cette comparaison :

Direct: "Add user permissions to the admin dashboard"
Planning: [Shift+Tab twice] "Add user permissions to the admin dashboard"

En mode planification, Claude lit ta codebase et présente des options avant de toucher un seul fichier. Tu examines l'approche, repères les problèmes tôt, et choisis la voie à suivre.

L'écart se révèle vite sur les fonctionnalités multi-fichiers. Lance cette expérience sur un système de permissions qui s'étend sur le middleware d'auth, les routes du dashboard, et les composants frontend. L'exécution directe plonge directement dans le middleware et commence à coder. Elle fait des suppositions sur la structure des rôles qui se battent avec le modèle utilisateur existant, et la moitié des changements doivent être annulés.

Le mode planification, par contraste, propose trois options d'architecture avant d'écrire du code. Une option utilise l'enum de rôle existant. Une autre suggère une table de permissions pour plus de granularité. La troisième propose un hybride. Choisis l'option un, et l'implémentation s'aligne avec la codebase dès le premier fichier touché.

Où se situe le seuil : les fonctionnalités complexes touchant 3+ fichiers bénéficient presque toujours du mode planification. Les corrections simples (fichier unique, changement évident) n'en ont pas besoin. Le point d'équilibre est autour de 2 fichiers. À 2 fichiers, le mode planification ajoute environ 30 secondes de surcharge mais économise du backtracking. En dessous, c'est de la cérémonie pour la cérémonie.

Expérience 4 : Les configurations CLAUDE.md

Ton fichier CLAUDE.md influence directement le comportement de Claude. Teste différentes configurations :

Configuration A: (empty CLAUDE.md)
Configuration B:
  - Always ask before making changes outside the current feature directory
  - Use conventional commits
  - Prefer small, focused changes over large refactors

Lance la même tâche avec chacune et compare :

Combien de questions de clarification Claude pose-t-il ?
Suit-il les patterns de ton projet ?
Les commits sont-ils bien délimités ?

Avec la configuration A, Claude traite chaque répertoire comme terrain libre. Demande-lui d'ajouter une fonctionnalité dashboard et il modifie le schéma de base de données, met à jour les routes API, et change la configuration de déploiement en une seule fois. Sans poser de questions. Un seul commit géant.

Avec la configuration B, la même demande déclenche une question de clarification : "La fonctionnalité dashboard a besoin d'un nouvel endpoint API. Dois-je le créer dans src/api/ ou modifier le routes.ts existant ?" Le travail résultant arrive en trois commits ciblés, chacun ne touchant que les fichiers de cette couche.

Ton CLAUDE.md n'est pas de la documentation. C'est un système d'exploitation. Les instructions que tu y mets influencent chaque décision que Claude prend. Lance différentes instructions contre la même tâche et regarde le résultat changer. De petits changements dans CLAUDE.md produisent des changements de comportement étonnamment importants. Consulte le guide du répertoire de règles pour un contrôle plus granulaire du comportement de Claude par type de fichier.

Expérience 5 : La pression de la fenêtre de contexte

Celle-ci est discrètement importante. La qualité de sortie de Claude baisse sous la pression de contexte d'une façon qui ne s'annonce pas. Lance ce test :

Démarre une session fraîche et demande à Claude de construire une fonctionnalité modérément complexe (quelque chose qui touche 3-4 fichiers). Note la qualité. Ensuite, dans une session existante qui tourne depuis un moment avec du contexte accumulé, demande exactement la même fonctionnalité.

La session fraîche produit généralement du code plus propre avec une meilleure gestion des erreurs. La session chargée coupe les coins ronds : noms de variables plus courts, moins de vérifications de cas limites, parfois les tests sont sautés. Ce n'est pas que Claude oublie comment écrire du bon code. C'est que le modèle répartit son attention sur tout le contexte accumulé, laissant moins de place à la tâche actuelle.

La conclusion pratique : utilise /compact de manière agressive avant les tâches complexes. Lance /compact avant toute fonctionnalité touchant plus de deux fichiers, et la différence de qualité est facile à voir. Certains développeurs préfèrent /clear pour un départ totalement frais, mais tu perds l'historique de conversation. La commande /compact fait un compromis en résumant le contexte précédent sans le jeter.

Construis ton propre journal d'expériences

Crée un fichier de suivi simple pour capturer ce que tu apprends :

# Claude Code Experiments

## Prompt Style
- Review mode: best for security and auth code
- Command mode: best for quick UI fixes
- Teaching mode: best for refactors

## Planning Mode
- Use for 3+ files
- Skip for single-file changes

Ce journal devient ton guide d'optimisation personnel. Après un mois, tu auras un ensemble de données de ce qui fonctionne vraiment dans ta codebase avec tes patterns. Ça vaut plus que n'importe quel conseil générique, parce que la bonne approche change selon le projet, le langage, et le type de travail que tu fais.

Être spécifique, c'est l'essentiel. "Le mode review est meilleur" n'est pas utile. "Le mode review repère 2-3 fois plus de problèmes de sécurité dans le code d'auth" est quelque chose que tu appliques à chaque session.

Prochaines expériences à essayer

Prêt à tester plus ? Essaie celles-ci :

Gestion du contexte : que se passe-t-il à 60% vs 90% d'utilisation du contexte ?
Planification automatique : la planification automatisée bat-elle le changement de mode manuel ?
Sélection de modèle : comment les différents modèles gèrent-ils la même tâche complexe ?
Pensée profonde : la réflexion étendue produit-elle de meilleures décisions d'architecture ?

Arrête de supposer. Lance l'expérience. Note le résultat. Itère.

Chaque session est une occasion de trouver quelque chose qui te rend plus rapide. Les développeurs qui expérimentent systématiquement dépassent ceux qui s'en tiennent à leur premier instinct. Chaque contournement est un pattern qui attend d'être nommé. Chaque pattern nommé est une compétence que Claude peut réutiliser.

C'est ce que signifie "l'état d'esprit d'évolution du système" en pratique. C'est l'une des 5 meilleures pratiques Claude Code qui séparent les meilleurs développeurs des autres.