Faisons un peu le point sur l'histoire de la naissance de Claude Code, principalement basée sur un article du blogueur technologique Gergely Orosz qui a interviewé des membres clés de Claude Code. Claude Code est vraiment impressionnant, avec un revenu annuel de 500 millions de dollars, et en trois mois, le nombre d'utilisateurs a augmenté de 10 fois. C'est maintenant l'outil de choix pour de nombreux programmeurs en tant qu'agent de codage. Cet outil n'était au départ qu'un petit jouet en ligne de commande capable de te dire "quelle chanson tu écoutes en ce moment". 🧵

Gergely Orosz a interviewé trois membres clés de Claude Code : • L'ingénieur fondateur Boris Cherny (17 ans d'expérience, ancien ingénieur en chef chez Meta) • L'ingénieur numéro deux Sid Bidasaria (auteur de la fonctionnalité Subagents) • Et le chef de produit Cat Wu. Ils ont discuté de la manière dont Claude Code est passé du prototype au produit, des choix techniques qu'ils ont faits, et comment cette petite équipe d'une dizaine de personnes parvient à publier 5 PR par personne chaque jour. C'est peut-être l'échantillon le plus proche d'une "équipe d'ingénierie axée sur l'IA" que nous ayons actuellement. Ils utilisent l'IA pour écrire du code, rédiger des tests, effectuer des revues de code, déboguer, et même utiliser Claude Code pour développer Claude Code lui-même. 90 % du code est écrit par lui-même. Ce que je veux faire, c'est rassembler les parties les plus intéressantes de cette interview, parler de la façon dont cette équipe travaille, ce qu'il y a à en tirer, et ce qui est déterminé par leurs conditions particulières et ne peut pas être reproduit. Ci-dessous, cela se divise en 7 petites histoires, chacune pouvant être lue indépendamment, mais ensemble, elles forment un tableau complet.

【1】Un petit outil pour écouter de la musique, comment il est devenu un produit générant 500 millions de dollars par an. En septembre 2024, Boris Cherny vient de rejoindre Anthropic et, par ennui, a écrit un petit jouet en ligne de commande. À quoi ça sert ? Ça peut te dire quelle chanson tu écoutes actuellement grâce à AppleScript, et il peut changer de chanson selon tes instructions. C'est aussi simple que ça. L'évaluation de Boris lui-même est : « C'est un démo plutôt cool, mais ça n'a pas beaucoup de sens. »

Le véritable tournant s'est produit après qu'il a discuté avec sa collègue Cat Wu. Cat étudiait alors la capacité d'utilisation des ordinateurs par les agents IA, et en discutant, Boris a eu une idée : que se passerait-il si on donnait à cet outil en ligne de commande plus de permissions ? Par exemple, lui permettre de lire et d'écrire des fichiers, ou d'exécuter des commandes ?

Il a essayé. Puis, le moment de voir le miracle est arrivé. Boris a jeté cet outil amélioré dans le code d'Anthropic et a posé quelques questions au hasard. Claude a commencé à explorer le système de fichiers par lui-même - lisant un fichier, voyant les instructions d'importation à l'intérieur, puis lisant les fichiers référencés, creusant couche par couche jusqu'à trouver la réponse. "Cela m'a sidéré," se souvient Boris, "je n'ai jamais utilisé un tel outil."

Dans le domaine de l'IA, il existe un concept appelé "product overhang", qui se traduit par "surplus de produit". Cela signifie que le modèle possède en réalité certaines capacités, mais que la forme actuelle du produit n'a pas libéré ces capacités. Ce que Boris a découvert, c'est un énorme "product overhang" ; Claude pouvait déjà faire cela, mais personne ne lui a construit un boîtier.

Boris a commencé à travailler avec cet outil tous les jours, puis l'a partagé avec quelques collègues. Deux mois plus tard, en novembre, ils ont publié une version interne. Les données sont impressionnantes : le premier jour, 20 % des ingénieurs l'utilisaient ; le cinquième jour, 50 %.

