Boris Cherny ne prompte plus Claude.
Ce n'est pas une paraphrase virale. C'est sa propre déclaration, publique et vérifiable : « Je ne prompte plus Claude. J'ai des boucles qui tournent, qui promptent Claude et décident de la suite. Mon travail, c'est d'écrire des boucles. » Il l'a répété à plusieurs reprises en public — une conférence Sequoia, un entretien chez Acquired, la Startup School de Y Combinator — et le schéma sous-jacent est le véritable sujet de cet article. Pas des astuces. Pas une liste de fonctionnalités. La manière précise dont la personne qui a construit Claude Code l'utilise réellement, au quotidien, vérifiée à partir de ses propres déclarations publiques plutôt que de paraphrases de seconde main.
Voici l'analyse complète, fondée sur ce que Cherny a réellement dit, ainsi que sur les bonnes pratiques documentées par Anthropic pour l'outil qu'il a lui-même créé.
Claude Code n'a jamais été conçu pour être un produit
Comprendre comment Cherny utilise l'outil commence par comprendre d'où il vient, car l'origine explique la philosophie — et c'est une histoire plus intéressante que ce que la plupart des utilisateurs actuels imaginent.
Claude Code a commencé en 2021 comme un projet de recherche sur l'alignement de l'IA, pas comme un produit. Une extension VS Code rudimentaire, puis un outil CLI interne appelé clide, utilisé chez Anthropic pendant des années avant que quiconque en dehors de l'entreprise n'en entende parler. Cherny a rejoint le projet en septembre 2024 et a reconstruit le cœur de l'outil en deux semaines de sprint intense en décembre de la même année. Le lancement public de février 2025 s'est fait en douceur, sans grande fanfare, accueilli davantage par un haussement d'épaules que par l'enthousiasme. Puis Claude 4 est sorti, et l'adoption a explosé presque du jour au lendemain.
Son propre constat sur l'état actuel de l'outil, énoncé sans détour : « Nous n'en sommes qu'à 1 %. »
Ce cadrage importe pour la manière dont vous devriez aborder son utilisation. Cherny ne décrit pas un produit fini avec un mode d'emploi figé. Il décrit quelque chose qui est encore activement reconstruit, par une équipe qui utilise l'outil pour construire l'outil. Claude Code a été réécrit à maintes reprises en utilisant Claude Code lui-même, une boucle d'auto-amélioration qui précède de loin l'existence du terme « loop engineering » dans le vocabulaire public. Cela mérite qu'on s'y attarde un instant, car cela explique quelque chose qui déroute beaucoup de nouveaux utilisateurs : pourquoi la « bonne » façon d'utiliser cet outil semble constamment évoluer. Ce n'est pas de l'incohérence. C'est un outil dont les créateurs eux-mêmes découvrent encore activement les capacités réelles, en temps réel, en utilisant l'outil pour le découvrir.
Les années passées comme outil de recherche interne avant de devenir un produit expliquent aussi pourquoi une grande partie de la philosophie ci-dessous semble étonnamment tranchée pour un logiciel destiné aux développeurs. La plupart des outils accumulent des fonctionnalités pour satisfaire dès le premier jour une base d'utilisateurs externe aux besoins concurrents. Claude Code a d'abord accumulé sa philosophie, au sein d'une petite équipe résolvant ses propres problèmes, avant d'avoir à s'adapter au flux de travail de qui que ce soit d'autre. Cette histoire explique précisément pourquoi comprendre les schémas d'utilisation de Cherny lui-même, plutôt que de se contenter de conseils génériques sur les « outils de codage IA », vaut le temps qu'il faut pour vraiment les assimiler.
Le changement fondamental : du prompt à la conception de boucles
La chose la plus importante que Cherny ait dite publiquement sur l'utilisation réelle de Claude Code, c'est sa déclaration sur les boucles — et il vaut la peine de décortiquer ce que cela signifie concrètement, pas seulement comme une phrase qu'on cite.
Un prompt est une instruction unique, envoyée une fois, à laquelle on répond une fois. Une boucle est un système : elle interroge Claude, évalue la réponse, décide de la suite, et recommence, sans qu'un humain soit assis au milieu de chaque cycle. La description de poste de Cherny — « mon travail, c'est d'écrire des boucles » — signifie qu'il passe son temps à concevoir les systèmes qui génèrent et évaluent les prompts, plutôt qu'à taper lui-même des prompts tour après tour.
Son flux de travail quotidien confirmé reflète directement cette approche. Un téléphone comme interface principale, pas un clavier d'ordinateur portable. Cinq à dix sessions actives simultanément, chacune capable de lancer des sous-agents — parfois quelques centaines d'un coup, parfois plusieurs milliers pendant la nuit pour les travaux plus profonds. Des dizaines de boucles tournant en continu en arrière-plan, surveillant les pull requests, maintenant l'intégration continue en bonne santé, regroupant les retours selon un calendrier récurrent. Des routines qui persistent côté serveur même lorsque son ordinateur portable est fermé.
Ce qu'il faut en retenir pour toute personne utilisant Claude Code au quotidien : le plafond de ce que l'outil peut accomplir n'est pas fixé par la qualité d'un seul prompt. Il est fixé par la qualité de conception du système autour de cycles automatisés et répétés de prompts, de vérifications et de nouvelles tentatives.
Ce qui a réellement changé dans le system prompt, et pourquoi c'est important
Cherny s'est également exprimé directement sur une décision technique précise qui révèle sa façon de penser l'instruction de Claude : « Nous avons supprimé environ 80 % du system prompt de Claude Code pour nos modèles les plus récents — voici ce que nous avons appris sur la rédaction de system prompts. »
Cette coupe a eu lieu précisément avec la génération Opus 4.8, réduisant le system prompt d'environ 15 000 caractères à environ 4 500, sans perte mesurable sur les évaluations de codage. La leçon derrière ce choix, selon les recommandations propres d'Anthropic en matière d'ingénierie de contexte, c'est que les listes de règles rigides et exhaustives cessent d'être nécessaires dès lors qu'un modèle est assez capable pour exercer un véritable jugement. Les règles deviennent des décisions discrétionnaires. Les exemples d'utilisation d'outils sont remplacés par des interfaces conçues pour être auto-documentées. Le contexte exhaustif fourni d'avance est remplacé par la divulgation progressive : l'information n'apparaît que lorsqu'une situation spécifique l'exige réellement, plutôt que d'être chargée par défaut dans chaque session.
Une nuance mérite d'être rapportée honnêtement, car elle complique la version simpliste de cette histoire : lorsque Opus 5 est sorti, des tests indépendants de développeurs ont constaté que son system prompt réel était environ 72 % plus long que celui d'Opus 4.8. Ce n'est pas une contradiction de la leçon ci-dessus, c'en est une version plus profonde. Le prompt a diminué en volume d'instructions rigides, puis a augmenté à nouveau en références plus riches et plus spécifiques : exemples travaillés, suites de tests, grilles d'évaluation — le genre de contexte dont un modèle réellement plus capable peut faire bon usage. La conclusion n'est pas « plus court est toujours mieux ». C'est que le volume d'instructions doit suivre ce dont le modèle spécifique a réellement besoin pour exercer un bon jugement, et non pas une cible fixe dans un sens ou dans l'autre.
Rédiger un CLAUDE.md comme les équipes d'Anthropic
Cela rejoint directement la façon dont vous devriez structurer vos propres instructions au niveau du projet. La documentation officielle d'Anthropic est explicite sur le modèle mental à adopter : considérez Claude comme un employé brillant mais tout nouveau, amnésique, qui a besoin d'instructions explicites.
Les implications pratiques de ce cadrage. Brillant signifie que vous n'avez pas besoin de sur-expliquer les compétences générales — elles sont déjà là. Nouveau signifie zéro connaissance accumulée sur l'historique ou les conventions de votre projet. Amnésique signifie que chaque session repart de zéro ; le CLAUDE.md est la seule chose qui transmet de manière fiable le contexte entre les sessions.
Les recommandations documentées d'Anthropic visent à maintenir ce fichier sous les 200 lignes, certaines des équipes les plus disciplinées descendant à 60. Le test pour savoir si quelque chose a sa place dans le fichier : est-ce réellement pertinent pour presque toutes les sessions, ou seulement pour une partie étroite et situationnelle du travail ? Les éléments universels — commandes de build, règles de style non négociables, attentes de test, véritables garde-fous — ont leur place dans le fichier racine. Tout ce qui est plus spécifique doit aller dans un fichier importé, chargé dans le contexte uniquement lorsque le travail de la session l'exige, via la syntaxe d'import @path/to/file que l'outil prend directement en charge.
Pour les instructions qui ne peuvent vraiment pas être ignorées, la pratique interne d'Anthropic utilise des marqueurs d'emphase explicites — « IMPORTANT » ou « YOU MUST » — réservés spécifiquement à la poignée de règles où le coût d'un oubli par Claude est réellement élevé. Tout marquer de cette façon détruit complètement l'objectif, car cela cesse de fonctionner comme un signal dès que c'est appliqué sans discernement.
Plan Mode : comprendre avant d'agir
Un modèle de comportement spécifique qu'il vaut la peine d'intégrer dans votre façon de travailler avec l'outil : faire planifier Claude avant qu'il n'exécute, plutôt que de se lancer directement dans les modifications.
Ce n'est pas qu'un simple interrupteur de fonctionnalité — cela reflète un véritable changement que décrivent les propres documents d'Anthropic : les modèles plus récents planifient correctement sans avoir besoin du guidage initial intensif que nécessitaient les modèles précédents, au point que certaines équipes rapportent ne plus avoir besoin de forcer une étape explicite de plan mode pour chaque tâche, parce que le raisonnement par défaut du modèle produit déjà un plan cohérent avant d'agir. Cela dit, pour les modifications vraiment complexes, multi-fichiers, demander explicitement un plan d'abord — et le relire avant d'approuver l'exécution — reste un point de contrôle utile, qui permet de rattraper une exigence mal comprise avant qu'elle ne se propage à travers une douzaine de modifications de fichiers plutôt qu'après.
Sous-agents et travail en parallèle
Le flux de travail confirmé de Cherny — des centaines, parfois des milliers de sous-agents dans une seule session — pointe vers une capacité structurelle qu'il vaut la peine de comprendre et d'utiliser délibérément plutôt que par accident.
Un agent principal peut décomposer une tâche complexe en morceaux plus petits et déployer des sous-agents pour les exécuter indépendamment, chacun travaillant dans son propre contexte plutôt que de se disputer l'espace d'une seule conversation continue. Cela sert deux objectifs à la fois. Cela permet à un travail qui déborderait d'une fenêtre de contexte unique de s'exécuter sur plusieurs fenêtres plus petites. Et cela ajoute une véritable couche de vérification, puisqu'un sous-agent qui relit la production d'un autre agent vérifie un travail qu'il n'a pas lui-même produit — ce qui est structurellement plus fiable qu'un agent qui note son propre travail dans le même souffle qui l'a produit.
Pour le travail en parallèle spécifiquement, les worktrees git permettent à plusieurs sessions de travailler simultanément sur des branches ou des répertoires distincts, sans que les modifications en cours d'une session ne perturbent celles d'une autre. C'est l'infrastructure mécanique qui sous-tend l'exécution de nombreuses boucles concurrentes comme Cherny décrit le faire personnellement : non pas un seul agent qui va plus vite, mais de nombreux agents travaillant simultanément sur des morceaux de travail réellement séparés.
La décision grep : une étude de cas sur la simplicité plutôt que l'ingéniosité
Une décision technique spécifique et bien documentée de l'équipe de Cherny illustre une philosophie plus large qu'il vaut la peine d'intérioriser. Claude Code a abandonné la recherche vectorielle et les embeddings pour la recherche dans le codebase au profit du bon vieux grep et de glob. Ses propres mots sur le résultat : « a surpassé tout le reste. De très loin. »
La leçon dépasse cette décision particulière. Une solution à la sonorité plus sophistiquée — la recherche vectorielle sémantique — n'est pas automatiquement meilleure qu'une solution plus simple — grep — si la plus simple est en réalité bien adaptée au problème. Les codebases ont une syntaxe exacte, des noms de fonctions exacts, des chemins d'importation exacts — le genre de correspondance précise et littérale dans laquelle grep excelle et qu'une correspondance sémantique floue peut en réalité compromettre en faisant remonter des résultats plausibles mais faux.
Ce qu'il faut retenir pour configurer vos propres flux de travail : ne partez pas par défaut de l'outil ou de l'architecture au nom le plus complexe, en supposant que la complexité implique la capacité. Testez d'abord l'option simple sur votre cas d'utilisation réel. Souvent, elle gagne — et même quand ce n'est pas le cas, vous avez confirmé que l'approche complexe mérite sa place plutôt que de l'avoir présumé.
Ne laissez jamais un agent évaluer son propre travail
Un autre principe confirmé, issu de la pratique d'ingénierie du harness chez Anthropic, directement pertinent pour structurer toute étape de vérification dans vos propres flux de travail Claude Code : la génération et l'évaluation doivent se faire dans des rôles réellement séparés, car un modèle qui relit sa propre production dans le même souffle qui l'a produite a tendance à dériver vers le positif, même lorsqu'un relecteur humain repérerait immédiatement le défaut.
Concrètement, cela signifie que l'agent qui écrit le code ne devrait pas être le même passage qui décide si ce code est suffisamment bon pour être livré. Une étape d'évaluation séparée — idéalement avec accès à quelque chose que l'agent générateur n'avait pas, comme la sortie réelle de la suite de tests ou le document d'exigences d'origine — attrape ce que l'auto-évaluation manque. C'est le même principe qui sous-tend le modèle de vérification par sous-agents ci-dessus, appliqué comme une discipline générale plutôt que comme une fonctionnalité spécifique.
Gestion de l'effort et du contexte
Pour ceux qui exécutent des sessions plus longues et plus exigeantes, comprendre comment signaler directement le niveau d'effort est important. Inclure « ultrathink » dans un prompt signale une profondeur de raisonnement maximale pour cette réponse spécifique, sans modifier les paramètres généraux de la session. Pour une orchestration automatique du flux de travail au niveau de la session, régler le niveau d'effort sur son palier le plus élevé combine un raisonnement profond avec une décomposition automatique des tâches sur l'ensemble d'une session — mais cela nécessite un modèle qui prend réellement en charge ce palier d'effort ; tous les modèles d'une gamme donnée ne le font pas.
La gestion du contexte mérite elle aussi une attention délibérée lors des longues sessions. Plus une session dure, plus le contexte accumulé peut diluer le signal de ce qui compte réellement à l'instant T — le même problème que créent les fichiers CLAUDE.md gonflés, mais qui se produit dynamiquement au sein d'une seule conversation plutôt que statiquement dans un fichier. Ouvrir périodiquement une nouvelle session pour une phase de travail réellement nouvelle, plutôt que de prolonger indéfiniment une conversation, est une discipline pratique réelle qui vaut la peine d'être appliquée, au lieu de supposer que plus de contexte est toujours strictement mieux.
Un exemple concret : application à une tâche réelle
Pour rendre tout ce qui précède concret plutôt qu'abstrait, voici comment ces principes se combinent réellement sur une tâche réelle et courante : ajouter une nouvelle fonctionnalité à un codebase existant avec une complexité raisonnable — quelques fichiers interconnectés, des tests existants, un changement non trivial mais pas exotique.
Commencez avec le CLAUDE.md déjà en place, court, universel, les commandes de build et de test, les règles de style non négociables, rien de situationnel qui l'encombre. Cela signifie que la session démarre avec un contexte réel et pertinent chargé automatiquement, sans que vous ayez à réexpliquer à nouveau les conventions de votre projet.
Plutôt que d'écrire un seul long prompt plein d'espoir décrivant la fonctionnalité entière dans un détail exhaustif, décrivez l'objectif et laissez la planification du modèle gérer la décomposition — en vous fiant à la philosophie de réduction de l'échafaudage évoquée dans la discussion sur le system prompt ci-dessus. Pour une tâche de cette taille, demander explicitement un plan d'abord vaut l'étape supplémentaire, car une exigence mal comprise attrapée ici coûte une correction de deux minutes au lieu d'une heure à défaire des modifications sur plusieurs fichiers plus tard.
Une fois le plan validé, laissez l'exécution se dérouler. Si la tâche se divise naturellement en morceaux réellement indépendants — mettre à jour un modèle de données et, séparément, mettre à jour l'interface utilisateur qui le consomme, par exemple — c'est un candidat naturel pour la décomposition en sous-agents, chaque morceau travaillant dans son propre contexte plutôt que tout s'entassant dans une seule conversation continue.
Avant de considérer le résultat comme terminé, exécutez un passage de vérification séparé plutôt que de vous fier à l'auto-évaluation de l'agent qui a implémenté. Cela peut être aussi simple qu'une nouvelle session, ou un sous-agent en lecture seule, qui vérifie la sortie réelle des tests et le diff par rapport au plan d'origine — sans simplement accepter un « c'est terminé » confiant venant du même contexte qui a écrit le code.
Remarquez ce qui est absent de cette démonstration. Aucun outil exotique. Aucune configuration inhabituelle. Juste l'application ordinaire de la planification d'abord pour les travaux vraiment complexes, de la décomposition en sous-agents pour les morceaux réellement indépendants, et de la vérification séparée au lieu de l'auto-évaluation — les trois mêmes principes qui traversent tout ce qui précède, appliqués à une tâche concrète plutôt que décrits de manière abstraite.
Passer à l'échelle au-delà d'une seule personne
Tout ce qui précède décrit des pratiques pour une personne qui utilise Claude Code de manière délibérée. Le flux de travail confirmé de Cherny — des centaines de sous-agents par jour, des milliers pendant la nuit — est déjà en soi une forme de passage à l'échelle : une personne qui dirige une quantité réellement importante de travail parallèle et automatisé. Mais les mêmes principes s'étendent à une équipe qui adopte ces pratiques ensemble, avec quelques considérations spécifiques qui méritent d'être nommées directement.
Le CLAUDE.md cesse d'être un fichier de préférences personnelles dès lors que plus d'une personne sur une équipe travaille réellement sur le même codebase avec Claude Code. Traitez les modifications qui y sont apportées avec la même discipline de relecture que vous appliqueriez à toute configuration partagée affectant le flux de travail de toute l'équipe. Un collègue qui ajoute une instruction « correction rapide » ponctuelle après une session frustrante, sans relecture, est exactement le mécanisme qui produit les fichiers gonflés et auto-contradictoires qu'on finit par ne plus suivre de manière fiable. Une étape de relecture légère — ne serait-ce qu'une deuxième personne qui jette un œil au diff avant la fusion — attrape une part significative de ces dérives avant qu'elles ne s'accumulent en un véritable problème.
La discipline de vérification compte encore plus à l'échelle de l'équipe que pour un utilisateur solo. Quand une seule personne écrit et relit à la fois son propre travail assisté par agent, il y a au moins une chance qu'elle attrape personnellement quelque chose que l'agent a manqué. Quand une équipe s'appuie sur la production de Claude Code qui transite par un processus de relecture partagé, le principe d'évaluation séparée évoqué plus tôt n'est plus optionnel — c'est le mécanisme réel qui protège le codebase d'une auto-évaluation confiante mais erronée qui atteindrait la production, puisque l'alternative consiste à espérer qu'un humain, à un moment donné dans le flux de travail chargé d'une équipe, attrape ce que l'agent n'a pas signalé lui-même.
Il vaut également la peine d'établir une propriété explicite des audits périodiques du CLAUDE.md — la même discipline de maintenance recommandée pour tout document partagé qui s'accumule. Sans propriétaire clairement désigné, ce travail tend à passer entre les mailles du filet précisément parce qu'il ne bloque aucune tâche immédiate comme le ferait un build cassé — et six mois d'ajouts sans propriétaire produisent exactement le genre de fichier gonflé et contradictoire que le principe d'applicabilité universelle existe justement pour empêcher.
Là où les gens appliquent mal ces principes
Une poignée de lectures erronées des idées ci-dessus revient régulièrement ; il vaut la peine de les nommer directement, car chacune a une correction simple et spécifique.
Considérer « des boucles plutôt que des prompts » comme une licence pour ne pas comprendre la tâche du tout. La déclaration de Cherny est que son travail consiste à écrire des boucles, pas qu'il a cessé de réfléchir à ce que ces boucles devraient réellement faire. Concevoir une bonne boucle — une bonne définition du succès, une bonne condition d'arrêt — exige toujours de comprendre le problème aussi clairement que l'écriture d'un bon prompt unique. La boucle remplace la frappe manuelle répétée, pas la réflexion initiale.
Interpréter la réduction du system prompt comme « donnez toujours moins de contexte au modèle ». Le contre-exemple d'Opus 5 plus haut dans cet article existe précisément pour corriger cette lecture erronée. La véritable leçon est que le volume d'instructions doit correspondre à ce dont un modèle spécifique a réellement besoin pour exercer un bon jugement — ce qui signifie parfois moins de listes de règles rigides et parfois plus de matériel de référence riche et spécifique. Réduire le contexte sans discernement parce que « les modèles les plus récents ont besoin de moins » applique une découverte nuancée et spécifique à un modèle comme une règle universelle.
Sur-décomposer les tâches simples en sous-agents par habitude. La décomposition en sous-agents mérite sa complexité sur des morceaux de travail réellement vastes et réellement indépendants. Diviser un petit changement étroitement couplé en morceaux artificiels juste pour utiliser le motif ajoute des frais de coordination sans le bénéfice qui la justifie sur les grandes tâches. L'exemple concret plus haut dans cet article a délibérément utilisé des sous-agents uniquement là où les morceaux étaient naturellement indépendants, pas comme un défaut pour chaque tâche quelle que soit sa taille.
Sauter la vérification en supposant que « les modèles les plus récents n'en ont plus besoin ». Le principe d'évaluation séparée n'est pas un contournement pour les modèles plus faibles qui deviendra inutile à mesure que les capacités s'améliorent. C'est un fait structurel sur l'auto-évaluation : un modèle qui vérifie son propre travail dans le même contexte qui l'a produit aura toujours plus de mal à repérer ses propres angles morts qu'une vérification indépendante, quelle que soit la capacité du modèle sous-jacent. C'est aussi vrai pour les relecteurs humains, et cela ne cesse pas d'être vrai parce que le relecteur devient plus intelligent.
Les habitudes quotidiennes réelles qui valent la peine d'être adoptées
En rassemblant tout ce qui précède en une pratique quotidienne concrète, voici à quoi ressemble le fait de suivre réellement l'approche démontrée par Cherny.
Cessez de traiter chaque tâche comme un prompt unique à réussir du premier coup. Concevez plutôt une boucle : un agent qui tente la tâche, un moyen de vérifier si la tentative a réussi, et un chemin défini pour la suite selon le résultat — réussite, nouvelle tentative, ou escalade directe vers vous.
Gardez votre CLAUDE.md court et traitez-le comme un support d'intégration pour une nouvelle recrue compétente mais sans contexte, pas comme un manuel exhaustif. Déplacez tout ce qui est situationnel dans des fichiers importés plutôt que de gonfler le document racine.
Utilisez le plan mode délibérément pour les travaux vraiment complexes et multi-fichiers, et faites confiance à la planification par défaut du modèle pour les tâches plus simples et bien cadrées, plutôt que d'imposer une étape supplémentaire partout par habitude.
Décomposez les grandes tâches en sous-agents travaillant dans des contextes séparés plutôt que d'essayer de contenir toute une tâche complexe dans une seule conversation continue. Utilisez un passage séparé pour vérifier le travail important plutôt que de vous fier à l'auto-évaluation d'un seul agent.
Optez par défaut pour l'outil le plus simple qui pourrait raisonnablement résoudre votre problème spécifique — comme grep a battu la recherche vectorielle pour ce cas d'usage exact — et n'allez vers plus de complexité qu'une fois que l'option simple a réellement été testée et trouvée insuffisante.
Construisez un véritable parallélisme dans votre flux de travail en utilisant les worktrees git pour les morceaux de travail réellement indépendants, plutôt que de tout faire passer par une seule session séquentielle parce que c'est le mode de travail par défaut.
Où tout cela mène réellement
Le cadrage de Cherny — « nous n'en sommes qu'à 1 % » — mérite d'être pris au sérieux comme une déclaration pratique, pas seulement comme une formule d'humilité. Les schémas spécifiques décrits ci-dessus — la conception de boucles plutôt que le prompt unique, l'élagage agressif du system prompt à mesure que les modèles deviennent plus capables, la décomposition en sous-agents, la vérification séparée — ne sont pas une méthodologie finale et figée. Ce sont l'état actuel d'un outil et d'une pratique que son propre créateur décrit comme encore à leurs débuts.
La compétence réelle qui vaut la peine d'être développée n'est pas de mémoriser la configuration actuelle des bonnes pratiques. C'est de comprendre suffisamment les principes sous-jacents pour continuer à s'adapter à mesure que l'outil lui-même évolue — de la même manière que l'équipe de Cherny a reconstruit Claude Code à plusieurs reprises en utilisant Claude Code, en affinant la boucle plutôt qu'en traitant une version particulière comme terminée.
C'est le vrai fil conducteur qui relie tout dans cet article. Pas une liste statique d'astuces, mais une philosophie de travail : concevoir des systèmes plutôt que taper des instructions isolées, garder les instructions légères et laisser la capacité du modèle faire davantage le travail à mesure qu'elle s'améliore, vérifier indépendamment plutôt que de se fier à l'auto-évaluation, et opter pour la simplicité jusqu'à ce que la complexité prouve réellement sa nécessité. Directement inspiré de la façon dont la personne qui a construit l'outil l'utilise lui-même.
Suivez @cyrilXBT pour d'autres analyses de Claude Code fondées sur des sources vérifiées et publiques.
