Comment Boris Cherny, créateur de Claude Code, utilise Claude Code

(x.com/bcherny)

114 points par GN⁺ 2026-01-05 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Il dévoile son environnement de travail et son workflow réels, avec 5 instances de Claude exécutées en parallèle dans le terminal et 5 à 10 supplémentaires sur le web
Il utilise Opus 4.5 with thinking pour toutes les tâches : plus gros et plus lent, mais nécessitant moins d’ajustements et excellent dans l’usage des outils, donc au final plus rapide
Toute l’équipe partage un seul fichier CLAUDE.md, enrichi à chaque fois que Claude adopte un mauvais comportement afin d’accumuler l’apprentissage
La plupart des sessions commencent en mode Plan, puis passent en mode auto-accept une fois le plan suffisamment affiné pour terminer en une seule passe
Le facteur le plus important pour améliorer de 2 à 3 fois la qualité du résultat final est de fournir à Claude une boucle de rétroaction lui permettant de vérifier lui-même son travail

1/ Configuration d’un environnement d’exécution en parallèle

5 instances de Claude en parallèle dans le terminal, avec des onglets numérotés de 1 à 5, et usage des notifications système pour savoir quand une saisie est nécessaire

Sur le web via claude.ai/code, 5 à 10 instances supplémentaires de Claude sont lancées en parallèle, en plus des Claude locaux
Possibilité de transférer une session locale vers le web (&), ou de démarrer directement une session dans Chrome, avec --teleport pour passer dans les deux sens
Il utilise aussi l’app iOS pour lancer plusieurs sessions chaque matin et à différents moments de la journée, puis y revenir plus tard

Utilisation de Opus 4.5 with thinking pour toutes les tâches
Le meilleur modèle de code qu’il ait utilisé jusqu’à présent
Plus gros et plus lent que Sonnet, mais nécessite moins de pilotage (steering) et excelle dans l’usage des outils
Au final, il produit presque toujours un meilleur résultat plus vite que les modèles plus petits

Le dépôt Claude Code conserve un unique fichier CLAUDE.md partagé par toute l’équipe
Le fichier est versionné dans git, et toute l’équipe y contribue plusieurs fois par semaine
Chaque fois que Claude adopte un mauvais comportement, l’information est ajoutée à CLAUDE.md pour éviter la même erreur la fois suivante
D’autres équipes maintiennent également leur propre CLAUDE.md, chaque équipe étant responsable de le garder à jour

Lors des code reviews, ils taguent @.claude dans les PR des collègues pour ajouter du contenu à CLAUDE.md dans la PR elle-même
Utilisation de Claude Code GitHub Action(/install-github-action)
Une approche similaire au concept de Compounding Engineering de Dan Shipper

La plupart des sessions commencent en mode Plan (shift+tab deux fois)
Si l’objectif est de produire une PR, l’échange avec Claude en mode Plan se poursuit jusqu’à ce que le plan soit jugé satisfaisant
Une fois le plan validé, passage en mode auto-accept edits, où Claude termine généralement en une seule passe (1-shot)
Un bon plan est vraiment crucial

Il utilise des slash commands pour chaque workflow « inner loop » exécuté plusieurs fois par jour
Cela évite de répéter les prompts, et Claude peut lui aussi exploiter ce workflow
Les commandes sont versionnées dans git et stockées dans le répertoire .claude/commands/
Exemple : usage de la slash command /commit-push-pr des dizaines de fois par jour
- Du bash inline pour pré-calculer des informations comme git status et exécuter plus vite, en évitant les allers-retours inutiles avec le modèle

Usage régulier de plusieurs sous-agents
- code-simplifier : simplifie le code après que Claude a terminé son travail
- verify-app : inclut des instructions détaillées pour les tests end-to-end de Claude Code
Comme pour les slash commands, l’idée est d’automatiser les workflows les plus courants présents dans la majorité des PR

Utilisation du hook PostToolUse pour gérer le formatage du code produit par Claude
Claude génère déjà du code bien formaté par défaut, et le hook s’occupe des 10 % restants, évitant plus tard des erreurs de formatage en CI

Il n’utilise pas --dangerously-skip-permissions
À la place, il utilise /permissions pour préautoriser les commandes bash courantes connues comme sûres dans l’environnement
Cela permet d’éviter les prompts de permission inutiles
La configuration est en grande partie versionnée dans .claude/settings.json et partagée avec l’équipe

Claude Code utilise lui-même tous les outils
- Recherche et publication sur Slack (via un serveur MCP)
- Exécution de requêtes BigQuery (avec la CLI bq) pour répondre à des questions d’analyse
- Récupération des logs d’erreur dans Sentry
La configuration Slack MCP est versionnée dans .mcp.json et partagée avec l’équipe

Pour les travaux très longs, il choisit entre trois méthodes :
- (a) demander qu’un agent en arrière-plan vérifie le travail une fois terminé
- (b) utiliser le hook Agent Stop pour une vérification plus déterministe
- (c) utiliser le plugin ralph-wiggum conçu par Geoffrey Huntley
Dans un sandbox, il configure --permission-mode=dontAsk ou --dangerously-skip-permissions afin que Claude reste concentré sur la tâche sans prompts de permission

L’élément le plus important pour obtenir d’excellents résultats avec Claude Code : donner à Claude un moyen de vérifier son travail
Avec cette boucle de rétroaction, la qualité du résultat final s’améliore de 2 à 3 fois
Il teste tous les changements destinés à arriver sur claude.ai/code avec l’extension Chrome Claude
- En ouvrant le navigateur, en testant l’interface, puis en itérant jusqu’à ce que le code fonctionne et que l’UX soit satisfaisante
La méthode de vérification varie selon le domaine
- Cela peut être aussi simple que l’exécution d’une commande bash
- L’exécution d’une suite de tests
- Ou le test de l’application dans un navigateur ou un simulateur de téléphone
Il faut investir pour construire solidement ce processus de vérification