Comment le créateur de Claude Code l'utilise au quotidien

Comment le créateur de Claude Code l'utilise au quotidien

Boris Cherny n'a pas écrit manuellement une seule ligne de code depuis novembre 2025.

Laissez ça faire son chemin un instant. La personne qui a construit Claude Code — qui a conçu l'outil que des centaines de milliers de développeurs utilisent désormais au quotidien — a arrêté de taper du code à la main il y a plus de quatre mois. Et sa production n'a pas diminué. Elle s'est accélérée. Il livre entre 10 et 30 pull requests chaque jour, fait tourner jusqu'à 15 sessions Claude Code en parallèle entre son terminal et son navigateur, et lance parfois des sessions de codage depuis son téléphone avant de se coucher pour examiner le travail terminé avec son café du matin.

Quand j'ai entendu ça pour la première fois lors de sa passage dans le podcast de Lenny, ma réaction a été le scepticisme. Trente PRs par jour ? De la part de quelqu'un qui n'écrit pas de code ? Ça ressemble à de la fanfaronnade LinkedIn déguisée en gourou de la productivité.

Puis j'ai étudié son workflow réel. Et ce qui m'a surpris, ce n'était pas le volume — c'était la simplicité. Le système de Boris est presque agressivement minimal. Pas de bibliothèques de prompts complexes. Pas de scaffolding élaboré. Pas de fichiers d'instructions de vingt pages. Toute sa configuration CLAUDE.md fait environ 100 lignes. Environ 2 500 tokens. C'est tout.

L'écart entre ma productivité avec Claude Code et la sienne ne venait pas d'une technique secrète que je n'avais pas découverte. Il venait de six principes que j'avais ignorés, trop compliqués, ou appliqués à l'envers. Après avoir passé les deux dernières semaines à restructurer mon propre workflow autour de son approche, je peux vous dire — les résultats sont réels. Mon temps de débogage a diminué d'environ la moitié. Mes sessions produisent du résultat utilisable du premier coup environ 3 fois plus souvent. Et j'ai enfin arrêté ce cycle exaspérant où Claude construit avec assurance la mauvaise chose pendant que je regarde, trop engagé dans les coûts irrécupérables pour interrompre.

Voici l'analyse complète de ce que Boris Cherny fait réellement — et plus important encore, pourquoi chaque élément compte plus qu'il n'y paraît.

« Ralentir pour aller plus vite » — Pourquoi 80 % des sessions commencent en plan mode

C'est la première chose qui a changé ma façon de travailler, et honnêtement, c'est le principe auquel j'ai résisté le plus longtemps.

Avant, j'ouvrais Claude Code et je commençais à prompter immédiatement. Décrire la fonctionnalité. Regarder le code apparaître. Me sentir productif. Sauf que je n'étais pas productif — j'étais occupé. Il y a une différence cruciale, et Boris la résume en une seule observation : l'IA résout les problèmes rapidement, mais pas nécessairement les bons problèmes. Sans planification claire, Claude va sprinter avec assurance dans la mauvaise direction et construire quelque chose de techniquement impressionnant qui rate complètement l'objectif réel.

Boris commence environ 80 % de ses sessions en plan mode. Si vous ne connaissez pas, le plan mode (activé en appuyant deux fois sur Shift+Tab dans Claude Code) dit à l'IA de réfléchir et d'analyser sans écrire de code ni exécuter de commandes. Il lit des fichiers, pose des questions, propose des approches — mais ne touche à rien tant que vous n'avez pas explicitement approuvé le plan.

La technique spécifique que Boris utilise est ce qu'il appelle le « prompt d'entretien ». Avant que le moindre code ne soit généré, il demande à Claude quelque chose comme :

Interview me about this. What core problems does this solve?
Who is this for? What does success look like? What should this
NOT do? Summarize it back to me before writing any code.

Ce prompt a changé l'intégralité de mon workflow. Voici pourquoi il est plus puissant qu'il n'y paraît.