À ce moment-là, un débat intéressant a émergé : faut-il publier cela à l'extérieur ? Les raisons de s'y opposer sont très réelles : si cette chose est vraiment aussi puissante que nous le pensons, ne serait-il pas préférable de la garder comme "arme secrète" ? Pourquoi céder notre avantage concurrentiel si facilement ? Finalement, Anthropic a choisi de publier. La logique est la suivante : la mission principale d'Anthropic est de rechercher la sécurité des modèles, et la meilleure façon d'étudier la sécurité est de permettre aux gens d'utiliser réellement ces outils. Puisque Claude Code a déjà été vérifié en interne pour être largement utilisé, le publier peut apporter plus d'informations sur les capacités et la sécurité du modèle.

En mai 2025, Claude Code a été officiellement lancé. Trois mois plus tard, son utilisation a augmenté de 10 fois, avec un revenu annuel dépassant 500 millions de dollars. Il est intéressant de noter que Boris pensait initialement à l'utiliser uniquement pour les programmeurs - c'est pourquoi il l'a appelé "Claude Code". Mais un jour, en passant devant le bureau d'un data scientist, il a vu que Claude Code était également utilisé sur son écran. "Tu fais quoi avec ça ?" "Je l'utilise pour m'aider à écrire des requêtes et à faire des visualisations." Maintenant, les data scientists d'Anthropic en ont tous un, et certains en ouvrent plusieurs en même temps. Un petit outil d'écoute de musique, qui, en ayant reçu quelques permissions supplémentaires, est devenu un produit d'une valeur de plusieurs centaines de millions de dollars. C'est probablement la meilleure preuve du "product overhang", les capacités du modèle ont toujours été là, il ne manquait que quelqu'un pour les libérer.

【2】90 % du code est écrit par lui-même — La philosophie de choix technologique de Claude Code Claude Code a 90 % de son code écrit par lui-même. Cela peut sembler être un argument marketing, mais cela est en réalité dû à leur logique de prise de décision technologique. Commençons par la pile technologique : TypeScript pour le cœur, React associé au framework Ink pour l'interface utilisateur terminal, Yoga de Meta en open source pour le système de mise en page, et Bun pour la construction et le packaging. Pourquoi avoir choisi ces technologies ? Parce qu'elles sont "dans la distribution". "Dans la distribution" (on distribution) est un terme du domaine de l'IA. Cela signifie que le modèle a déjà vu une grande quantité de ce type de code et est doué pour les traiter. TypeScript et React sont précisément les points forts de Claude. Si l'on choisit un framework peu connu, le modèle devra "apprendre", ce qui réduira l'efficacité. Ce choix crée un merveilleux cycle : écrire Claude Code avec la pile technologique que Claude maîtrise, puis utiliser Claude Code pour écrire encore plus de Claude Code. 90 % de soi-même, c'est ainsi que cela fonctionne. Leurs choix au niveau de l'architecture sont tout aussi simples. Claude Code s'exécute localement. Pas de conteneurs Docker, pas de sandbox cloud, juste la lecture et l'écriture de fichiers, l'exécution de commandes directement sur votre ordinateur.

Quant à la raison pour laquelle ce design a été choisi ? La réponse de Boris est : « Chaque fois que nous prenons une décision de design, nous choisissons presque toujours la solution la plus simple. L'exécution locale est la réponse la plus simple. » Cette simplicité s'étend à toute la philosophie du produit : écrire le moins de logique métier possible, laisser le modèle être le protagoniste. « Cela peut sembler un peu étrange, » dit Boris, « mais nous voulons que les utilisateurs puissent ressentir le modèle de la manière la plus "authentique" possible. Beaucoup de produits d'IA ajoutent une tonne de structures - des éléments d'interface utilisateur supplémentaires, diverses fonctionnalités d'assistance - ce qui limite en fait l'expression du modèle. Ce que nous voulons faire, c'est rendre l'UI aussi épurée que possible. » Pour maintenir la simplicité, chaque fois que Claude publie un nouveau modèle, ils simplifient massivement le code. Par exemple, lors de la sortie de Claude 4.0, ils ont supprimé environ la moitié des prompts système, car le nouveau modèle n'avait plus besoin de ces « béquilles ». Le nombre d'outils est également en constante simplification - tout ce qui peut être supprimé est supprimé, tout ce qui peut être fusionné est fusionné. L'ensemble de l'architecture Claude Code peut être résumé en trois choses : définir l'UI et exposer l'interface pour modification par le modèle, exposer des outils pour que le modèle puisse les appeler, puis se retirer. Bien sûr, la simplicité ne signifie pas qu'il n'y a pas de parties complexes. Le système de permissions en est une exception. Après tout, permettre à l'IA d'exécuter des commandes sur votre ordinateur comporte des risques. La solution de Claude Code est de vous demander avant d'exécuter : voulez-vous approuver cette opération ? Vous pouvez approuver uniquement cette fois-ci, ou approuver à l'avenir, ou refuser. Le système de permissions prend en charge une configuration multi-niveaux - par projet, par utilisateur, par entreprise. Les équipes peuvent partager des fichiers de configuration et ajouter des commandes de sécurité courantes à une liste blanche. Le principe derrière cette conception des permissions est le suivant : Si vous lancez Claude Code, il ne devrait rien modifier sans votre consentement. Mais en même temps, il faut donner aux utilisateurs le choix de "décentraliser" - dans des scénarios de confiance, vous pouvez sauter l'étape de confirmation. Simple, mais pas rudimentaire. Réservé, mais pas dépourvu de fonctionnalités.

