Je fais tourner 15 clones IA de moi-même en parallèle — et ce n'est même pas ma forme finale

« Mais Opus est plus lent ! » hurle la voix intérieure de chaque développeur qui a déjà benchmarké des temps de réponse.

L'argument de Boris ? Les maths fonctionnent différemment quand on prend en compte le temps humain :

Sonnet (modèle plus rapide) :
Requête : 30 secondes
× 5 itérations (direction, correction)
= 2,5 minutes + votre santé mentale

Opus (modèle plus lent) :
Requête : 2 minutes
× 1 itération (fait bien du premier coup)
= 2 minutes + votre santé mentale intacte

L'insight clé : le goulot d'étranglement n'est pas le temps de traitement de l'IA — c'est le temps humain passé à diriger et corriger. Opus nécessite moins de main-holding, prend de meilleures décisions d'utilisation d'outils, et généralement n'a pas besoin qu'on lui dise « non, pas comme ça » dix-sept fois par tâche.

C'est comme la différence entre un développeur junior qui est rapide mais a besoin de revue de code constante, versus un senior qui est plus lent mais livre du code prêt pour la production. Sauf que le senior est une IA et vous pouvez en faire tourner quinze en parallèle.

CLAUDE.md : La Mémoire Collective de Votre Base de Code

C'est là que ça devient vraiment brillant.

L'équipe Claude Code maintient un seul fichier CLAUDE.md, commité dans git, auquel toute l'équipe contribue plusieurs fois par semaine. Pensez-y comme un document vivant qui capture chaque leçon « ne fais pas ça » que Claude apprend.

Claude fait une erreur →
Le développeur remarque →
Ajouter le pattern à CLAUDE.md →
Commit dans git →
Claude le lit à la session suivante →
Claude ne refait plus jamais cette erreur

C'est comme avoir un nouveau développeur qui n'oublie jamais rien de ce qu'on lui dit et partage cette connaissance avec toutes les autres instances de lui-même à travers le temps et l'espace.

Que Met-on Dans CLAUDE.md ?

Boris a révélé les specs réelles : leur CLAUDE.md fait 2,5k tokens et couvre :

- Commandes bash courantes
- Conventions de style de code
- Guidelines de design UI et contenu
- Comment faire la gestion d'état, logging, gestion d'erreurs, gating, et debugging
- Template de pull request

C'est tout. Pas un roman — un document de référence focalisé.

## Structure du Projet
- /src contient le code applicatif
- /tests reflète la structure de /src

## Commandes Courantes
- npm run build: Construire le projet
- npm run test: Lancer la suite de tests
- npm run lint: Lancer le linter avec auto-fix

## Nos Conventions
- On utilise le mode strict TypeScript partout
- Préférer const à let, toujours
- Les noms de fonction doivent être des verbes

## Choses Que Claude a Mal Faites Avant
- N'utilise pas les APIs dépréciées (voici la liste...)
- Ne modifie jamais le répertoire .claude/ directement
- Lance toujours les tests avant de suggérer un commit

L'équipe utilise même une GitHub Action pour automatiquement taguer @.claude pendant les revues de code, lui demandant de mettre à jour le CLAUDE.md basé sur les patterns trouvés dans les PRs. Chaque revue de code devient une opportunité d'apprentissage qui se compose au fil du temps.

Comme l'a noté un observateur : « Chaque erreur devient une règle. Plus longtemps l'équipe travaille ensemble, plus l'agent devient intelligent. »

C'est basiquement du RLHF, mais conduit par toute votre équipe d'ingénierie à travers les revues de code.

Le Workflow en Deux Phases : Penser D'abord, Livrer Ensuite

Boris ne fait pas juste du yolo à travers ses prompts. Il a développé une approche disciplinée en deux phases :

Phase 1 : Mode Plan (Interactif)

[Shift+Tab][Shift+Tab] — entre en mode Plan

Vous : « J'ai besoin d'ajouter l'authentification OAuth »

Claude : « Voici mon plan :
1. Installer passport-oauth2
2. Créer le fichier de config OAuth
3. Ajouter les routes /auth/login et /auth/callback
4. Mettre à jour le modèle utilisateur pour les données OAuth
5. Créer le middleware d'auth
6. Mettre à jour le frontend avec le bouton de connexion
7. Ajouter les tests »

Vous : « Ça a l'air bien, mais ajoute aussi les refresh tokens »

Claude : *met à jour le plan*

Phase 2 : Mode Exécution (Autonome)