Quand je l'ai essayé pour la première fois, Claude m'a posé cinq questions de clarification sur une fonctionnalité que je pensais avoir décrite clairement. Deux de ces questions ont révélé des hypothèses que j'avais faites et qui étaient tout simplement fausses. L'une d'elles — « Cela devrait-il modifier l'enregistrement utilisateur existant ou créer une nouvelle entrée dans le journal d'activité ? » — aurait conduit à une erreur d'architecture de base de données qui aurait pu prendre des heures à démêler si Claude avait simplement commencé à construire.

Boris a partagé un exemple précis qui m'est resté en mémoire : une correction de bug pour un client où Claude, sans planification, est allé directement modifier des valeurs en base de données au lieu de corriger la logique d'affichage de l'UI. La « correction » a techniquement résolu le symptôme signalé mais a cassé trois autres fonctionnalités qui dépendaient de ces valeurs en base de données. Le genre de bug qui passe un test manuel rapide puis explose en production deux jours plus tard.

Le plan mode l'aurait détecté en soixante secondes. L'entretien aurait révélé que le problème concernait uniquement l'affichage. Claude aurait proposé une correction au niveau de la couche UI. Pas de modifications en base de données. Pas de cascade de dysfonctionnements.

J'utilise cette approche « entretien d'abord » depuis deux semaines, et le schéma est constant : environ 4-5 minutes de planification économisent 20-40 minutes de reprise. Le calcul est sans appel.

Un détail facile à manquer — le plan mode est aussi nettement plus rapide et moins coûteux par interaction. Puisque Claude n'exécute pas d'outils, n'écrit pas de fichiers et ne lance pas de commandes pendant la planification, les réponses reviennent à la vitesse de l'éclair et consomment moins de tokens. Vous obtenez essentiellement la meilleure réflexion de l'IA à prix réduit avant de vous engager dans la coûteuse phase d'exécution.

Après que Claude a présenté son plan, Boris le passe en revue, le modifie parfois directement avec Ctrl+G (qui ouvre le plan dans votre éditeur de texte), et seulement alors passe en mode d'acceptation automatique pour laisser Claude exécuter. Dans la plupart des cas, dit-il, Claude réussit l'implémentation du premier coup après une bonne session de planification. Un seul essai. Pas d'itérations. Pas de corrections « c'est presque ça mais en fait je voulais dire... ».

Cela seul justifie l'effort de planification. Mais le prochain principe est ce qui fait que la planification perdure d'une session à l'autre.

Le CLAUDE.md de 100 lignes — Pourquoi moins de contexte donne de meilleurs résultats

C'est ici que l'approche de Boris contredisait directement ce que je faisais depuis des mois.

J'avais un fichier CLAUDE.md qui approchait les 500 lignes. De la documentation architecturale détaillée. Des standards de codage avec des exemples. Du contexte historique sur pourquoi certaines décisions avaient été prises. Des bibliothèques de patterns. Ça semblait exhaustif. Professionnel. Comme un vrai document d'ingénierie.

Ça consommait aussi silencieusement 30 % de ma fenêtre de contexte disponible à chaque requête. Chaque fois que je posais une question à Claude — même une simple — ces 500 lignes étaient chargées en premier. Des tokens dépensés avant même que le travail réel ne commence.

Le CLAUDE.md de Boris fait environ 100 lignes. Environ 2 500 tokens. Et il surpasse chaque fichier d'instructions gonflé que j'ai jamais créé.

Sa philosophie est presque zen dans sa retenue : le fichier ne devrait contenir que des règles qui corrigent des erreurs récurrentes. Pas de documentation. Pas d'explications d'architecture. Pas de standards de codage que Claude connaît déjà par ses données d'entraînement. Uniquement des corrections. Des garde-fous. Les choses spécifiques que Claude fait mal dans votre projet et qu'il ne saurait pas sans qu'on le lui dise.

