Le fondateur de Claude Code, Boris Cherny, partage 7 jugements clés sur l'IA à la conférence Sequoia

Organisé par A Ying

Boris Cherny, fondateur de Claude Code, a partagé lors de la conférence Sequoia des informations très riches, de nombreuses idées que j'ai entendues pour la première fois. Ce type comprend effectivement bien l'IA.

Je partage mon résumé.

Pour de nombreux scénarios de développement courants, écrire du code à la main commence à devenir une démarche peu efficace.

Auparavant, pour livrer une fonctionnalité, un ingénieur s’asseyait, réfléchissait d’abord à la manière de l’implémenter, puis tapait le code ligne par ligne. Pendant ce processus, la valeur principale de l’ingénieur résidait dans sa capacité à écrire, à bien écrire et à écrire rapidement.

The way things work now is different.

Pour une même fonctionnalité, ce que font les ingénieurs ressemble davantage à : d’abord clarifier les exigences, décomposer la tâche en plusieurs parties à attribuer à l’Agent, établir des critères d’acceptation, puis vérifier si les résultats générés par l’Agent sont corrects ; si ce n’est pas le cas, ajuster le prompt et relancer.

L'IA peut désormais gérer la plupart des tâches de codage. Bien sûr, ce n'est pas à 100 %, car de nombreux grands et complexes bases de code, langages peu courants ou environnements spécifiques restent encore au-delà des capacités des modèles actuels.

Dans l'ensemble, la valeur des ingénieurs est passée de la capacité à écrire du code à celle de décomposer les tâches, de clarifier les objectifs, de valider les résultats et de gérer les agents.

Ce changement est en réalité très similaire à la révolution industrielle.

Avant la Révolution industrielle, un forgeron faisait tout lui-même : frapper, forger, polir et assembler. Un forgeron habile valait naturellement cher.

Ensuite, la chaîne de montage est apparue. Chaque ouvrier ne se chargeait que d'une seule étape, mais la production globale était de plusieurs dizaines à cent fois supérieure à celle de l'ère artisanale.

À ce moment-là, le rôle le plus précieux dans l'usine n'est plus celui de l'artisan qui excelle dans une seule étape, mais celui qui sait concevoir, gérer et faire fonctionner efficacement la chaîne de production.

Les travailleurs n'ont pas disparu, mais leur rôle a changé.

L'ingénierie logicielle traverse actuellement un tournant similaire. Le code lui-même n'est plus une ressource rare. Savoir écrire du code devient une compétence de base, comme savoir utiliser PowerPoint.

Ce qui est véritablement rare, c’est la capacité à décomposer des besoins vagues en tâches claires, à choisir parmi les plusieurs solutions proposées par l’Agent celle qui est la plus adaptée, et à faire coopérer un groupe d’IA pour accomplir une tâche.

En réalité, beaucoup de vieux ingénieurs ont du mal à accepter cela au départ. Écrire soi-même le code est, depuis des décennies, la raison pour laquelle beaucoup aiment ce métier.

Le confier à une machine, pour beaucoup, ne change pas seulement la manière de travailler, mais entraîne une refonte de l'identité.

Mais une tendance reste une tendance.

La programmation est en train de passer d'une compétence professionnelle à une compétence de base. Cela peut être comparé à l'imprimerie en Europe au XVe siècle.

Avant l'invention de l'imprimerie, environ 10 % de la population européenne seulement savait lire et écrire. Ces personnes étaient souvent employées par des nobles illettrés pour lire et écrire en leur nom.

Ensuite, l'imprimerie est apparue. En 50 ans, le nombre de livres publiés en Europe a dépassé la somme totale des mille années précédentes, et le prix des livres a diminué d'environ 100 fois. Il a fallu encore plusieurs siècles pour que les infrastructures associées (systèmes éducatifs, structures économiques) rattrapent le pas, avant que le taux d'alphabétisation mondial n'atteigne les 70 % d'aujourd'hui.

Boris estime que l'impact de l'IA sur le logiciel est une version accélérée de la révolution de l'imprimerie. Le logiciel sera complètement démocratisé en quelques décennies, devenant accessible à tous.

Finalement, faire du logiciel sera aussi naturel que d'envoyer un SMS.

Lorsque la barrière d'entrée pour écrire du code est réduite à un niveau extrêmement bas par l'IA, ce qui distingue véritablement la capacité d'une personne, c'est son sens du produit et sa compréhension réelle d'un domaine spécifique.

Par exemple, deux personnes veulent développer un produit destiné aux médecins. L'une est un ingénieur qui code rapidement, et l'autre a travaillé pendant plusieurs années dans le service informatique d'un hôpital.

Dans le passé, les ingénieurs avaient plus de chances de réaliser quelque chose, car ils pouvaient concrétiser leurs idées.