Une fois le plan approuvé, Boris passe en mode auto-accept. Claude exécute alors tout le plan, souvent d'un coup.

La philosophie est simple : investir du temps en amont dans la planification, économiser beaucoup plus de temps dans l'exécution. C'est la version alimentée par l'IA de l'adage du charpentier : mesurer deux fois, couper une fois. Sauf qu'ici c'est : planifier interactivement, coder de manière autonome.

Un bon plan est vraiment important, insiste Boris. Et il a raison — un plan bien structuré signifie que Claude peut enchaîner des dizaines d'éditions de fichiers sans avoir besoin d'intervention humaine à chaque étape.

Commandes Slash : Parce Que Taper C'est Pour les Gens Qui Ont du Temps

Boris a clarifié dans les commentaires : « Skills = commandes slash, je les utilise de manière interchangeable. » Même chose, noms différents.

Boris a automatisé chaque workflow de « boucle interne » en commandes slash qui vivent dans .claude/commands/ :

---
description: Commiter les changements, pusher vers remote, et créer PR
---

# Git Status
!`git status --short`

# Branche Actuelle
!`git branch --show-current`

# Commits Récents
!`git log -5 --oneline`

Basé sur le git status ci-dessus :
1. Stager et commiter les changements avec un message descriptif
2. Pusher vers remote
3. Créer PR avec titre et description clairs
4. Demander review aux membres d'équipe appropriés

Le bash inline (ces commandes !) pré-calcule le contexte donc Claude n'a pas besoin de demander. Il voit le git status, connaît la branche actuelle, comprend l'historique récent — et peut prendre des décisions intelligentes immédiatement.

Boris utilise /commit-push-pr des dizaines de fois chaque jour. C'est des dizaines de workflows git multi-étapes réduits à sept frappes de touches.

Autres commandes de sa configuration :

• /quick-commit — Stager tout et commiter avec message auto-généré
• /test-and-fix — Lancer les tests, corriger les échecs, répéter jusqu'au vert
• /review-changes — Revoir les changements non commités et suggérer des améliorations
• /first-principles — Déconstruire les problèmes en vérités fondamentales

Celles-ci sont commitées dans git et partagées à travers l'équipe. Tout le monde bénéficie des optimisations de workflow de chacun.

Sous-agents : Collègues IA Spécialisés

Au-delà des commandes slash, Boris utilise des sous-agents — assistants IA spécialisés avec leurs propres prompts système, accès aux outils, et fenêtres de contexte séparées.

AgentObjectifcode-simplifierSimplifie le code après que Claude ait fini de travaillerverify-appTeste minutieusement que l'application fonctionne correctementcode-architectRevues de design et décisions architecturalesbuild-validatorS'assure que le projet se construit correctement pour le déploiementoncall-guideAide à diagnostiquer et résoudre les problèmes de production

Pensez-y comme des experts spécialisés que vous pouvez appeler pour des tâches spécifiques. Le code-simplifier tourne après chaque feature pour réduire la complexité. L'agent verify-app a des instructions détaillées pour tester Claude Code de bout en bout.

La différence clé avec les commandes slash : les sous-agents ont leur propre fenêtre de contexte, donc ils ne polluent pas votre conversation principale. Ce sont vraiment des travailleurs séparés qui gèrent des jobs spécifiques.

Hooks : La Couche d'Automatisation Ultime

Claude Code supporte les hooks — actions automatisées qui tournent à des points spécifiques du workflow. Boris utilise un hook PostToolUse pour auto-formater le code :

{
"hooks": {
"PostToolUse": [{
"matcher": "Edit|Write",
"hooks": [{
"type": "command",
"command": "npx prettier --write \"$CLAUDE_FILE_PATH\""
}]
}]
}
}

Chaque fois que Claude édite ou écrit un fichier, Prettier le formate automatiquement. Cela attrape les derniers 10% de problèmes de formatage, évitant les échecs CI sans aucune intervention humaine.

Sans hook :

Claude écrit du code → Push vers PR → CI échoue sur le formatage →
Corriger le formatage → Push à nouveau → CI passe

Avec hook :

Claude écrit du code → Hook formate → Push vers PR → CI passe ✓

C'est la différence entre nettoyer après votre aspirateur robot et avoir un robot qui nettoie après lui-même.

Le Système de Permissions : Sécurité Sans Friction

Boris évite explicitement --dangerously-skip-permissions. À la place, il utilise /permissions pour pré-autoriser des commandes sûres spécifiques :