Le processus est réactif, pas proactif. Boris et son équipe chez Anthropic suivent une règle simple : « Chaque fois que nous voyons Claude faire quelque chose d'incorrect, nous l'ajoutons au CLAUDE.md pour que ça ne se répète pas la prochaine fois. » Le fichier est commité dans git, partagé avec toute l'équipe, et mis à jour plusieurs fois par semaine. Mais des choses sont aussi supprimées. Au fur et à mesure que les modèles s'améliorent, des règles qui étaient nécessaires il y a six mois deviennent redondantes. Claude les a apprises tout seul.

Cela rejoint quelque chose que j'ai couvert dans mon guide de 50 astuces Claude Code — votre CLAUDE.md est soit votre superpouvoir soit votre goulot d'étranglement, et la ligne de démarcation est la longueur. Mais Boris va plus loin que moi. Il ne recommande pas seulement de le garder court. Il recommande de le supprimer et de le recréer de zéro quand il devient gonflé ou contradictoire, plutôt que d'essayer de le nettoyer chirurgicalement.

Le raisonnement : les instructions accumulées développent des contradictions internes au fil du temps. La Règle 7 dit « toujours utiliser async/await » mais la Règle 43 dit « utiliser des callbacks pour les opérations de base de données ». Un humain lisant le fichier pourrait repérer le conflit. Claude pourrait ne pas le faire — ou pire, pourrait essayer de satisfaire les deux simultanément, produisant du code hybride bizarre.

Repartir de zéro élimine les contradictions, les instructions en double et les règles écrites pour des capacités de modèle qui ne s'appliquent plus. C'est l'approche Marie Kondo de la configuration IA : si une règle ne corrige pas un problème actuellement actif, elle n'a pas sa place dans le fichier.

J'ai essayé la semaine dernière. Supprimé mon CLAUDE.md de 500 lignes et reconstruit de zéro avec uniquement les règles que je pouvais justifier par les deux dernières semaines d'utilisation. J'ai fini avec 87 lignes. Ma consommation de tokens a baissé sensiblement, et — voici la partie que je n'attendais pas — la qualité du code de Claude s'est réellement améliorée. Moins de contexte contradictoire signifiait un output plus cohérent.

Il y a un détail structurel qui mérite d'être mentionné. Boris tire parti de la hiérarchie CLAUDE.md : un fichier au niveau racine pour les règles de tout le projet et des fichiers au niveau des répertoires pour le contexte spécifique aux sous-systèmes. Votre répertoire /api obtient ses propres règles ciblées sans gonfler le fichier racine. C'est quelque chose que j'utilise aussi intensivement, et ça scale magnifiquement sur les monorepos.

Si vous êtes là avec un CLAUDE.md qui a dépassé les 200 lignes, je recommande fortement l'option nucléaire de Boris. Supprimez-le. Reconstruisez uniquement à partir des points de douleur récents. Le fichier qui en résultera sera plus petit et meilleur.

Boucles de vérification — Le multiplicateur de qualité 2-3x que personne n'utilise

C'est le principe qui, honnêtement, m'a fait me sentir un peu bête de ne pas l'avoir mis en place plus tôt.

L'affirmation de Boris est précise : donner à Claude la capacité de vérifier son propre travail améliore la qualité de l'output de 2-3x. Pas « un peu mieux ». Pas « un peu plus fiable ». Deux à trois fois mieux. Et après avoir implémenté son approche, je crois que le chiffre est exact.

Le concept est simple. La plupart des gens utilisent Claude Code dans un cycle générer-et-réviser : Claude écrit du code, vous le lisez, vous repérez les problèmes, vous demandez des corrections. Ça marche, mais ça met toute la charge de qualité sur vous. Vous êtes la couche de vérification. Et vous êtes humain, ce qui signifie que vous ratez des choses — surtout pendant les longues sessions quand l'attention diminue.

L'approche de Boris inverse cela. Il donne à Claude les outils et instructions pour vérifier son propre output avant de le présenter comme terminé. Deux étapes :

1. Donnez à Claude une méthode pour vérifier son travail (une suite de tests, un aperçu navigateur, une commande de linting, un vérificateur de types)
2. Dites explicitement à Claude cette méthode (dans CLAUDE.md ou dans le prompt)