Maintenant, c'est l'inverse. N'importe qui peut mettre en œuvre une idée. À ce moment-là, la personne qui comprend réellement le flux de travail quotidien de l'hôpital devient plus précieuse. Car elle sait quelles fonctionnalités les médecins utiliseront vraiment et lesquelles ne sont que logiques en apparence.

Autrement dit, une fois que l'IA a nivelé la barrière à l'exécution, les différences de jugement sont amplifiées.

This directly redefines the meaning of the word generalist.

Par le passé, lorsque nous parlions de generalist, nous désignions généralement un ingénieur capable de développer à la fois sur iOS, sur le Web et en back-end. Ce type de generalist reste fondamentalement un full-stack au sein de l'ingénierie.

Le généraliste de l'avenir est un full-stack interdisciplinaire.

Certaines personnes maîtrisent à la fois le produit, le design et l'ingénierie. D'autres maîtrisent à la fois le produit, la science des données et l'ingénierie. Ce type de combinaison était presque impossible auparavant, car chaque domaine exigeait une formation spécialisée de longue durée.

Mais maintenant, l'IA abaisse les barrières d'entrée pour chaque domaine, permettant à une personne de couvrir plusieurs domaines tout en conservant une profondeur professionnelle.

L'équipe Claude Code fonctionne ainsi : le manager technique, le PM, les designers, les scientifiques des données, les comptables et les chercheurs utilisateurs écrivent tous du code.

Les concepteurs peuvent exécuter eux-mêmes les prototypes interactifs pour les présenter à l'équipe, sans plus avoir à se contenter de fournir des visuels en attendant que les ingénieurs les implémentent.

Les professionnels des finances peuvent désormais créer leur propre outil d'analyse pour exécuter les modèles financiers complexes de l'entreprise, sans avoir à attendre leur tour auprès de l'équipe BI. Les collègues de l'étude utilisateur commencent à exécuter eux-mêmes les données, en reprenant les tâches qui nécessitaient auparavant la collaboration de l'équipe données.

La profondeur professionnelle de chacun reste intacte. Mais avec l'aide de l'IA, écrire du code est devenu une langue commune à tous.

Au cours des dernières décennies, l'industrie SaaS a adopté plusieurs principes considérés comme des axiomes.

Le premier coût est le coût de transition. Une fois qu'une entreprise utilise votre système, elle accumule progressivement des données, des configurations, des champs et des relations de permissions sur plusieurs années, voire plusieurs décennies.

Déménager vers un autre système, simplement déplacer ces éléments tels quels puis les réintégrer, suffit à rendre la tâche si pénible qu’on n’a plus envie de bouger.

Le deuxième point est le verrouillage du flux de travail. Les opérations quotidiennes des employés, la collaboration interdépartementale et les points d'approbation sont tous construits autour de ce SaaS.

Changer de système, ce n'est pas simplement déplacer des données, c'est démolir et reconstruire la mémoire musculaire que l'entreprise a développée au cours des dernières années.

Ces deux éléments combinés constituaient le fossé compétitif le plus profond de l’industrie SaaS précédente. Mais avec des modèles suffisamment puissants, la logique des choses commence à changer.

Regardons d'abord le coût de basculement. Auparavant, passer d'un SaaS à un autre nécessitait déjà plusieurs mois de travail supplémentaire pour l'équipe technique, simplement pour aligner les champs et recréer la structure des données.

Envoyez directement les interfaces et les structures de données des deux côtés au modèle, et laissez-le déterminer lui-même les relations de mappage, en progressant progressivement vers la solution optimale. Ce qui aurait pris des mois peut désormais produire une version utilisable en quelques jours.

Regardons maintenant le côté verrouillage des flux de travail, qui est encore plus intéressant. Par le passé, les flux de travail verrouillaient les clients parce qu’ils étaient complexes, implicites et dépendaient des personnes.

Les accords implicites sur qui doit approuver qui et à quelle étape le processus se bloque ne peuvent pas être transférés directement.

Mais des modèles comme Opus 4.7 sont précisément les meilleurs pour comprendre, décomposer et reconstruire un processus complexe dans un nouvel environnement. La version reconstruite peut même être plus fluide que l'originale.

Ainsi, les avantages concurrentiels construits autrefois grâce à la consolidation des données et des processus sont en train de s'effriter.

Pour ceux qui développent des SaaS, cela pourrait être une mauvaise nouvelle. Mais pour tous les clients utilisant des SaaS et les équipes en préparation de la nouvelle génération de SaaS, c’est une véritable fenêtre d’opportunité.

Les entreprises de start-up qui révolutionneront véritablement l'industrie au cours des 10 prochaines années pourraient être 10 fois plus nombreuses que celles des 10 dernières années.

La raison n'est en fait pas compliquée.