【3】Vingt prototypes en deux jours - à quoi ressemble l'itération des produits à l'ère de l'IA Avant, faire des prototypes de produits, réussir à en faire deux en deux jours était déjà considéré comme efficace. Boris a réalisé 20 prototypes en deux jours. Ce n'est pas une exagération, c'est un enregistrement réel de son travail sur la fonctionnalité de liste de tâches de Claude Code. Il a même partagé les invites et les captures d'écran de chaque étape. Voyons comment ces 20 prototypes ont évolué. Dans la première version, il voulait que la liste de tâches s'affiche sous le dernier appel d'outil. L'invite était très courte : "Ne pas faire apparaître la liste de tâches avec l'entrée, mais afficher une liste de tâches fixe au-dessus de la zone de saisie, avec le titre en gris '/todo (1 sur 3)'". Après avoir vu le résultat, il n'était pas très satisfait. Dans la deuxième version, il a changé pour afficher la liste de tâches en ligne à chaque mise à jour. L'invite : "En fait, ne pas afficher la liste de tâches, mais rendre le nom de l'outil en gras lorsque le modèle commence à traiter une tâche. Conserver l'affichage de progression comme 'étape 2 sur 4'". Ce n'était toujours pas ça. Dans la troisième et la quatrième version, il a essayé de créer une "pilule interactive" - un petit carré en bas de l'écran qui, lorsqu'on clique dessus, montre la progression. "Ajouter une pilule de tâches sous la zone de saisie, similaire au style des tâches en arrière-plan, affichant 'todos : 1 sur 3'". Puis : "Rendre cette pilule interactive, comme celle des tâches en arrière-plan". C'était un peu intéressant, mais pas encore assez bon. Dans la cinquième et la sixième version, il a changé d'approche : créer un "tiroir" qui glisse depuis la droite. "Annuler la pilule et le titre précédents, afficher la liste de tâches à droite de la zone de saisie, centrée verticalement, séparée par une ligne grise". "C'est un peu brusque, peut-on faire une animation de tiroir ?" Ça avait l'air cool, mais son utilité était douteuse. Dans les versions sept à neuf, il a de nouveau déplacé la liste de tâches au-dessus de la zone de saisie, expérimentant différentes méthodes de coupure et styles de titre. "Si plus de 5, afficher '... et 4 de plus'", "ajouter un titre gris 'Todo:'". Il se rapprochait de la réponse. Dans les versions dix à vingt, il a commencé à réfléchir à la façon de combiner la liste de tâches avec l'animation de chargement. La solution finale était de placer les informations de progression à côté du spinner (indicateur de chargement), maximisant la visibilité. Après la publication, les utilisateurs ont fait savoir qu'ils voulaient voir la liste de tâches complète. Il a donc ajouté une itération : en appuyant sur Ctrl+T, on peut développer toutes les étapes. C'est la version actuelle en ligne.