L'implémentation pratique diffère selon ce que vous construisez. Pour une application web, ça peut signifier dire à Claude : « Après avoir fait des modifications, lance la suite de tests et ouvre le navigateur pour confirmer visuellement que l'UI correspond au besoin. » Pour un endpoint d'API : « Après l'implémentation, lance le test d'intégration et confirme que la structure de la réponse correspond au schéma. » Pour la génération de contenu : « Après l'écriture, vérifie par rapport au document de directives de marque dans /docs/style-guide.md. »

Boris va plus loin — il ajoute des prompts de vérification directement dans son fichier CLAUDE.md. Quelque chose comme :

Before marking any task as complete, propose a verification plan.
Describe what you'll check and how you'll confirm correctness.
Then execute that plan.

Cette unique règle, ajoutée à votre fichier d'instructions, force Claude à penser à la vérification avant de commencer à construire. Et ça change le résultat de façon spectaculaire. Claude commence à suggérer des cas de test auxquels vous n'aviez pas pensé. Il attrape des cas limites pendant l'implémentation plutôt qu'après. Il lance des vérifications de types et des linters de manière proactive au lieu d'attendre que vous le demandiez.

J'ai ajouté cette règle à mon propre CLAUDE.md il y a huit jours. Pendant cette période, j'ai eu exactement deux cas où Claude a soumis du code avec un bug que je n'ai pas repéré pendant la revue. Dans les huit jours avant l'ajout de la règle, le nombre était plus proche de neuf ou dix. Petit échantillon, certes. Mais le changement directionnel est indéniable.

L'insight clé ici est que Claude ne manque pas de la capacité de vérifier — il manque de l'instruction de vérifier. Laissé à ses paramètres par défaut, Claude optimise pour la vitesse et la complétion. Il veut vous donner une réponse. La vérification ralentit cela, alors il la saute sauf si vous l'intégrez explicitement dans le workflow. Le génie de Boris est de reconnaître qu'une ligne dans CLAUDE.md déverrouille une capacité qui a toujours été là mais dormante.

Cela se connecte à quelque chose de plus large sur ma façon de penser les skills d'agent Claude Code — les meilleures configurations n'ajoutent pas de nouvelles capacités à l'IA. Elles activent des capacités que l'IA possède déjà mais n'utilise pas par défaut. La vérification est l'exemple le plus impactant de ce schéma.

Multipliez-vous — Des sessions parallèles qui fonctionnent vraiment

Boris fait tourner 5 instances de Claude Code localement dans son terminal et 5-10 autres sur le site web d'Anthropic. Simultanément. Sur des tâches différentes.

Quand j'ai entendu ça pour la première fois, ma réaction a été « ça a l'air chaotique ». Plusieurs sessions d'IA travaillant sur la même codebase ? C'est une recette pour les conflits de merge, les modifications contradictoires et du code qui ne s'intègre pas.

Sauf que Boris ne les fait pas travailler sur la même tâche. Chaque session reçoit un morceau de travail distinct et indépendant. L'une construit peut-être un nouveau endpoint d'API. Une autre écrit des tests pour une fonctionnalité existante. Une troisième refactorise un module utilitaire. Une quatrième investigue un rapport de bug. Elles ne se chevauchent jamais. Elles ne touchent jamais les mêmes fichiers. Elles tournent en parallèle parce qu'elles le peuvent — le travail est naturellement partitionné.

L'astuce qui fait que ça marche au niveau pratique : chaque session locale utilise son propre git checkout plutôt que des branches ou worktrees dans le même dépôt. Cela élimine totalement les conflits du système de fichiers. Chaque instance de Claude pense qu'elle travaille sur un projet autonome. Pas de fichiers de verrouillage qui se battent entre eux. Pas de modifications à moitié écrites dans des répertoires partagés.

Pour les sessions distantes, Boris les lance avec & depuis la CLI et utilise parfois --teleport pour déplacer des sessions entre son terminal et l'interface du navigateur. Il lance une session avant de se coucher, et elle attend avec un pull request terminé quand il vérifie le matin.