{
"permissions": {
"allowedTools": {
"Bash": {
"allowedCommands": [
"git status",
"git diff",
"git commit",
"npm test",
"npm run build",
"npm run lint"
]
},
"Edit": { "allowed": true },
"Read": { "allowed": true }
}
}
}

Cela vous donne la commodité de l'auto-approbation pour les opérations que vous savez sûres, tout en nécessitant encore une permission explicite pour tout ce qui est inhabituel. C'est comme donner à votre IA un jeu de clés de maison au lieu des codes de lancement nucléaire.

Intégration MCP : La Connexion de Claude à Tout

Claude Code utilise MCP (Model Context Protocol) pour se connecter aux outils externes. La configuration de Boris inclut :

• Slack — Poster des mises à jour, notifications, chercher dans les conversations
• BigQuery — Lancer des requêtes analytics via CLI bq
• Sentry — Récupérer les logs d'erreur directement
• Simulateurs iOS/Android — pour la vérification d'apps mobiles (oui, il y a des MCPs pour ça)

{
"mcpServers": {
"slack": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-slack"],
"env": {
"SLACK_BOT_TOKEN": "xoxb-...",
"SLACK_TEAM_ID": "T..."
}
}
}
}

Maintenant Claude peut faire des choses comme :

> Déployer en staging et notifier l'équipe dans #deployments