Tout au long du processus, les prompts de Boris sont étonnamment courts - la plupart ne font qu'une ou deux phrases. Mais chaque version est un prototype fonctionnel, pas une image statique, pas un PPT. Il peut vraiment tester et valider cette fonctionnalité, ressentir si cela fonctionne bien ou non. Le processus traditionnel de développement de produit est : idée → discussion → création de maquettes → réalisation de designs haute fidélité → développement → test → mise en ligne. Chaque étape prend du temps, chaque étape peut être un obstacle. Le processus actuel est devenu : idée → prompt d'une phrase → prototype fonctionnel → si ça ne va pas, on en refait une version. Cela exige en fait des développeurs de changer leur façon de penser pour s'adapter à ce processus de développement. Auparavant, le rôle du prototype était de "valider une idée" - car créer un prototype coûte cher, il fallait d'abord bien réfléchir avant de se lancer. Maintenant, le prototype est devenu "explorer des possibilités" - car créer un prototype coûte peu, on peut d'abord le réaliser et ensuite décider, si ce n'est pas bon, on le jette. Boris dit que lorsqu'il utilise Claude Code, il saute souvent directement l'étape de création de maquettes et fait directement une version fonctionnelle, c'est plus intuitif que tout. Le rythme quotidien de l'équipe Claude Code est : chaque ingénieur pousse environ 5 PR par jour, publie en interne 60 à 100 versions par jour, et publie une version externe par jour. Cinq PR par jour, c'est inimaginable pour la plupart des entreprises. Uber, pendant sa période de restructuration la plus intense, considérait qu'un PR de taille moyenne par jour était déjà bien. Les outils ont changé, le rythme a changé, et la façon de penser doit également évoluer.

【4】Redesign du terminal de commande intégré à l'IA Le terminal de commande existe depuis des décennies, pourquoi a-t-on besoin de le redessiner maintenant ? Parce qu'avant l'apparition des LLM, le terminal ne se souciait pas vraiment de l'expérience utilisateur. Le terminal traditionnel fonctionne sur un modèle question-réponse : vous entrez une commande, il renvoie un résultat, c'est tout. Pas de dialogue, pas de contexte, pas de retour pendant l'attente. Vous fixez le curseur clignotant, sans savoir ce qui se passe en arrière-plan. Claude Code est l'un des premiers produits à vraiment devoir réfléchir à l'"UX du terminal". Ils ont ajouté quelques petits détails qui peuvent sembler insignifiants, mais l'expérience d'utilisation est complètement différente. Premier point : les indications de chargement de contexte. Lorsque le modèle réfléchit, l'écran peut afficher des indications pertinentes en fonction de la tâche actuelle : par exemple, "en train de lire votre structure de code" ou "en train de réfléchir à une solution". C'est un petit détail, mais cela donne une "personnalité" à l'outil. Vous avez l'impression qu'il travaille sérieusement, et non qu'il est bloqué. Boris a dit que la dernière fois qu'il a vu une interaction aussi agréable, c'était lors du processus d'intégration de Slack. Deuxième point : les conseils pédagogiques pendant l'attente. Lorsque Claude exécute une tâche longue, le bas de l'écran affiche en alternance des astuces d'utilisation, comme "vous pouvez appuyer sur Esc pour interrompre la tâche actuelle" ou "essayez /help pour voir toutes les commandes". Le terminal sert à enseigner le terminal, simple et intelligent. La troisième histoire est encore plus intéressante : le rendu Markdown. La veille de la publication, un ingénieur s'est plaint que les listes imbriquées étaient très laides et que l'espacement des paragraphes n'était pas correct. Le problème venait du rendu Markdown. Boris a essayé tous les rendus disponibles sur le marché, aucun n'était beau dans le terminal. Alors, il a passé une journée avec Claude Code à écrire un parseur et un rendu Markdown depuis le début. Oui, la veille de la publication. Oui, depuis le début. Oui, en utilisant Claude Code lui-même. Le résultat, ce rendu "fait à la hâte", est plus beau que toutes les solutions existantes. Ils l'ont directement publié. Boris pense qu'il n'y a actuellement aucun autre terminal avec un rendu Markdown de la même qualité. Cette histoire illustre une chose : lorsque vous avez un outil de programmation IA suffisamment bon, le coût de "fabriquer ses propres roues" diminue considérablement. Ce qui était autrefois un compromis de "ça fonctionne" peut maintenant se transformer en "alors faisons quelque chose de mieux". Cette ancienne interface de terminal de commande renaît grâce à l'ajout des LLM. Le terminal reste le même, mais grâce à l'ajout de l'IA, nous devons réfléchir sérieusement : comment améliorer le dialogue entre l'utilisateur et l'IA dans le terminal.