Les petites équipes peuvent utiliser l'IA pour créer des produits de niveau équivalent, voire supérieur, à ceux des grandes entreprises. À l'inverse, pour les grandes entreprises, vouloir vraiment utiliser l'IA devient un fardeau.

How to say it?

Une entreprise avec plus de dix ans d'histoire a développé tout un ensemble de processus opérationnels, de répartitions de postes, d'habitudes de collaboration, de systèmes de formation et de indicateurs de performance. Ces éléments étaient autrefois des actifs, des barrières à l'entrée.

Mais intégrer réellement l'IA signifie reconsidérer tout cela : les processus métiers doivent être重构, tous les employés doivent être formés à nouveau, chaque pas en avant rencontre une forte résistance interne, et il faut coordonner N départements et N niveaux d'approbation.

Une équipe de départ de trois personnes a intégré l'IA comme base par défaut dès le premier jour. Ils n'ont pas de fardeau historique à démanteler, pas d'habitudes à modifier, personne à convaincre. Discuté aujourd'hui, démonstration demain, mise en ligne après-demain pour que les utilisateurs puissent l'utiliser.

Ce décalage de vitesse existait déjà auparavant avec l’IA. Les startups ont naturellement un avantage de vitesse sur les grandes entreprises. Mais l’IA a multiplié cet écart par plusieurs facteurs.

Pourquoi ?

Plus l'IA est puissante, plus une personne peut multiplier son levier dans un laps de temps donné. Une petite équipe qui utilise réellement l'IA peut aujourd'hui produire autant que dix personnes par le passé, et demain peut-être trente.

Mais le poids organisationnel des grandes entreprises ne s'est pas allégé ; au contraire, il s'est alourdi en raison de la nécessité d'intégrer l'IA. Plus l'IA est puissante, plus l'écart entre l'accélération des petites équipes et la traînée des grandes entreprises s'élargit.

C'est ce que Boris appelle des actifs négatifs. Ce n'est pas que les grandes entreprises manquent d'argent, de personnel ou de volonté ; ce sont les compétences qui leur ont autrefois permis de générer des revenus qui se trouvent aujourd'hui bloquées sur le chemin de la véritable valeur de l'IA.

MCP ne mourra pas.

Après que Skill ait connu un grand succès, beaucoup ont pensé que MCP n'était plus nécessaire. Le fondateur d'OpenClaw partage une opinion similaire.

Mais Boris ne voit pas les choses ainsi. Il pense que MCP deviendra la couche de connexion logicielle de l'ère de l'IA.

Autrefois, les logiciels sur Internet se connectaient via des API.

Mais le problème fondamental de l'API est qu'elle est conçue pour les ingénieurs. Utiliser une API, c'est d'abord consulter la documentation, demander un Token, écrire du code, aligner les champs et gérer les exceptions. En résumé, l'API est faite pour les développeurs humains.

MCP est différent. Il permet aux modèles de se connecter directement ; le modèle peut le lire et l'utiliser lui-même, sans qu'un programmeur doive le traduire en cours de route.

Donc Boris appelle l'API Human Developer Interface et le MCP Model Interface Protocol. L'un est destiné aux humains, l'autre aux modèles.

Cela ressemble beaucoup à l'époque passée. À l'ère de l'Internet mobile, il était implicite que tous les services doivent être API-ifiés. À l'ère de l'IA, il est implicite que tous les services doivent être MCP-ifiés.

Beaucoup de personnes parlent aujourd'hui de Computer Use et pensent que cette direction ne fonctionne peut-être pas.

La raison est également logique : trop consommateur de tokens, lent et peu stable. Cela ressemble davantage à une démonstration technique qu'à un produit réellement utilisable.

Mais Boris voit un tout autre niveau.

Ce qu'il valorise vraiment, c'est que Computer Use résout l'un des principaux défis de l'implémentation de l'IA : dans le monde réel, de nombreux systèmes n'ont ni API ni MCP.

En particulier dans le monde des entreprises.

Vous ne comprenez vraiment l’entreprise que lorsque vous y travaillez : de nombreux systèmes essentiels sont très anciens. ERP, OA, systèmes financiers, approbations internes, back-office de la chaîne d’approvisionnement, divers systèmes personnalisés. Beaucoup n’ont pas d’interfaces ouvertes, pas de documentation, pas de capacité d’automatisation. Ils sont là, manipulés quotidiennement par des milliers d’employés de manière manuelle.

Pourquoi ne pas leur fournir directement une API ?

Parce que c'est impossible à faire. Les fournisseurs ayant développé ces systèmes pourraient ne plus exister. Le département IT n'a ni la motivation ni le budget pour les重构.

Les départements opérationnels ne peuvent certainement pas attendre six mois ou un an. Ces systèmes n’attendront jamais une API parfaite pour se sauver eux-mêmes.

À court terme, les principaux modèles devraient continuer d'améliorer leur capacité d'utilisation informatique.