Comment le createur de Claude Code utilise reellement Claude Code

Boris Cherny, le createur de Claude Code, a partage publiquement son workflow de developpement — et le post a depasse les 5 000 likes en seulement deux heures. Quand la personne qui a construit l’outil revele comment elle l’utilise au quotidien, les gens sont tout ouie.

Ce qui m’a le plus surpris, c’est la simplicite. Pas de personnalisation elaboree, pas de configurations secretes. L’essentiel de son approche repose sur la combinaison des fonctionnalites natives de Claude Code, utilisees de maniere disciplinee et deliberee.

Si vous avez lu la recente analyse d’Andrej Karpathy sur les couches d’abstraction que les developpeurs doivent maitriser dans les agents de codage IA, le guide de Boris en est le complement pratique.

Traitement parallele — 15 sessions Claude en simultanee

Boris lance cinq instances de Claude en parallele dans le terminal, plus cinq a dix autres sur claude.ai/code via le navigateur. Il demarre meme des sessions depuis son telephone le matin et vient les consulter plus tard.

Sa configuration :

• Il numerate les onglets de terminal de 1 a 5, en utilisant les notifications systeme pour savoir quand une intervention est necessaire.
• Il bascule entre sessions locales et web avec la commande &.
• Il utilise --teleport pour naviguer entre les sessions.
• Chaque onglet de terminal possede son propre checkout Git, de sorte que chaque session execute un plan independant sur une branche independante.

Ce n’est pas du multitache gratuit. Chaque session traite une tache discrete et bien delimitee. Le parallelisme decoule de la clarte des plans, pas du fait de jongler entre les contextes.

Un detail interessant releve dans les commentaires : Boris utilise des checkouts Git separes par onglet plutot que des worktrees Git. Il trouve ce modele plus simple a apprehender quand il gere de nombreuses sessions en parallele.

Opus 4.5 avec reflexion — plus gros, c’est en realite plus rapide

Boris utilise le modele le plus puissant disponible pour chaque tache. C’est contre-intuitif — Opus est plus lent par token et plus couteux. Mais son raisonnement est pragmatique : le modele le plus gros necessite moins de corrections, utilise les outils plus precisement et produit de meilleurs resultats des le premier essai.

L’effet net est que le temps total d’accomplissement d’une tache est plus court avec Opus qu’avec des modeles plus petits, parce qu’on passe moins de temps a corriger les erreurs et a reformuler les prompts.

• Les meilleures performances de codage de tous les modeles qu’il a testes.
• Moins d’interventions necessaires pendant l’execution.
• Le temps reel total diminue malgre une latence par token plus elevee.

CLAUDE.md — l’ingenierie de contexte en equipe

Toute l’equipe versionne un unique fichier CLAUDE.md dans Git. Chaque fois que Claude commet une erreur, quelqu’un ajoute une note dans ce fichier pour que la meme erreur ne se reproduise pas.

C’est de l’ingenierie cumulative en action :

• Plusieurs membres de l’equipe contribuent chaque semaine.
• Lors des revues de code, l’equipe utilise des tags @.claude pour demander des ajouts au CLAUDE.md.
• Chaque equipe maintient son propre CLAUDE.md.
• Le fichier devient un corpus croissant de connaissances institutionnelles dont chaque session Claude herite automatiquement.

Le concept est simple, mais c’est la discipline a le maintenir de facon reguliere qui en fait toute la puissance.

Mode Plan — une bonne planification, c’est 90 % du succes

Boris demarre la plupart de ses sessions en Mode Plan (shift+tab deux fois). Si l’objectif est une pull request, il discute du plan avec Claude jusqu’a ce qu’il en soit satisfait, puis bascule en mode auto-accept et laisse Claude executer l’integralite du plan sans interruption.

Le workflow :

1. Investir du temps en amont dans la phase de planification.
2. Iterer sur le plan jusqu’a couvrir les cas limites et les problemes potentiels.
3. Une fois le plan verrouille, passer en execution automatisee.
4. Minimiser les allers-retours de correction pendant l’implementation.

Ce schema elimine le mode d’echec le plus courant : commencer a coder avant que l’approche ne soit claire. La planification ne coute presque rien. Le retravail, lui, coute cher.

Slash Commands et sous-agents — automatiser le travail repetitif

Tout workflow que Boris utilise plus de quelques fois par jour devient une slash command, enregistree dans .claude/commands/. Des commandes comme /commit-push-pr deviennent accessibles a Claude lui-meme, pas seulement au developpeur.

• Elimination totale des prompts repetitifs.
• Utilisation de bash inline pour precalculer le contexte, ce qui accelere les commandes.
• Des sous-agents comme code-simplifier et verify-app gerent les workflows de validation courants.
• Des hooks PostToolUse formatent automatiquement le code apres chaque modification.

Boris considere egalement les Skills comme une forme de slash commands — des definitions de workflows reutilisables et partageables qui standardisent la facon dont Claude aborde des taches specifiques.

Gestion des permissions et integration d’outils

Plutot que d’utiliser --dangerously-skip-permissions, Boris utilise /permissions pour pre-approuver les commandes jugees sures. L’equipe partage les configurations de serveurs MCP pour que Claude puisse acceder directement a Slack, BigQuery, Sentry et d’autres outils.

• Partager les parametres de permissions via .claude/settings.json.
• Partager les integrations d’outils via .mcp.json.
• Reduire les demandes de permission superflues sans sacrifier la securite.

C’est le juste milieu pragmatique entre le verrouillage total et l’acces sans restriction. L’equipe s’accorde sur ce qui est sur, le formalise, et passe a autre chose.

Boucles de verification — le multiplicateur de qualite 2-3x

La pratique la plus importante du workflow de Boris : donner a Claude un moyen de verifier son propre travail.

Sur claude.ai/code, il fait tester chaque modification par Claude via une extension Chrome qui interagit avec l’application reelle. La boucle de verification comprend :

• Des agents en arriere-plan qui controlent le travail une fois termine.
• Des hooks Agent Stop qui executent des validations deterministes.
• Le plugin ralph-wiggum pour une verification supplementaire.
• Des environnements sandbox avec des modes de permission ajustes pour eviter les blocages.
• Des tests UX reels dans les navigateurs et les simulateurs.

Ce n’est pas un bonus optionnel. Boris considere les boucles de verification comme la difference entre un resultat de qualite 1x et un resultat de qualite 2-3x.

Le schema derriere les pratiques

En faisant abstraction des outils et configurations specifiques, quatre principes emergent :

• Paralleliser sans hesitation. Lancer de nombreuses sessions, chacune avec un perimetre clair et sa propre branche.
• Planifier avant de construire. Le Mode Plan est la fonctionnalite a plus fort levier de Claude Code.
• Partager le contexte en equipe. CLAUDE.md transforme les lecons individuelles en savoir collectif.
• Fermer la boucle de verification. Laisser Claude verifier son propre travail avant de le relire soi-meme.

Ce qui frappe le plus dans la configuration de Boris, ce n’est aucune technique en particulier — c’est le faible nombre de composants en jeu. Le createur de l’outil ne s’appuie pas sur des configurations exotiques. Il s’appuie sur les fondamentaux, appliques avec constance.