【5】L'IA pénètre chaque étape - une expérience de "transformation complète par l'IA" d'une équipe d'ingénieurs L'équipe d'ingénierie d'Anthropic est peut-être l'une des équipes qui utilise les outils d'IA de manière la plus poussée. Cela ne se limite pas à l'écriture de code, mais s'étend à toutes les étapes du projet. Revue de code : la première révision de toutes les PR est effectuée par Claude Code, l'ingénieur fait la deuxième. Boris dit que Claude Code peut détecter de nombreux problèmes dès la première révision. Cette fonctionnalité était à l'origine utilisée en interne, mais ils l'ont ensuite rendue publique, permettant à tout le monde d'utiliser Claude Code pour les revues de sécurité. Écriture de tests : la suite de tests de Claude Code est presque entièrement écrite par Claude Code. Boris dit : "Avant, si quelqu'un proposait une PR sans écrire de tests, j'hésitais à dire quelque chose - j'avais l'impression de chipoter. Mais maintenant, avec Claude, écrire des tests n'est qu'une question de mot d'invite, il n'y a plus d'excuse pour ne pas écrire." Réponse aux incidents : l'ingénieur de garde demande à Claude Code d'aider à analyser la cause racine (la raison fondamentale du problème). Il peut extraire des discussions pertinentes de Slack, des journaux d'erreurs de Sentry, des données de divers systèmes de surveillance, puis effectuer une analyse globale. Boris dit que Claude Code trouve la cause racine plus rapidement que les humains dans certains scénarios. Redirection des problèmes GitHub : chaque fois qu'un nouveau problème arrive, Claude Code effectue d'abord une analyse, puis l'ingénieur lui demande "peux-tu le résoudre ?". Boris dit que dans environ 20 % à 40 % des cas, il peut le résoudre dès la première fois. Graphiques et requêtes : les données produit sont stockées dans BigQuery, presque toutes les requêtes et visualisations sont générées par Claude Code. Les ingénieurs lui demandent même de produire directement des graphiques ASCII.

Ce qui m'a le plus surpris, c'est le renouveau du TDD (développement piloté par les tests). Le TDD est un vieux concept : d'abord écrire des tests, puis écrire le code qui fait passer ces tests. En théorie, c'est très beau - cela vous oblige à réfléchir à ce que vous voulez. Mais dans la pratique, la plupart des gens trouvent que c'est trop lent et trop compliqué, donc cette méthode a lentement été marginalisée au cours des dix dernières années. Mais Boris a dit qu'après avoir utilisé Claude Code, il a fait beaucoup de TDD : "Je fais d'abord écrire un test au modèle, tout en lui disant que ce test va échouer pour l'instant, sans essayer de le faire passer. Ensuite, je lui fais écrire le code pour réaliser la fonctionnalité et faire passer le test, mais sans modifier le test lui-même." "Quand le modèle a un objectif clair à itérer - comme un test unitaire ou un mock - il se comporte très bien." Il a particulièrement mentionné que Claude 4.0 est la première série de modèles capable de faire écrire la plupart des tests par le modèle. Les versions précédentes pouvaient écrire une partie, mais nécessitaient beaucoup d'interventions humaines. Il y a aussi un nouveau concept : le multi-clauding. Cela signifie exécuter plusieurs instances de Claude Code en même temps, leur permettant de traiter différentes tâches en parallèle. Sid a dit qu'il le faisait souvent - il lance plusieurs agents pendant les réunions et revient ensuite pour voir les résultats. Anthropic a découvert que 25 % des utilisateurs abonnés à Max (utilisateurs premium payant entre 100 et 200 dollars par mois) pratiquent le multi-clauding chaque jour. C'est un changement très intéressant. La programmation a toujours été une activité "monothread" : vous ne pouvez faire qu'une seule chose à la fois, et vous ne changez de tâche que lorsque vous attendez une révision de code ou un déploiement. Mais maintenant, la "programmation parallèle" devient possible - vous pouvez avancer sur plusieurs choses en même temps. Bien sûr, il y a beaucoup d'inconnues : le travail parallèle est-il vraiment plus efficace, ou est-ce juste une impression ? Quel type de tâches se prête à la parallélisation ? Le fait que chaque agent reçoive moins d'attention, cela ne posera-t-il pas de problèmes ? Ces questions n'ont pas encore de réponse. Mais nous avons un nouvel outil pour expérimenter. Enfin, un exemple. Une entreprise devait effectuer une migration de cadre, initialement estimée à deux années d'ingénierie - un ingénieur pendant deux ans, ou dix ingénieurs pendant deux mois et demi. Ils ont utilisé Claude Code, et un ingénieur a terminé en deux semaines. Boris a dit qu'il aurait été sceptique à l'égard de ce genre d'affirmation auparavant, mais ils ont entendu trop de récits similaires.