J'ai monté en charge jusqu'à trois sessions parallèles — mon matériel et ma capacité d'attention ne sont pas encore tout à fait au niveau de Boris — et même à cette échelle modeste, la différence de productivité est significative. Trois tâches indépendantes qui me prendraient 45 minutes chacune en série sont terminées en environ 50-55 minutes au total. Pas du parallélisme parfait, mais assez proche pour changer fondamentalement la façon dont je planifie ma journée de travail.

Il y a un avantage plus subtil que Boris mentionne et que j'ai confirmé par l'expérience : les sessions fraîches apportent des perspectives fraîches. Quand vous êtes plongé dans une session qui travaille sur un problème depuis 30 minutes, la fenêtre de contexte est remplie des hypothèses de ce problème et des approches échouées précédentes. Démarrer une deuxième session pour regarder le même problème — mais de zéro — produit parfois une meilleure solution en moins de cinq minutes parce qu'elle ne porte pas le bagage des tentatives précédentes.

Je fais maintenant ça systématiquement pour les bugs coriaces. Si ma première session ne l'a pas résolu en 15 minutes, j'ouvre une session fraîche avec une description propre du problème. La session fraîche le résout environ la moitié du temps. Pas parce qu'elle est plus intelligente — parce qu'elle est sans charge.

Pour ceux qui s'intéressent à l'approche git worktree pour les sessions parallèles de Claude, j'en ai parlé plus en détail dans mon guide Claude Code git worktrees agents parallèles. La version courte : les worktrees vous donnent des répertoires de travail isolés à partir d'un seul dépôt, ce qui est légèrement plus efficace que des clones complets mais atteint le même objectif que Boris décrit.

Systématiser les boucles internes — Les slash commands comme mémoire musculaire

C'est ici que le workflow de Boris passe d'« individu productif » à « système de production ».

Chaque développeur a des boucles internes — les tâches que vous répétez plusieurs fois par jour. Lancer les tests. Générer du boilerplate. Créer des pull requests. Formater des revues de code. Écrire des messages de commit. Mettre à jour la documentation. Ces tâches ne sont pas complexes individuellement, mais elles s'accumulent. Si vous passez 3 minutes sur chacune et en faites vingt par jour, c'est une heure de travail répétitif.

Boris automatise tout ça avec les slash commands et skills de Claude Code. Pas occasionnellement. De façon obsessionnelle. Chaque workflow qu'il fait plus de deux fois devient une commande.

L'analogie qu'il utilise est parfaite : les prompts réguliers, c'est comme dire à un joueur de basket « dribble le ballon jusqu'au bout du terrain, cherche un coéquipier ouvert et passe si tu en vois un ». Les slash commands sont des systèmes de jeu précis — des séquences exactes exécutées de la même manière à chaque fois. « Pick and roll côté gauche. » Pas d'ambiguïté. Pas de variation. Juste l'exécution.

Dans Claude Code, les slash commands vivent dans .claude/commands/ sous forme de fichiers markdown. Chaque fichier décrit un workflow spécifique. Quand vous tapez /ma-commande, Claude lit le fichier et exécute ce workflow. Pas de ré-explication. Pas de préambule « voici ce dont j'ai besoin que tu fasses... ». Juste le déclencheur et le résultat.

Le vrai coup de maître de Boris est de demander à Claude lui-même de suggérer quelles commandes il devrait créer :

Based on this project, what Claude skills should I create?
Look at my recent git history, my CLAUDE.md, and the types
of changes I make most frequently. Suggest 5-7 slash commands
that would automate my most common workflows.

J'ai lancé ce prompt sur l'un de mes projets et Claude a suggéré sept commandes. Cinq d'entre elles étaient des workflows que je faisais manuellement tous les jours. Deux étaient des workflows auxquels je n'avais même pas pensé à automatiser parce qu'ils impliquaient plusieurs étapes à travers différents outils. J'ai construit les sept, et les gains de temps se cumulent quotidiennement.