Claude : [Lance le déploiement]
Claude : [Utilise le serveur MCP Slack]
Claude : [Poste dans le canal #deployments]
✓ Déploiement terminé, équipe notifiée

Le fichier .mcp.json est commité dans git. Toute l'équipe obtient ces intégrations automatiquement.

La Méthode Ralph Wiggum : Pour Quand Vous Avez Besoin d'une IA Qui N'Abandonne Jamais

Pour les tâches très longues, Boris utilise quelque chose appelé le plugin Ralph Wiggum. Nommé d'après le personnage des Simpsons qui persiste joyeusement malgré tous les obstacles, il crée une boucle itérative qui maintient Claude en marche jusqu'à ce qu'une tâche soit vraiment terminée.

Le concept :

Itération 1 :
Claude : [Implémente l'API de base]
Claude : [Essaie de sortir]
Hook d'Arrêt : [Tests qui échouent - bloquer la sortie]
Hook d'Arrêt : [Renvoyer le même prompt]

Itération 2 :
Claude : [Voit les échecs de tests]
Claude : [Corrige les bugs]
Claude : [Essaie de sortir]
Hook d'Arrêt : [Certains tests échouent encore - bloquer la sortie]

Itération 3 :
Claude : [Corrige les bugs restants]
Claude : [Tous les tests passent]
Claude : [Sort COMPLETE]
Hook d'Arrêt : [Promesse de completion détectée - autoriser la sortie]
✓ Terminé !

Pour ces sessions autonomes de longue durée, Boris utilise soit --permission-mode=dontAsk soit --dangerously-skip-permissions — mais seulement dans des environnements sandboxés et isolés.

La Règle d'Or : Donnez à Claude une Boucle de Vérification

Voici le conseil le plus important de Boris, et il l'a gardé pour la fin :

Donnez à Claude un moyen de vérifier son travail. Si Claude a cette boucle de feedback, cela va multiplier par 2–3 la qualité du résultat final.

C'est la sauce secrète qui fait que tout le reste fonctionne.

Sans vérification :

Claude écrit du code → Pushe vers PR →
CI échoue → Bugs en production →
Debugging manuel requis

Avec vérification :

Claude écrit du code → Le teste →
Voit les échecs → Les corrige →
Reteste → Itère jusqu'à ce que ça passe →
Code de haute qualité

La vérification a l'air différente pour chaque domaine :

• Outils CLI : Lancer la commande, vérifier la sortie
• APIs : Faire des requêtes, vérifier les réponses
• UI : Utiliser l'extension Chrome de Claude pour tester visuellement
• Backend : Lancer la suite de tests, vérifier la couverture
• Apps mobiles : Utiliser les MCPs de simulateur iOS/Android pour tester sur appareil itère jusqu'à ce que le code fonctionne et que l'UX soit bonne.

Investissez pour rendre la vérification rock-solid. C'est la seule amélioration à plus fort effet de levier que vous puissiez apporter au développement assisté par IA.

La Stack Complète : Tout Ensemble

Voici la configuration complète de Boris en une vue :

1. 15+ Sessions Parallèles — Terminal, web, iOS
2. Opus 4.5 + Pensée Étendue — Meilleur modèle, plus rapide globalement
3. CLAUDE.md d'Équipe — Base de connaissances partagée, sous contrôle de version
4. GitHub Action — Auto-mise à jour de CLAUDE.md depuis les PRs
5. Mode Plan → Auto-Accept — Workflow en deux phases
6. Commandes Slash — Automatiser les workflows répétés
7. Sous-agents — Assistants IA spécialisés
8. Hook PostToolUse — Auto-formater le code
9. Permissions Intelligentes — Pré-autoriser les commandes sûres
10. Intégration MCP — Se connecter à Slack, BigQuery, Sentry
11. Ralph Wiggum — Boucles itératives pour les tâches longues
12. Vérification — Le plus important : boucles de feedback partout

Ce Que Cela Signifie Pour le Reste d'Entre Nous

La réaction au thread de Boris a été… intense.

« Si vous ne lisez pas les meilleures pratiques Claude Code directement de son créateur, vous êtes en retard en tant que programmeur, » a écrit un observateur de l'industrie.

« C'est potentiellement leur moment ChatGPT, » a déclaré un autre.

L'excitation vient d'un paradoxe : le workflow de Boris est étonnamment simple, pourtant il permet à un seul humain d'opérer avec la capacité de sortie d'un petit département d'ingénierie.

Dans les trente derniers jours, Boris a landé 259 PRs — 497 commits, 40k lignes ajoutées, 38k lignes supprimées. Chaque ligne a été écrite par Claude Code + Opus 4.5.

Ce n'est pas un workflow. C'est un multiplicateur de force.

Commencer (Sans Brûler Votre Maison)

Vous n'avez pas besoin d'implémenter tout d'un coup. Commencez petit :

1. Créez un CLAUDE.md — Documentez les conventions de votre projet
2. Configurez une commande slash — Automatisez quelque chose que vous faites quotidiennement
3. Ajoutez la vérification — Donnez à Claude un moyen de tester son travail
4. Configurez les permissions — Pré-autorisez les commandes sûres
5. Ajoutez un hook — Auto-formatez le code à la sauvegarde

Puis itérez. Ajoutez plus de commandes slash quand des patterns émergent. Créez des sous-agents pour les tâches spécialisées. Étendez vos intégrations MCP.

L'objectif n'est pas d'égaler la configuration de Boris — c'est de construire votre propre machine d'apprentissage composé qui s'améliore chaque jour.

Le Taux d'Échec Dont Personne ne Parle

Quand on lui a demandé quel pourcentage de sessions il abandonne, Boris a répondu : « Peut-être comme 10–20% ? »

Même le créateur de Claude Code n'a pas un taux de succès de 100%. Certaines sessions ne marchent juste pas. C'est normal. Les gains de productivité viennent des 80% qui fonctionnent.

Réflexions Finales

Ce que Boris a démontré n'est pas juste un hack de productivité. C'est un aperçu d'un modèle entièrement différent de développement logiciel.

Pendant des années, « le codage IA » signifiait autocomplétion — une façon plus rapide de taper. Ce que Boris montre c'est que l'IA peut maintenant fonctionner comme un système d'exploitation pour le travail lui-même.

« Lisez ceci si vous êtes déjà ingénieur et voulez plus de pouvoir, » a résumé un commentateur.

Les outils pour multiplier la production humaine par 5x sont là. Ils ne nécessitent qu'une volonté d'arrêter de penser à l'IA comme un assistant et commencer à la traiter comme une main-d'œuvre.

Les programmeurs qui font ce saut mental en premier ne seront pas juste plus productifs. Ils joueront un jeu entièrement différent.

Et tous les autres seront encore en train de taper.

Basé à l'origine sur le thread Twitter de Boris Cherny. Boris est le créateur et responsable de Claude Code chez Anthropic.

Ressources

• Documentation Claude Code
• Référence Commandes Slash
• Guide Sous-agents
• Guide Hooks
• Documentation MCP
• Plugin Ralph Wiggum
• Extension Chrome Claude
• Config de Boris (Repo Communautaire)

Si vous avez apprécié cette analyse, clappez 50 fois et suivez pour plus de plongées profondes dans le développement alimenté par l'IA. Vos récepteurs de dopamine vous remercieront.

Découvrez comment un développeur fait tourner 15 clones IA en parallèle, en utilisant une architecture intelligente qui évite les conflits de merge et optimise la productivité.

→ Rejoindre la newsletter de production AI