【6】Hackathon de trois jours — Comment la fonctionnalité Subagents est née La fonctionnalité Subagents s'inspire d'un post sur Reddit. Quelqu'un a dit qu'il avait ouvert cinq instances de Claude Code en même temps, en attribuant un rôle différent à chaque instance, puis en utilisant un système de fichiers pour les faire communiquer entre elles. Lorsque Sid Bidasaria a vu ce post, sa première réaction a été : ce concept est génial, mais les utilisateurs ne devraient pas avoir à se compliquer la vie. Nous devrions en faire une fonctionnalité intégrée au produit. Il se trouve que l'entreprise avait un hackathon interne de trois jours, Sid a décidé d'utiliser ces trois jours pour réaliser cela. Le premier jour, l'équipe a dessiné avec enthousiasme diverses structures topologiques complexes d'Agent : communication entre Agents via un bus de messages, mode asynchrone, interactions multiples… Les dessins étaient très beaux, le concept très avancé. Le deuxième jour, ils ont réalisé que cela semblait irréalisable. Le problème n'était pas la mise en œuvre technique — ces modèles complexes pouvaient être réalisés. Le problème était que les utilisateurs ne pouvaient pas comprendre. L'interface utilisateur de Claude Code est simplement un terminal, comment faire comprendre aux utilisateurs ces modes de communication complexes entre Agents dans une interface aussi simple ? Ils ont décidé de tout recommencer, en revenant à une question fondamentale : quelle est la forme la plus simple que les développeurs ordinaires peuvent utiliser ? Ils se sont fixés deux contraintes : Premièrement, ne rien inventer de nouveau. Utiliser uniquement les capacités existantes de Claude Code — les commandes “/” et les fichiers .md. Deuxièmement, ne pas faire de communication entre Agents. Passer à un mode d'orchestration simple : il y a un Agent principal qui peut appeler des sous-Agents, et les sous-Agents retournent les résultats après avoir accompli leurs tâches, c'est tout. Ils ont également discuté avec l'équipe de recherche d'Anthropic. Les chercheurs étudient le modèle multi-Agent, mais la conclusion est : l'efficacité des topologies complexes d'Agents n'est pas encore prouvée. Cela leur a donné plus de confiance : puisque même l'équipe de recherche dit que complexe n'est pas forcément meilleur, il est d'autant plus important de faire une version simple. À la fin du troisième jour, ils avaient créé une version fonctionnelle. Les utilisateurs peuvent définir les rôles et capacités des sous-Agents dans un fichier .md (par exemple, "sous-Agent front-end : utilisant React 19 et Next.js"), Claude Code les appellera au bon moment, ou l'utilisateur peut les déclencher manuellement. Après le hackathon, après quelques ajustements, la fonctionnalité a été mise en ligne. Maintenant, vous pouvez définir divers sous-Agents spécialisés : un Agent back-end expert en audit de sécurité, un Agent front-end familier avec des frameworks spécifiques, un Agent QA spécialisé dans l'écriture de tests… Ils peuvent travailler en parallèle en arrière-plan, chacun ayant son propre rôle. De nombreuses équipes lors du hackathon ont du mal à abandonner leurs solutions complexes, après tout, elles ont passé toute une journée à dessiner et discuter, il y a un attachement. Reconnaître que "ce chemin ne fonctionne pas" et tout recommencer nécessite du courage, ainsi qu'une foi en la "simplicité". La simplicité n'est pas de la paresse. La simplicité consiste à trouver la forme que l'utilisateur peut réellement utiliser parmi d'innombrables possibilités.