La différence clé entre un slash command et un prompt sauvegardé, c'est la durabilité. Les prompts vivent dans votre presse-papiers ou un fichier de notes. Ils se perdent, sont modifiés de façon inconsistante et oubliés. Les slash commands vivent dans votre dépôt. Ils sont versionnés. Ils sont partagés avec votre équipe via git. Quand vous améliorez un workflow, tout le monde reçoit l'amélioration au prochain git pull.

Les skills vont encore plus loin — ce ne sont pas seulement des commandes que vous déclenchez, mais des capacités que Claude peut invoquer de façon autonome pendant son raisonnement. Une skill avec le bon frontmatter YAML s'active automatiquement quand Claude rencontre une situation pertinente. « Quand l'utilisateur demande un rapport d'état, utilise ce workflow. » « Quand tu génères un endpoint d'API, suis ce template. » C'est la différence entre avoir un livre de recettes et avoir un chef qui connaît déjà toutes les recettes.

Pour approfondir la création de Claude Skills efficaces, mon guide des Claude Skills couvre la structure YAML, les cinq patterns qui comptent vraiment, et les erreurs que j'ai faites pendant ma première semaine de construction. L'approche de Boris confirme ce que j'ai découvert indépendamment : commencez par les workflows que vous répétez le plus, automatisez ceux-là d'abord, et laissez la complexité grandir organiquement.

Construire pour l'avenir — La leçon amère appliquée à votre workflow

C'est le principe qui relie tout le reste, et c'est le plus philosophique des six stratégies de Boris. Mais ne le sautez pas — c'est celui qui vous sauvera d'un piège dans lequel j'ai vu tomber des dizaines de développeurs.

Boris fait référence au célèbre essai de Rich Sutton de 2019, « The Bitter Lesson », qui argumente que dans l'histoire de la recherche en IA, les méthodes générales qui exploitent la puissance de calcul ont toujours fini par surpasser les approches basées sur des connaissances spécifiques au domaine conçues par des humains. Chaque fois que des chercheurs ont essayé de coder l'intelligence à la main — livres d'ouvertures d'échecs, règles de reconnaissance vocale, grammaires de traduction — ils ont été battus par des systèmes qui apprenaient simplement à partir de quantités massives de données.

Boris applique cela aux workflows Claude Code : ne sur-ingénierez pas vos prompts ou votre scaffolding. Le modèle s'améliore vite. Cette chaîne de prompts élaborée sur laquelle vous avez passé trois jours ? Dans six mois, une simple instruction d'une phrase produira de meilleurs résultats parce que le modèle se sera autant amélioré.

J'ai vu ça de mes propres yeux. Des techniques que j'ai documentées début 2025 pour faire produire du TypeScript propre à Claude — des instructions de formatage spécifiques, des patterns d'exemple, des annotations de type explicites dans le prompt — sont maintenant inutiles. Claude génère du TypeScript propre par défaut. Les heures que j'ai passées sur ces prompts étaient de l'effort gaspillé, investi dans une infrastructure que les améliorations du modèle ont rendu obsolète.

Le conseil pratique de Boris : concentrez-vous sur alimenter le modèle avec des données et du contexte de qualité plutôt que d'optimiser l'ingénierie de prompts. Votre temps est mieux investi dans une codebase bien structurée avec des conventions de nommage claires, des tests exhaustifs et une bonne documentation que dans le perfectionnement du méga-prompt en dix-sept étapes qui force Claude à écrire du code comme vous le voulez. Parce que Claude apprendra à écrire du code comme vous le voulez. Votre travail est de vous assurer qu'il a le bon contexte — pas les bonnes contraintes.

Cela rejoint la philosophie du CLAUDE.md minimal. Un fichier d'instructions de 500 lignes, c'est de la sur-ingénierie pour les limitations du modèle actuel. Un fichier de 100 lignes centré sur les corrections spécifiques au projet restera pertinent même quand le modèle s'améliorera, parce qu'il enseigne à Claude des choses qu'il ne peut genuinement pas savoir sans qu'on le lui dise — les conventions de votre équipe, les particularités de votre projet, les exigences spécifiques de votre domaine métier.

Boris le formule comme une question de où investir votre heure marginale. Vous pourriez la consacrer à :

• Option A : Affiner un prompt jusqu'à ce que Claude génère du code légèrement meilleur maintenant
• Option B : Améliorer votre codebase, votre couverture de tests ou votre CLAUDE.md avec une correction qui rapportera pendant des mois

L'Option B gagne à chaque fois. Et elle gagne par une marge plus large à chaque mise à jour du modèle, parce que plus le modèle s'améliore, moins l'ingénierie de prompts compte et plus la qualité du contexte compte.

J'ai restructuré ma propre approche en conséquence. Quand je me retrouve à peaufiner un prompt pour la troisième fois, je m'arrête et je demande : « Est-ce un problème de prompt ou un problème de contexte ? » Presque toujours, c'est le contexte. La codebase est ambiguë. La suite de tests ne couvre pas le cas limite. Le CLAUDE.md manque une convention critique du projet. Corrigez le contexte, et le prompt peut rester simple.

Ce qui a changé dans mon propre workflow

Après deux semaines de mise en œuvre des six principes de Boris, voici ce qui a changé.

Mes sessions sont plus courtes. Pas parce que je fais moins — parce que la phase de planification élimine les faux départs qui consommaient avant 30-40 % de mon temps de session. Je passais 90 minutes sur une fonctionnalité dont 30 minutes de « non, ce n'est pas ce que je voulais dire, laissez-moi ré-expliquer ». Maintenant, le prompt d'entretien détecte le désalignement dans les cinq premières minutes.

Mon CLAUDE.md fait 87 lignes. En baisse de presque 500. Et ma qualité d'output est allée vers le haut, pas vers le bas. Moins d'instructions, moins de confusion, du code plus cohérent. Je le passe en revue chaque semaine et me pose deux questions : « Claude a-t-il fait cette erreur récemment ? » et « Claude ferait-il cette erreur sans cette règle ? » Si la réponse à l'une ou l'autre est non, la règle est supprimée.

Je fais tourner trois sessions parallèles quotidiennement. Une pour la fonctionnalité principale que je construis. Une pour les tests et la documentation. Une pour l'investigation de bugs ou le refactoring. Elles n'interfèrent pas. Elles ne partagent pas de contexte. Et le débit combiné est environ 2,5 fois ce que je faisais en série.

Chaque workflow que j'ai répété trois fois est maintenant un slash command. J'en ai quatorze répartis sur mes projets principaux. Le gain de temps semble petit individuellement — peut-être 2-3 minutes chacun — mais à vingt invocations par jour, c'est presque une heure récupérée. Une heure que je consacre au travail qui demande réellement du jugement, pas de l'exécution.

Et j'ai arrêté d'optimiser les prompts. Quand Claude produit un mauvais output, je corrige le contexte : mettre à jour CLAUDE.md, améliorer la codebase, ajouter un test manquant. Je n'ai pas écrit un « meilleur prompt » depuis dix jours. J'ai écrit du meilleur code. Et l'output de l'IA s'est amélioré en conséquence.

L'implication inconfortable

Il y a quelque chose dans l'approche de Boris qui mérite qu'on s'y attarde — quelque chose autour duquel la plupart des créateurs de contenu Claude Code (moi y compris) ont tendance à tourner.

Les six principes ci-dessus ne sont pas complexes. Planifiez avant de construire. Gardez les instructions minimales. Laissez l'IA vérifier son propre travail. Exécutez les tâches en parallèle. Automatisez les workflows répétitifs. Pariez sur l'amélioration du modèle.

Rien de tout cela ne demande de sophistication technique. Un développeur junior peut implémenter les six dès le premier jour. La barrière n'est pas la connaissance — c'est l'ego. Planifier semble lent quand on veut commencer à construire. Supprimer son CLAUDE.md de 500 lignes soigneusement élaboré ressemble à jeter du travail. Faire confiance à Claude pour vérifier son propre output ressemble à un abandon de contrôle. Faire tourner des sessions parallèles donne l'impression de perdre le fil.