【7】À quoi ressemblera l'équipe d'ingénierie de demain ? Certaines choses peuvent être inspirantes, d'autres non reproductibles. Boris dit : "La programmation est tellement intéressante maintenant. La dernière fois que j'ai ressenti cela, c'était au collège quand j'ai écrit du code pour la première fois sur une calculatrice graphique. Cette sensation magique, je ne l'avais pas ressentie depuis longtemps, mais elle est de retour maintenant." Sid ressent quelque chose de similaire : "Il y a deux choses qui m'excitent. D'une part, la vitesse à laquelle nous publions - parfois, cela semble même trop rapide. D'autre part, l'espace d'expérimentation - même si les travaux précédents étaient rapides, ce que nous faisions était assez routinier, nous savions quelle était la réponse, il ne s'agissait que d'exécuter. Maintenant, ce n'est plus le cas, le modèle change tous les trois mois, nous devons constamment repenser notre façon de faire." Ces sentiments sont très réels et contagieux. Mais avant de discuter de "à quoi ressemblera l'équipe d'ingénierie de demain", n'oublions pas la spécificité d'Anthropic. Premièrement, Anthropic est un laboratoire de recherche, pas une entreprise de produits. Sa mission principale est de rechercher la sécurité et les capacités de l'IA, les produits sont un moyen, pas une fin. Cela signifie qu'ils ont une tolérance pour les "expérimentations rapides" beaucoup plus élevée que la plupart des entreprises. Deuxièmement, leur produit principal est le modèle Claude lui-même. Claude Code n'est qu'une "enveloppe" du modèle. Donc, "supprimer le code pour que le modèle fasse plus de choses" est un choix naturel pour eux, mais pour d'autres entreprises, cela pourrait signifier confier la logique commerciale essentielle à une boîte noire. Troisièmement, tous les employés ont un accès illimité à Claude, y compris le modèle Opus le plus cher. Dans la plupart des entreprises, les frais d'abonnement à l'IA sont un poste budgétaire à défendre, il est impossible que tout le monde puisse l'utiliser librement. Quatrièmement, l'équipe ne compte qu'une dizaine de personnes, avec un processus très simplifié. Ils n'utilisent presque pas de feature flag (commutateur de fonctionnalité), car "c'est trop lent". Cela est inimaginable dans des produits avec une grande base d'utilisateurs et un coût d'erreur élevé. Ainsi, copier directement les pratiques de l'équipe Claude Code n'est pas nécessairement réaliste pour la plupart des équipes. Mais certaines choses peuvent être inspirantes. La mentalité de prototypage rapide : même si vous ne pouvez pas faire 10 prototypes par jour, pouvez-vous passer de "un prototype toutes les deux semaines" à "trois prototypes par semaine" ? Les outils ont changé, les attentes concernant "la rapidité des prototypes" devraient également être mises à jour. Révision de code assistée par IA : laissez l'IA faire la première révision, puis une personne fait la seconde. Ce processus ne dépend pas d'un accès API illimité, la plupart des équipes peuvent essayer. Le renouveau du TDD : si écrire des tests devient suffisamment facile, alors "je n'ai pas le temps d'écrire des tests" ne sera plus une excuse. Cela pourrait être un point d'entrée à faible coût pour améliorer la qualité du code. La valeur amplifiée de l'ingénieur orienté produit : l'équipe Claude Code n'a pas de designer, pas de PM, elle repose sur quelques ingénieurs ayant un sens du produit. Les outils d'IA ont considérablement élargi ce que ces "talents polyvalents" peuvent faire.

Bien sûr, il y a des choses que les outils ne peuvent pas remplacer. Boris peut choisir le meilleur prototype parmi 20, car il a du jugement - il sait ce qui "semble juste" et ce qui "semble juste utilisable". Ce goût est le résultat de 17 ans d'expérience en développement logiciel, ce n'est pas quelque chose que l'IA peut fournir. L'équipe a élaboré des solutions complexes le premier jour, et le lendemain, elle a pu prendre la décision difficile de tout recommencer, cette capacité de décision est également le jugement humain. Savoir quand supprimer du code et quand le conserver, cette intuition architecturale est tout aussi importante. L'IA a accéléré l'exécution, mais elle n'a pas simplifié le fait de "savoir quoi faire". Au contraire, avec la baisse des coûts d'exécution, la décision de "quoi faire" est devenue plus importante - vous pouvez rapidement créer 20 versions, mais vous devez savoir laquelle est la bonne. À quoi ressemblera l'ingénierie logicielle dans quelques années ? Personne ne peut prédire avec précision. Mais l'équipe de Claude Code aujourd'hui pourrait être une sorte de préfiguration de ce que beaucoup d'équipes vivront demain - des itérations plus rapides, moins de "boulot de base", plus de jugement et de décisions. Les outils évoluent. Ce qui ne change pas, c'est que la décision finale revient toujours à l'homme.