Les résultats de Boris suggèrent que les développeurs qui prospéreront avec la programmation assistée par IA ne sont pas ceux qui ont les prompts les plus ingénieux. Ce sont ceux qui sont prêts à changer leur façon de penser le travail lui-même. À traiter l'IA non comme une machine à écrire plus rapide mais comme un collaborateur qui a besoin d'une direction claire, d'un contexte propre et de l'autonomie pour vérifier son propre travail.

La personne qui a construit l'outil nous dit exactement comment l'utiliser. Et son conseil n'est pas « utilisez plus de fonctionnalités » ou « écrivez de meilleurs prompts ». Son conseil est : planifiez plus, configurez moins, vérifiez tout, et faites confiance au fait que l'outil va continuer à s'améliorer.

J'en suis à deux semaines avec cette approche. Mon output a augmenté. Ma frustration a diminué. Et pour la première fois depuis que j'utilise Claude Code, j'ai le sentiment de travailler avec l'outil au lieu de le forcer à se soumettre.

Si vous n'essayez qu'une seule chose de cet article aujourd'hui, faites-en le prompt d'entretien. Ouvrez votre prochaine session Claude Code en plan mode et collez ceci avant toute autre chose :

Interview me about this. What core problems does this solve?
Who is this for? What does success look like? What should this
NOT do? Summarize it back to me before writing any code.

Répondez aux questions de Claude honnêtement. Regardez-le vous résumer votre intention. Détectez le désalignement avant qu'une seule ligne de code n'existe. Et puis dites-moi que ces cinq minutes n'en valaient pas la peine.

Questions fréquemment posées

Qui est Boris Cherny et quel est son rôle chez Anthropic ?

Boris Cherny est le créateur et responsable de Claude Code chez Anthropic. Il a construit le prototype original basé sur le terminal et dirige maintenant l'équipe qui le développe. Il livre 10-30 pull requests par jour sans écrire manuellement de code, en utilisant son propre outil pour tout le travail de développement. Pour du contexte sur l'outil lui-même, consultez mon tutoriel Claude Code pour débutants.

Comment activer le plan mode dans Claude Code ?

Appuyez deux fois sur Shift+Tab dans le terminal Claude Code pour activer le plan mode. Claude analysera alors les fichiers et proposera des approches sans écrire de code ni exécuter de commandes. Vous pouvez aussi utiliser la commande /plan dans Claude Code v2.1.0 ou ultérieur. Voir « Ralentir pour aller plus vite » ci-dessus pour le workflow complet.

Quelle devrait être la longueur de mon fichier CLAUDE.md ?

Boris Cherny maintient le sien à environ 100 lignes (environ 2 500 tokens). Le fichier ne devrait contenir que des règles qui corrigent des erreurs récurrentes — pas de documentation, d'explications architecturales ou de standards de codage que Claude connaît déjà. Supprimez les règles qui n'ont pas été pertinentes ces deux dernières semaines. Pour une analyse complète, consultez mon guide de 50 astuces Claude Code.

Puis-je exécuter plusieurs sessions Claude Code en même temps ?

Oui. Boris fait tourner 5 sessions localement et 5-10 dans le navigateur simultanément. La clé est de donner à chaque session un travail indépendant sur des checkouts git séparés pour éviter les conflits de fichiers. Lancez les sessions distantes avec & depuis la CLI et utilisez --teleport pour déplacer les sessions entre le terminal et le navigateur.

Que sont les slash commands de Claude Code et comment les créer ?

Les slash commands sont des templates de workflow réutilisables stockés sous forme de fichiers markdown dans .claude/commands/. Tapez /nom-de-la-commande pour les déclencher. Créez-en un en écrivant un fichier markdown qui décrit les étapes du workflow, puis enregistrez-le dans le répertoire de commandes. Demandez à Claude : « Quels slash commands devrais-je créer pour ce projet ? » pour commencer.

Travaillons ensemble

Vous souhaitez construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.

• Fiverr (développements sur mesure et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io