Files

T

2026-06-02 23:24:21 +02:00

93 KiB

Raw Blame History

Boris Cherny (créateur de Claude Code) sur ce qui a fait grandir sa carrière — Ryan Peterman

Transcript de l'interview avec Boris Cherny (@bcherny), créateur de Claude Code, sur la chaîne de Ryan Peterman, publiée le 15 décembre 2025.

← Retour à Claude Code Best Practice

Détails de la vidéo

Invité : Boris Cherny (créateur de Claude Code)
Hôte : Ryan Peterman
Publié : 15 décembre 2025
YouTube : Regarder sur YouTube

Transcript

Note : ce transcript provient de sous-titres automatiques. Les noms ont été normalisés (Claude Code, Anthropic, Scala, etc.) pour la lisibilité ; le contenu parlé est traduit fidèlement.

0:02 Les modèles évoluent tellement vite. Si tu me poses cette question dans 3 ou 6 mois, ma réponse sera totalement différente. Voici Boris Cherny. Il est le créateur de Claude Code et ancien principal engineer chez Meta. Et on a parlé de tout ce qui a façonné sa carrière. Peux-tu expliquer la demande latente ?

0:17 La demande latente, je pense, est le principe le plus important en produit.

0:22 Tu as dit qu'il y avait des différences culturelles claires et que c'était difficile.

0:26 Oh mon dieu, « difficile » est un tel euphémisme. C'était un cauchemar. On a aussi parlé de Claude Code et de ce qui se passe réellement chez Anthropic en ce moment. Même si Anthropic a triplé, la productivité par ingénieur a augmenté de presque 70% grâce à Claude Code. Ne construis pas pour le modèle d'aujourd'hui. Construis pour le modèle dans 6 mois. Le seul livre technique que je recommanderais à tout le monde, celui qui a eu le plus grand impact sur moi en tant qu'ingénieur, c'est… Quelles sont tes réflexions sur la concurrence avec Codex et OpenAI ? Je veux commencer au début de ton histoire, avec ta promotion en senior engineer chez Meta. Quelle est l'histoire derrière les projets qui t'ont fait promouvoir, et où en étais-tu à l'époque ? Si je me souviens bien, le projet était Chats and Groups, et c'était un projet pour rapprocher un peu Messenger et Facebook. Et en fait les premiers projets sur lesquels j'ai travaillé chez Meta portaient sur Messenger et Facebook. Le premier était genre une idée de Zach sur la synchronisation des chats Messenger et des groupes Facebook. Mais il y avait quelques-uns de ces projets qui essayaient de rapprocher Messenger et Facebook. Et la motivation, c'était ce sentiment que ce genre de produit social d'espace public disparaissait et que les choses se déplaçaient un peu plus vers le chat et ces espaces plus décontractés en temps réel. Donc on a essayé plusieurs versions du produit, et Chats and Groups est celle qui a marché. C'était genre la numéro trois ou quatre à l'époque, et j'étais dans Facebook groups, ou dans Facebook à l'époque, et je travaillais beaucoup avec Messenger qui était organisationnellement très distant. Et c'est une idée que Steve, qui était PM à l'époque, avait — « voilà un truc qu'on devrait construire » — et j'ai juste embrayé là-dessus, et j'étais genre « ouais carrément, faisons ça ». Et donc j'ai commencé à bidouiller dessus. Et puis assez vite il y a eu des signes de vie. Donc j'ai demandé plus d'ingénieurs, et trois ingénieurs ont rejoint. Il y avait Shatambri, Crystal et Chang. C'étaient les trois premiers ingénieurs qui ont rejoint, et puis on a eu du support en data science, en design. Et ça a commencé juste sur le web. Puis on est aussi passés un peu sur mobile, et ouais, je pense qu'on a juste prouvé cette idée qu'on peut avoir des chats dans les groupes Facebook et que ce genre de produit peut marcher. Et honnêtement il y avait plein de trucs qui ne marchaient pas du tout. C'était une expérience super bancale selon les standards produit modernes. À l'époque tout le monde construisait sur le web et toutes sortes de bugs étaient totalement acceptables. De nos jours le standard, honnêtement le standard visuel, le standard de qualité, est beaucoup plus élevé. Et donc le produit a grandi et on était une si petite équipe que tout le monde devait tout faire, et je me souviens qu'on n'avait pas de user researcher, donc j'allais à la cafétéria au déjeuner et on avait une nouvelle fonctionnalité et on montrait la fonctionnalité aux employés de la cafétéria en disant « hé, tu peux trouver comment ouvrir un chat ? » et parfois ils trouvaient, parfois ils n'y arrivaient pas, et c'est juste une étude de recherche utilisateur par observation. Donc tu vois comment les gens, dans une situation particulière, peuvent faire une tâche sans trop les guider. Tu ne veux pas trop en dévoiler et tu vois où ils galèrent, ce qu'ils comprennent. Et donc on a fait ça, et puis j'ai en quelque sorte appris à l'équipe à le faire. Donc assez vite on allait tous à la cafétéria au déjeuner et on embêtait les employés de la cafétéria comme utilisateurs représentatifs pour leur demander « est-ce que ça a du sens ou pas ? » C'est intéressant de voir comment la culture des débuts de Facebook, dans laquelle tu opérais, laissait les ingénieurs faire tellement de choses en dehors du seul code. Par exemple, tu fais de l'UXR. Il me semble que dans ton histoire tu as aussi fait du design et coaché des gens pour le design. Donc je trouve ça assez intéressant et unique dans la culture de Facebook. Je pense que c'est tellement important, et aujourd'hui encore, dans l'équipe Claude Code, qui est l'équipe dans laquelle je suis maintenant, on priorise vraiment les généralistes. Donc j'adore travailler avec des généralistes. Si tu es un ingénieur qui code mais qui peut aussi faire du travail produit, du design, qui a du sens produit, qui va parler à ses utilisateurs — j'adore ce genre d'ingénieur. Et c'est en fait comme ça qu'on recrute pour toutes les fonctions maintenant. Nos product managers codent, nos data scientists codent, notre user researcher code un peu. J'adore ces généralistes et je pense que c'est vraiment comme ça que j'ai grandi, depuis le début quand je faisais tourner ma première startup à 18 ans, je devais tout faire, et jusqu'à Facebook j'ai travaillé dans des plus petites boîtes où tu devais tout faire, et j'ai l'impression que dans les grandes boîtes tu es forcé dans un couloir de nage particulier, mais c'est juste officiel parce que… qu'est-ce que l'ingénierie ? C'est un ensemble de compétences très étroit, mais en réalité ce que tu fais c'est construire du produit ou de l'infra, et il y a tellement plus que ça pour le faire de bout en bout au-delà d'écrire du code. C'était vraiment cool d'être dans un endroit que Facebook, uniquement, récompensait à ce moment-là. Et je crois qu'à la fin de ce semestre j'ai été promu, puis le semestre d'après chacun des ingénieurs a aussi été promu. Dans ces premiers produits, il y avait ce concept de demande latente que tu as mentionné plusieurs fois, qui semble avoir été l'impulsion de beaucoup de ces directions produit. Peux-tu expliquer la demande latente ?

5:42 La demande latente, je pense, est le principe le plus important en produit, et je pense que si tu regardes surtout les produits Facebook à succès, chacun a un élément de demande latente. Par exemple, Marketplace est venu de cette observation que si tu regardais les groupes Facebook à l'époque, 40% des posts étaient de l'achat et de la vente. Donc les groupes Facebook n'étaient pas conçus pour le commerce, mais c'est ce que les gens en faisaient. Et c'est plutôt cool : tu conçois ce produit d'une façon qui peut être détournée. Il peut être un peu abusé par les utilisateurs, puis tu regardes les données, tu vois comment ils l'abusent, et tu construis un produit autour. Donc il y avait les groupes Facebook, puis les groupes d'achat-vente, et ça a marché évidemment parce que les gens voulaient déjà acheter et vendre sur les groupes Facebook, et puis Marketplace est arrivé. C'était juste une extension naturelle de la même intention que les gens avaient. Facebook Dating était assez similaire je pense. L'observation, c'était que genre 60% des vues de profil étaient des gens du sexe opposé qui n'étaient pas amis. Donc ce genre de « creeping » traditionnel… et pour Nate et les FMS à l'époque, c'était la preuve que ça marcherait. Et le principe en produit, c'est que tu ne peux jamais amener les gens à faire quelque chose qu'ils ne font pas encore. Ce que tu peux faire, c'est trouver l'intention qu'ils ont et l'orienter pour qu'ils puissent mieux capitaliser sur cette intention et faire plus facilement ce qu'ils veulent. À cet endroit de ton histoire, tu as mentionné que tu travaillais entre les orgs. Tu faisais le pont entre Messenger et le travail d'ingénierie des groupes. Je suis curieux : tu as dit qu'il y avait des différences culturelles claires et que c'était difficile. As-tu des conseils pour travailler entre des orgs aux cultures très différentes ?

7:30 Oh mon dieu, « difficile » est un tel euphémisme. C'était un cauchemar. Pour Facebook à l'époque, on voulait livrer, on voulait juste aller vite et livrer du produit génial aussi vite que possible. Et Messenger, c'était tout sur la fiabilité et la performance. C'est tout ce qui leur importait. Des valeurs diamétralement opposées. Et ce n'est pas juste culturel. Ce n'est pas juste un truc d'ingénieur à ingénieur. Les ingénieurs de cette équipe se méfiaient de nous parce qu'on affectait leurs métriques de performance. Et organisationnellement, leur org était structurée pour livrer lentement sans régresser les métriques, et nous étions structurés pour livrer vite. Et puis les objectifs étaient totalement différents : eux avaient des SLA de disponibilité et pour nous c'était juste les utilisateurs actifs quotidiens et l'engagement. Donc pour moi l'enseignement, c'est que ces valeurs culturelles vont super profond. Ce n'est pas juste un truc dont les gens parlent, tu le vois en réalité dans le design de l'org, dans le design des objectifs et dans chaque partie de tout. Et honnêtement, je pense qu'une des raisons pour lesquelles ce projet a échoué — et finalement il a évolué vers quelque chose de réussi, mais cette version-là a échoué — c'est à cause de cette différence de valeurs. Donc fondamentalement, si tu veux faire réussir des entreprises aux valeurs très différentes et les faire travailler ensemble, tu dois trouver une sorte d'objectif partagé, d'intérêt partagé, de croyance partagée, une hypothèse qu'elles veulent tester ensemble et qui serait vraiment intéressante pour les deux si ça marchait. Et ce truc Chats and Groups était fondamentalement vraiment cool pour Facebook, mais pas si cool pour Messenger, pour plein de raisons. Donc, sachant ce que tu sais maintenant, comment changerais-tu les choses en revenant à ce genre de projet ?

9:10 Je serais probablement allé voir Zuck en disant : si tu es vraiment sérieux à ce sujet, on devrait déplacer Messenger dans l'org Facebook. Et je crois que c'est arrivé depuis, et en fait c'est arrivé plusieurs fois : Messenger était dans l'org, puis en est sorti, puis revenu, puis ressorti. C'est une grande boîte, ça arrive. Mais fondamentalement, pour que ce genre de chose réussisse, le rapport hiérarchique commun ne peut pas être genre Chris Cox. Ça doit être un peu plus bas. Et donc tu peux structurer les orgs pour être un peu plus collaboratives.

9:39 Je vois. Aligner les incitations pour ne pas avoir cette lutte constante.

9:44 Ouais. Exactement. À ce stade de ta carrière, j'ai vu que tu avais un tas de projets parallèles vraiment intéressants, et je suis curieux : quel est l'effet papillon de ce genre de projets ? Par exemple, même avant Meta, tu as travaillé sur Undux, le framework de gestion d'état pour React. Comment ça a impacté ta carrière, si tant est que ce soit le cas ?

10:07 Ouais, pour moi les quêtes annexes sont tellement importantes, et quand j'embauche des ingénieurs c'est vraiment quelque chose que je recherche. Je veux des gens avec des quêtes annexes, des projets de week-end cool, des projets parallèles cool, même quelqu'un qui est genre vraiment à fond dans la fabrication de kombucha ou un truc comme ça. Tu veux des gens généralement curieux et intéressés par des choses en dehors de leur travail principal. Ce sont des gens complets. C'est le genre de gens avec qui j'aime travailler. Pour moi, c'est de là qu'est venue une grande partie de ma croissance, de travailler sur ce genre de projets parallèles. Quelque chose comme Undux, honnêtement, d'où ça vient : la gestion d'état React est honnêtement inutilement compliquée, et à l'époque l'état de l'art c'était Flux, puis cet autre truc appelé Redux, et je n'arrivais juste pas à piger Redux. Je me considère comme un ingénieur plutôt moyen, je construis du produit, je ne suis pas un de ces incroyables ingénieurs systèmes. Et donc pour moi Redux à l'époque, j'avais ces concepts de reducers et ce flux très compliqué par lequel il fallait passer juste pour mettre à jour un petit bout d'état, et je n'arrivais juste pas à le piger. Donc j'ai construit un truc plus simple qui semblait marcher. Je l'ai utilisé — je faisais du bénévolat dans une association à l'époque — et ils ont commencé à l'utiliser et leurs ingénieurs l'ont aimé. Et puis quand j'ai rejoint Facebook, j'ai vu beaucoup de frustration autour de l'usage de Redux parce qu'il y avait un groupe interne pour les gens qui utilisaient Redux, et il y avait toutes ces questions où les gens posaient les mêmes questions que moi. Quand, en tant qu'ingénieur ou personne produit, tu rencontres un problème, parfois c'est juste toi. Souvent c'est aussi d'autres gens. Et je pense que c'est important de développer le sens d'araignée pour savoir quand ce problème pourrait être partagé. Et c'était un problème qui était vraiment partagé. Je pouvais le voir dans les posts de support et par la difficulté que mon équipe avait avec Redux. Donc j'ai lancé Undux en interne, et Undux c'est… ça va. Ce n'est pas un super produit, mais au moins c'est mieux que Redux. Et chez Facebook je ne savais pas comment obtenir de l'adoption. Donc j'ai posté à son sujet. Quelques personnes ont commencé à l'utiliser. Je me souviens que Jeff Case dans l'équipe notifications était un gros adopteur précoce et on a passé des nuits tardives à déboguer des bugs liés aux notifications vraiment costauds à cause de ça. Et je voulais plus d'adoption. Donc ce que j'ai fait, j'ai écrit un petit script et j'ai scrapé le groupe des gens qui signalaient des problèmes et je les ai juste comptabilisés par équipe. Puis j'ai contacté en chat le tech lead et le manager de chaque équipe et j'ai planifié un tech talk juste pour cette équipe. Et globalement j'ai dû faire peut-être 20, 30, 40 tech talks sur quelques semaines.

12:45 Et je me souviens juste de faire du vélo sur le campus Meta et de faire ces talks, et c'était tellement fun parce que les gens étaient tellement engagés et tellement excités que quelqu'un se soucie de résoudre ce problème qu'ils ont vraiment. Et à un moment Undux était le framework de gestion d'état le plus populaire chez Facebook, puis il a été assez vite remplacé par Recoil et des alternatives plus modernes, et de nos jours c'est genre Relay et ce genre de choses. Est-ce que ce genre de projet parallèle apparaît dans ta performance review, ou ça t'a aidé d'une façon ? Je pense que c'était dans ma performance review. Selon les standards Meta, c'est un peu la cerise sur le gâteau. Ce n'est pas vraiment quelque chose qui t'amène au niveau suivant en soi. Mais j'avais beaucoup d'autres quêtes annexes à cette époque aussi. À un moment je suis devenu vraiment à fond dans TypeScript, et c'était dans la boîte précédente. On l'utilisait. Il n'y avait pas beaucoup de bonnes ressources. Donc j'ai commencé à écrire un livre dessus parce que je me suis dit « quelqu'un devrait faire ça, c'est dingue que ça n'existe pas ». Ce langage est juste magnifique. C'est un design étonnamment bon. Il a toutes ces idées qu'aucun autre langage n'avait à l'époque. À l'époque il n'y avait pas de types conditionnels, mais les types conditionnels, les types littéraux pour tout, les types mappés — ce sont des trucs absolument dingues. Même le Haskeller le plus chevronné va être impressionné par ce genre de fonctionnalité de langage, mais personne n'écrivait là-dessus, donc je suis devenu super à fond et j'ai écrit ce livre et ça a juste bouffé genre un an de ma vie. [rires] Je ne le recommanderais pas. Mais c'était vraiment fun d'aller vraiment en profondeur, et j'ai aussi lancé le plus grand meetup TypeScript du monde à l'époque à San Francisco, et c'était une chance vraiment cool de rencontrer — il y avait Ryan Dahl qui a créé Node.js, toutes ces célébrités JavaScript — et ça m'a fait réaliser que tous ces gens sont juste des gens, et que tout le monde construit juste des trucs cool, certains cools, certains cools à un moment particulier, mais c'est juste des gens et n'importe qui peut faire ces trucs.

14:47 As-tu fini par utiliser TypeScript ou cette profondeur technique plus tard chez Meta, ou même chez Anthropic ? Ouais, c'est drôle. Avant je ne me souciais pas des langages, puis à un moment, il y a peut-être 10 ans, je faisais de la moto et j'ai eu un accident assez grave en fait. Je me suis cassé les bras.

15:05 Oh mon dieu.

15:05 Les deux.

15:06 Les deux. Ouais. J'avais genre deux écharpes.

15:08 Oh mon dieu. Comment tu as codé ?

15:10 C'était ça le plus dur. Je ne pouvais pas coder pendant genre un mois, puis mes mains me faisaient encore mal, donc je ne pouvais pas écrire du JavaScript, ce que j'écrivais à l'époque. Donc j'ai dû me diversifier et apprendre d'autres langages parce qu'ils utilisaient littéralement moins de frappes. J'ai commencé par CoffeeScript parce qu'il y avait moins de parenthèses et de trucs. Je ne pense même pas que ce langage existe encore, personne ne l'utilise. Mais c'est aussi comme ça que je suis entré dans Haskell et la programmation fonctionnelle. Parce que tu pouvais faire la même chose avec moins de frappes, et c'était littéralement la motivation à l'époque. Et puis à un moment je travaillais dans un hedge fund, c'était avant Facebook, et j'avais un collègue Rick qui était vraiment à fond dans Scala et je ne comprenais vraiment pas Scala, et il m'a vraiment lancé dedans et m'a entraîné dans ce côté programmation fonctionnelle, et c'est encore le seul livre technique que je recommanderais à tout le monde, celui qui a eu le plus grand impact sur moi en tant qu'ingénieur : ce livre, Functional Programming in Scala. Tu n'utiliseras probablement jamais Scala aujourd'hui, mais la façon dont il t'apprend à penser les problèmes de code est un tel changement par rapport à la façon dont la plupart des gens codaient, soit en pratique soit à l'école, c'est juste incroyable. Ça va complètement changer ta façon de coder. Donc pour moi c'était : Haskell et CoffeeScript comme premières langues clés, première étape, puis Scala, puis TypeScript, et je pense que ça a changé ma façon de penser parce que maintenant je pense en types quand je code. La chose qui compte le plus dans ton code, ce sont les signatures de types. C'est plus important que le code lui-même. Et bien faire ça mène à du code très propre. Donc même chez Facebook où j'écrivais surtout du Flow et du Hack, puis plus tard chez Instagram du Python, c'était très utile. Ici chez Anthropic j'écris surtout du TypeScript et du Python, donc c'est en fait assez pertinent, mais je pense que la plus grande leçon, c'est juste : pense en types.

17:07 À ce stade de ta carrière, tu as mentionné que tu es arrivé sous-leveled, comme ingénieur mid-level même si tu avais beaucoup d'expérience, et tu as dit qu'avec le recul tu as eu de la chance d'être sous-leveled. Quelle est la pensée derrière ça ?

17:23 Juste des attentes plus basses. Dans une grande boîte il y a à chaque niveau certaines attentes en termes d'impact projet, d'impact sur les gens, et tout ça, et les critères spécifiques sont différents d'une boîte à l'autre. Mais beaucoup, c'est de l'impact projet ou cocher un tas de cases, et tout ça prend beaucoup de temps. Donc arriver sous-leveled m'a juste donné l'espace pour explorer et construire des trucs cool pour le plaisir de construire des trucs cool. Carrément. Et je me demande si ça aide aussi à construire de l'élan. Ce que je veux dire, c'est que si tu arrives comme mid-level ou E4 et que tu déchires, tout le monde dit « Boris est incroyable, c'est dingue », contrairement à si tu arrives à tes attentes et que tu fais bien. Je pense qu'il peut y avoir cet effet où, quand tu arrives et que tu épates tout le monde, tu as une si forte première impression, ça peut aider à construire une bonne réputation qui te donne plus de crédibilité, plus de projets, etc. à l'avenir.

18:42 Ouais, je pense que c'est totalement vrai, et c'est probablement un bon conseil pour n'importe quelle boîte : souvent les ingénieurs changent de job et ils poussent fort « je veux aller dans une autre boîte et je veux un niveau +1 ou autre », et en fait il y a beaucoup d'inconvénients à ça, comme tu l'as dit. Passons à ce qui t'a fait promouvoir staff ou E6 chez Meta. L'histoire derrière : où tu en étais et ce qui t'a fait passer dans ce rôle plus orienté leadership ? Ce qui se passait, c'est que Chats and Groups était lancé et tournait, avec une équipe dessus. Et j'avais fait beaucoup de JavaScript avant de rejoindre, mais chez Facebook je n'avais jamais écrit de JavaScript parce que c'était tout du PHP.

19:28 Donc je voulais juste écrire du JavaScript. Et on avait cette interface web. Et pour les groupes Facebook en particulier, beaucoup de gens utilisent le web plutôt que le mobile parce que, par exemple pour être admin de groupe, c'est juste plus facile sur un grand ordinateur avec un clavier. Et à l'époque le site était vraiment bancal. C'était un site statique, tout en PHP. Il y avait ces petits bouts de JavaScript injectés à différents endroits, toutes sortes d'états incohérents et tous ces problèmes qui en découlent. Ça ne semblait juste pas une bonne UX. Donc je voulais le réécrire en JavaScript, et j'ai reçu beaucoup de résistance de l'org à l'époque. La grande raison, c'est que l'infra n'était juste pas prête. Heureusement, au même moment, Comet démarrait — c'était la réécriture de facebook.com sur desktop. C'était Tom Occhino, qui est maintenant chez Vercel, c'était Jing Chen. Il y a un tas de ces gens clés qui travaillaient là-dessus. Et je voulais vraiment être impliqué. Donc j'ai tendu la main et demandé comment aider. Et j'ai offert les groupes Facebook comme cobaye. Et je n'ai demandé à personne. Juste [rires] je l'ai fait. Puis plus tard je suis allé voir mon leadership des groupes Facebook en disant « hé, Comet arrive, ça va être beaucoup de boulot, on peut prendre de l'avance ». Poser le standard pour tout le monde, construire des relations avec ces autres équipes. Et j'ai quand même reçu pas mal de résistance genre « hé, tu ne peux pas mettre 20 ingénieurs là-dessus ». Et après pas mal de revues et de marchandage pour des ingénieurs, on en a mis genre 12 parce que c'était une migration assez grosse. Ça allait prendre genre un an. Groups est la plus grande surface produit de tout Facebook, ce qui est en fait assez surprenant. Et la migration a plutôt marché, et un truc assez fun au-delà de construire des relations et amitiés avec cette équipe infra avec qui je n'aurais jamais travaillé autrement — ce qui était en soi tellement gratifiant et fun — c'est qu'on a pu influencer la direction de Comet. Et c'est un peu bizarre parce que pour un projet infra, une équipe produit ne peut souvent pas influencer la direction, ils sont plutôt vus comme un client. Mais ici, parce qu'on a aidé à le co-construire, on a construit beaucoup des abstractions ensuite utilisées par d'autres équipes qui construisaient aussi sur Comet. Par exemple, une que je me rappelle, c'était les Relay mutations. Tu envoies des requêtes API et il te faut une certaine cohérence. Mais il y a ce bug où, disons qu'il y a un bouton et tu appuies dessus : à chaque appui tu envoies une requête POST, et à chaque appui ça bascule l'état du bouton. Pour une UX vraiment agréable, ce que tu veux c'est que dès que tu appuies, l'état bascule — ce qui veut dire une mise à jour optimiste. Mais aussi, quand la requête réseau revient, tu dois mettre à jour le cache local pour t'assurer que c'est cohérent. Et si tu martèles ce bouton, ce qui peut arriver c'est que les réponses arrivent dans le désordre et tu peux te retrouver avec un état différent de ce qui était dans l'UI. Donc j'ai écrit un système pour mettre les mutations en file. C'était de la cohérence au prix de la fiabilité, et c'était le bon compromis à l'époque. Et tout le monde a fini par l'utiliser, et c'est comme ça que j'ai rencontré Joe Savona et une partie de l'équipe Relay qui travaillait sur les data stores. Et c'était vraiment fun. Et c'est quelque chose que depuis, et avant, et chaque fois que je travaille avec des ingénieurs, j'adore quand les gens vont une couche plus profond et essaient juste de comprendre ce qui se passe : ce n'est pas parce que tu es ingénieur produit que tu ne peux pas faire de l'infra, ni parce que tu es ingénieur infra que tu ne peux pas aller parler aux utilisateurs — sois juste curieux de ces autres parties de la stack.

22:56 Carrément. Et dans ton initiative de prendre de l'avance sur Comet ou cette grosse réécriture JavaScript, tu as mentionné dans tes écrits que prendre de l'avance t'a donné beaucoup plus de contrôle et aussi la priorité sur les opportunités. Quand tu parles d'opportunités, est-ce de ça que tu parles, construire ces pièces fondamentales d'infra produit qui sont impactantes pour tous ceux qui adopteront la nouvelle plateforme ?

23:21 Ouais. C'est un exemple. Et puis un autre genre d'exemple : Comet était de bien plus haute qualité que ce qui existait avant parce que c'est une single page web app. Donc ça peut juste sembler bien plus soigné. Mais on n'avait pas encore défini ce que « qualité » veut dire côté produit. Donc j'ai écrit un tas de notes pour essayer de le définir, puis fait un tas de tech talks pour enseigner aux gens des autres équipes « voilà ce qu'on a appris sur la qualité ». Et juste lancer la conversation là-dessus. Tu as mentionné une grosse demande d'effectifs pour cette migration vers Comet. Je serais curieux de ce à quoi ça ressemblerait aujourd'hui avec ces nouveaux outils comme Claude Code, Codex, etc. Sachant ce que tu sais maintenant sur Claude Code, si tu étais en charge de faire le même cadrage pour le même job, combien d'ingénieurs penses-tu qu'il faudrait pour ce boulot de 12 ingénieurs ?

24:17 Ouais. Globalement pour migrer les groupes Facebook, ça a commencé avec 12 ingénieurs mais je pense qu'à la fin c'était genre 20 ou 30 ingénieurs pendant environ deux ans. Donc ça s'est avéré un assez gros projet. De nos jours ce serait peut-être, je sais pas, genre cinq ingénieurs pendant six mois, quelque chose comme ça.

24:37 Donc un quart du temps, et plus d'un tiers ou moins d'un tiers des ingénieurs aussi.

24:44 Ouais. Parce que tout le monde aurait juste un tas de Claude qui tournent en parallèle, tu le laisses mijoter quelques heures et il revient avec une PR, puis tu lui donnes genre Puppeteer pour qu'il puisse voir l'UI et ajuster, et je pense que ce serait à peu près tout. Et de nos jours le monde dans lequel on est est tellement différent du point de vue du code parce que les modèles évoluent si vite que si tu me poses cette question dans 3 ou 6 mois ma réponse sera totalement différente. Dans 6 mois la réponse pourrait être « en fait c'est un ingénieur ». Ça bouge tellement vite maintenant qu'il est vraiment dur de faire ces estimations ou de prédire comment ils vont changer.

25:22 À ce stade de ta carrière, tu as mentionné un truc, peut-être ironique, je ne sais pas. Tu as dit que c'est là que tu as appris à toujours présenter trois options dans les revues VP, puisque 80% du temps ils choisiront juste l'option du milieu, et puis ça dit que ton VP a choisi l'option du milieu, ironiquement. Quelle est la pensée derrière ? Ouais, c'est très ironique. Mais peut-être que c'était en fait un peu vrai chez Meta à l'époque. [rires] Je pense que les décideurs loin du travail veulent savoir que tu as fait la due diligence de trouver les bonnes options et les bons compromis et que tu as fait le travail, mais ils veulent aussi contribuer d'une façon à la décision. Donc l'option du milieu est la façon facile de faire ça. C'est un peu ironique parce que tous les leaders ne sont pas comme ça. Beaucoup font leur propre travail, font plus ou moins confiance à leurs équipes. Il y a tellement de façons d'opérer. Mais à l'époque on avait une leader assez peu technique et c'était la façon de l'aider à prendre des décisions. À ce stade de ta carrière tu avais la plus grande proximité que tu aies eue avec le management senior. Tu as dit que tu rapportais à un senior director à un moment et tu étais impliqué dans beaucoup de grosses conversations de cadrage. Quels sont les effets en aval de rapporter à quelqu'un d'aussi senior ?

26:43 Ouais, ça dépend de l'ingénieur et de la boîte. Par exemple, maintenant je suis chez Anthropic, et chez Anthropic ça n'a pas d'importance. Peu importe à quel niveau tu rapportes. Certaines des personnes les plus seniors de la boîte rapportent à des line managers. Beaucoup des line managers sont genre des ex-CTO. Donc ça n'a vraiment pas d'importance. Donc c'est une observation culturelle très spécifique à Meta. Je pense qu'il y a deux choses. Une, chez Meta, en tant qu'ingénieur tu devais toujours trouver du scope. Une partie tu la trouves toi-même, une partie ton manager t'aide à la trouver, ton tech lead, les gens dont tu t'entoures. Et le processus PSC, c'est fameusement « grow at Meta », donc tu dois constamment parler de ton impact, et le scope est le plus gros contributeur : si tu as assez de scope et que tu as bien exécuté, c'est de l'impact, c'est la formule. L'autre partie : chez Meta personne n'avait de titre, donc même les ingénieurs les plus seniors avaient le titre de software engineer, ce que j'adore vraiment. Les Bell Labs avaient ça avec « member of technical staff », et c'est vrai chez Anthropic aussi, mais on va encore plus loin ici : le titre de tout le monde est member of technical staff. Peu importe que tu sois ingénieur, PM ou designer, c'est le même titre. Et j'adore vraiment ça parce que, pour revenir à ce point de travailler en dehors de ton couloir et faire des trucs qui devraient juste être faits, peu importe ce qu'on attend personnellement de toi, ce genre de culture met juste ça en place. Je vois beaucoup des bénéfices du « pas de titres ». Je pourrais aussi voir un cas — peut-être seulement vrai pour les grandes boîtes — où tu contactes quelqu'un à travers la boîte et tu dis « hé j'aimerais faire cette collaboration », et si ton titre disait director ou autre, c'est un raccourci pour qu'ils comprennent à quel point te prendre au sérieux ou comment interagir avec toi, si tu es designer ou un autre rôle. Anthropic est devenu un peu plus gros maintenant. Tu vois quelque chose de ça ? Les gens te connaissent probablement tous, donc tu ne le vois peut-être pas autant.

29:01 Ouais, je pense que c'est vraiment l'inconvénient. Je pense que l'avantage l'emporte : tu dois gagner la confiance. Et c'est vrai, peu importe la boîte, tu dois la gagner. Et ce n'est pas parce que tu as fait un truc cool avant que tu mérites le respect — enfin, tout le monde mérite le respect — ça ne veut pas dire que tu devrais mériter l'autorité dans une nouvelle boîte, un nouveau contexte. Donc même pour les gens qui arrivent avec des titres de manager, tu dois en quelque sorte la gagner. Et d'une certaine façon, avoir un titre de manager rend un peu plus dur de gagner ce genre de confiance. Donc en tant qu'IC, tu dois la gagner de toute façon. Et je pense que l'absence de titres rend ça un peu plus facile. À ce stade tu devenais de plus en plus un tech lead ou über tech lead. Tu avais quelques histoires où tu as cadré du travail pour des centaines d'ingénieurs. Je me demandais : comment fais-tu ça s'il y a tant à cadrer et que tu es une seule personne ? Comment t'y prends-tu pour de si massives demandes de cadrage pour le leadership ?

30:03 Ouais, c'était une période totalement folle. J'ai beaucoup travaillé avec Tina Shutchman, qui est maintenant chez Microsoft, elle était ma manager à l'époque, puis Ephe qui a été mon manager après, et il y avait beaucoup plus d'investissement qui allait dans les groupes Facebook à l'époque. L'org était peut-être de 150 ou 200 personnes quand j'ai rejoint, et au moment où je suis parti chez Instagram c'était genre 600 ou 800 personnes. Il y avait ce sentiment de la part de Zach que l'app Facebook devrait être tout sur les communautés, et il voulait juste qu'on aille de plus en plus vite pour en faire une réalité, et en tant qu'exécutif, ta plus grande façon de faire ça c'est de mettre les bonnes personnes en charge des décisions, puis de leur donner des ressources. Dans le cas de Meta, c'est juste des ingénieurs — tu n'as pas besoin de GPU pour ça, tu as besoin d'ingénieurs pour faire des trucs. Donc on a pitché ce projet à Zach, ça s'appelait « communities as the new organizations », c'était le nom interne, et il a accordé un tas d'effectifs pour ça, donc on devait juste trouver ce que ces gens feraient. Et pour lui, je comprends : si le truc est important, tu dois mettre un tas de gens dessus. Avec le recul, ce que j'aurais fait différemment, c'est que j'aurais mis bien moins de gens dessus, parce que ce qui compte c'est résoudre les problèmes des gens et construire du produit génial, et ça doit en fait être bottom-up, et tu veux monter ça lentement à mesure que tu trouves le product-market fit pour de nouvelles lignes de produit — tu ne peux pas tout faire d'un coup. Et ouais, on devait juste cadrer tout ce truc. Il y avait des semaines où je devais faire un doc de cadrage du genre « OK, on va mettre 30 ingénieurs là-dessus, voilà trois options techniques, on va choisir celle-ci. Projet suivant, on va mettre 20 ingénieurs, voilà trois options, on choisit celle-ci. » Et juste faire ça encore et encore, juste pour avoir une certaine confiance que ce truc n'est pas totalement dingue. On a fait un cadrage technique de base, faisant grossièrement correspondre le nombre d'ingénieurs au projet. Et il y a des trucs assez fun : je me souviens qu'on essayait de fusionner les groupes Facebook et les pages à un moment, côté data model, et c'était cette migration très costaude, ç'aurait été — pour le faire complètement — genre plusieurs années et probablement des centaines d'ingénieurs, parce que tu dois le faire à travers le data model, la couche produit, les systèmes d'intégrité, les systèmes de pub, il y a toutes sortes de trucs à fusionner. Et à l'époque Yusef Carver venait de rejoindre, je crois qu'il venait soit de Profile soit d'Events, une org différente qui s'est jointe aux groupes pour faire ça, et il travaillait dessus mais galérait avec une décision, et je crois qu'il était même plus senior que moi mais il ne prenait juste pas la décision sur le data model. Donc j'ai pris un tas de gens et j'ai dit « bon, les tech leads de toute l'org, on va passer les 3 prochaines heures là-dessus aujourd'hui, et on va faire ce jeu où on conçoit de l'architecture ». Donc j'ai divisé tout le monde en deux équipes, je crois c'était blue team et green team, ou je ne me souviens plus. Et on a donné à tout le monde ce problème : comment fusionner ces data models ? Voilà les exigences. Et tout le monde avait 3 heures à un tableau blanc pour trouver un design. Et ce qui était cool, c'est qu'en entrant on n'avait aucune idée de comment faire parce que ça semblait un problème trop dingue. Mais en sortant, on avait deux designs qui étaient à 80% identiques. Donc c'était vraiment évident sur quoi on pouvait exécuter. Et les 20% où étaient les différences, c'était très évident où était le risque. Donc on pouvait front-loader un peu ce risque avec quelques spikes techniques. Mais aussi on pouvait juste démarrer l'exécution tout de suite parce qu'on savait exactement quoi faire.

33:31 Ouais, c'était vraiment intéressant quand j'ai vu ça : une compétition de design technique avec tous les ingénieurs seniors, et tu as juste mis les gens dans des salles séparées pour trouver — je n'ai jamais entendu un truc pareil. Quand tu as proposé cette idée de compétition de design dans l'org, les gens étaient excités, ou c'était une idée un peu folle ?

33:52 Ouais, c'était un peu fou. Avec ce genre de truc, tu dois juste le faire. Donc j'ai juste dit à tout le monde « hé, on fait ça ». Puis je l'ai mis dans le calendrier de tout le monde, et ça semble juste fun, tu vois ? En tant qu'ingénieur tu voudrais le faire. Mais je pense que c'est le genre de truc où parfois tu as besoin de consensus et parfois tu dois juste agir. Et dans ce cas, parce que le chemin n'était pas clair, c'était important d'agir. Mais en même temps je ne savais pas comment procéder. Donc on devait rassembler tout le monde pour construire du consensus. Et donc en tant que leader, tu jongles toujours avec ces deux choses.

34:23 Après cette expérience, qu'on te donne des centaines d'ingénieurs et qu'on te fasse cadrer des trucs, as-tu des conseils pour quelqu'un qui est tech lead et doit faire du cadrage rapide ? Quelque chose qui a bien marché pour toi ? Je pense que le plus gros écueil que j'ai vu, c'est les gens qui prennent juste trop de temps et entrent trop dans les détails. Il y a toujours un nombre infini de détails. Commence juste par un haut niveau. La plupart des cadrages techniques tu peux les faire en genre 30 minutes très grossièrement. Et si tu ne connais pas les systèmes, de nos jours tu utiliserais juste Claude Code dans le codebase et tu lui demandes « quels sont tous les systèmes impliqués ? ». Il peut juste faire ça pour toi. Et c'est un autre changement totalement dingue. Quand je faisais ces trucs, je n'aurais jamais imaginé que l'IA pourrait faire ça pour moi maintenant. Mais maintenant elle le fait. Mon plus gros conseil par le passé aurait été : time-box. Passe peut-être 30 minutes, max quelques heures. Si tu dois fouiller du code, contacte des experts, fais une liste d'experts, parle à tous, fais-leur passer le design en revue. Ne leur demande pas juste leur avis. Donne-leur un straw man, parce qu'alors ils peuvent vraiment te donner du feedback dessus et tu as quelque chose sur quoi partir. Pour continuer ton histoire de carrière : ce qui t'a fait promouvoir senior staff ou IC7, c'est les groupes publics sur Facebook. L'histoire de ton implication, et tout ce qui s'est passé d'intéressant ? Ouais. Les groupes publics étaient un de ces projets sortis du cadrage de « rendre les groupes Facebook plus axés communautés ». Il y avait ce changement très étroit qu'on voulait faire et qui semble si simple en surface, mais c'était si complexe en dessous. Et c'est drôle d'expliquer ça à quelqu'un qui n'était pas là. Ils disent « attends, c'est un changement d'une ligne ? » et je dis « non ». C'était très difficile à réaliser. Le changement, c'était : pour participer à un groupe Facebook public, tu n'as plus besoin de rejoindre d'abord.

36:18 Donc tu dis que tu peux juste voir, tu as un accès en lecture pour tous les groupes, ou les groupes publics ? Accès en lecture pour tous les groupes, et pour certains même accès en commentaire. Donc tu peux commenter sans rejoindre d'abord.

36:28 Intéressant.

36:29 Et le truc, ça semble un changement d'une ligne et c'était en fait un changement d'une ligne, mais il y a toutes ces implications en aval qui étaient si délicates. Une, dans le data model, il y a essentiellement un champ dans la base qui était « group member », et on a eu ce débat technique vraiment intense : ces gens qui commentent dans un groupe, sont-ils des membres du groupe ? Et le modèle a aussi changé : avant, pour rejoindre un groupe Facebook un admin devait t'approuver, donc il y a une sorte de vote de confiance pour que tu sois dans ce groupe ; après on est passés à ce modèle où pour rejoindre un groupe Facebook public tu appuies juste sur « suivre ». Et on a fait des allers-retours : devrait-ce être « rejoindre » ou « suivre », quel est le bon verbe ? Mais c'était essentiellement « suivre » parce qu'il n'y a pas d'action réciproque : si tu suis un groupe, es-tu membre ? Devrais-tu être stocké dans la même partie de la base ? Et on a fait des allers-retours là-dessus un moment. Je me souviens qu'à l'époque il y avait cet ingénieur très senior, Bob, le plus senior de l'org à l'époque, et il était très convaincu que ça ne devait pas être la même chose, et il nous a poussés assez fort, même si ç'aurait été une tonne de boulot d'ingénierie de migrer pour en faire un truc différent. Donc on a fait ce boulot parce qu'il était un des premiers ingénieurs des groupes Facebook, il connaissait ça très bien et il était très convaincu. Il y a un tas d'autres changements en aval autour de la modération et du nouvel outillage admin dont les admins auraient besoin pour gérer l'afflux de spam, etc. Et je me souviens d'avoir pensé que si n'importe qui peut commenter, les commentaires vont juste se remplir de spam. Et j'ai eu du mal à en convaincre les gens. Donc à un moment j'ai construit cette visualisation Monte Carlo de comment ça marcherait. C'était ce bloc-notes vraiment simple : un commentaire arrive, il y a une certaine probabilité qu'il soit bon ou mauvais, et ce qui arrive réellement aux commentaires. Et ça a fait un assez bon boulot pour convaincre les équipes d'intégrité de sauter dedans et d'aider. À l'époque l'équipe d'intégrité des pages a sauté dedans et a aidé avec le classement des commentaires, parce que classer les commentaires spam plus bas était le principal mécanisme technique pour que les gens ne les voient pas. Donc il y a un tas de ces implications en aval assez costaudes de laisser les gens participer. Il y a aussi cette migration de data model. Et donc pour tout faire, on a dû staffer une grosse équipe. On a embauché un nouveau director, Yammen, qui a embauché un tas d'ingénieurs. Il y a eu des transferts internes, certains des ingénieurs les plus seniors de l'org comme Henry Long, Joe Cham, quelques autres, et ils travaillaient tous dessus et j'étais au même niveau qu'eux, j'étais genre IC6 à l'époque et eux aussi, et je me souviens de ce syndrome de l'imposteur de devoir les diriger et les pointer vers du travail en sachant dans ma tête qu'on était au même niveau, même si les niveaux sont cachés. Tu le sais par les rumeurs. Avec le recul je pense que c'est un syndrome de l'imposteur mal placé parce que les niveaux n'importent pas du tout, c'est ma vision actuelle. Certaines personnes très juniors peuvent viser bien plus haut et te donner des résultats incroyables ; certaines très seniors peuvent te donner des résultats terribles. Donc le niveau n'importe en fait pas tant. Mais à l'époque j'y pensais vraiment et c'était un peu dur d'entrer dans ce rôle. Et finalement je l'ai fait. Et c'est drôle, finalement ce qui m'a fait promouvoir IC7, c'est d'avoir inversé cette décision de Bob, parce qu'il voulait faire cette grosse migration. Et on l'a faite. Et c'était, mec, tellement de boulot. C'était genre 6 mois ou un an de boulot juste à migrer des centaines et des centaines de call sites pour faire ça correctement. Et techniquement, ce qu'on a fait c'est qu'on a essentiellement juste ajouté un if-else à chacun de ces call sites au passage. On a audité tous les call sites, donc on savait que c'était sûr, mais on n'a pas changé la logique. Et donc ce qu'on a appris, c'est que oui, « member » est le bon champ pour modéliser à la fois les followers et les membres de groupe. C'était la bonne décision. Donc j'ai poussé le même ingénieur qui avait fait ça à le défaire. C'était la bonne chose de pousser cet ingénieur, parce que ça a montré de la maturité de sa part qu'il dise oui et soit capable de le faire. Il avait aussi le plus de contexte techniquement, donc il pouvait le faire le mieux. Et pour Bob, ça l'a rassuré sur moi en tant que leader technique parce qu'il savait que j'étais prêt à reculer et à challenger des décisions même prises par des gens seniors. Et au final c'était la bonne chose. Donc on a inversé la migration. Ça a aussi pris longtemps, mais au final ça a fait que tout le monde construisant sur cette infra pouvait le faire sans constamment buter sur « devrais-je utiliser ce champ ou celui-ci ? »

41:15 Ouais, je suis curieux de cette partie parce que tu as eu un fort désaccord technique avec Bob, un TL senior, mais l'issue à la fin semble avoir renforcé la relation. Il a été un champion pour toi dans ta promotion. Comment recommanderais-tu d'aborder un fort désaccord technique d'une façon qui ne blesse pas la relation ?

41:38 Le plus important, c'est que tu dois la gagner. Ouais. Tu dois juste gagner la confiance, et ça peut être aussi simple que ce que j'ai fait au début : juste être en désaccord et m'engager (disagree and commit), montrer que je suis prêt à le faire et à exécuter si quelqu'un d'autre pense que c'est une bonne idée et que je le respecte. Mais aussi tu dois montrer que tu as un bon jugement technique. Sauf que tu ne peux pas vraiment faire ça avant d'avoir gagné la confiance. Donc prends le temps de gagner cette confiance d'abord.

42:05 Et sur le syndrome de l'imposteur, à diriger ces ingénieurs aussi très forts, as-tu des conseils pour le surmonter ?

42:14 Ouais, juste ne te prends pas trop la tête. Personne ne sait vraiment ce qu'il fait, à n'importe quel niveau. Personne ne sait vraiment. On essaie tous juste de comprendre.

42:22 Plus facile à dire qu'à faire. Y a-t-il eu un déclic où tu as réalisé « en fait peut-être que je gère » ou « ce n'est pas si grave » ? Je ne pense pas, vraiment. Il n'y a pas eu un seul moment. Ça disparaît juste avec le temps. Et à chaque niveau, peu importe lequel, tu devrais toujours ressentir un peu de syndrome de l'imposteur, parce que si tu n'en ressens pas, alors tu ne te pousses pas assez fort.

42:45 À ce stade tu étais de plus en plus tech lead et donc tu écrivais de moins en moins de code. Et tu as mentionné que chez Meta surtout il y a des cas où d'autres fonctions sont sous-staffées, et tu vois ça comme une opportunité pour les ingénieurs d'être plus orientés produit et peut-être d'aider sur les opportunités PM. Quand dirais-tu qu'il faut aller dans cette direction plutôt qu'escalader et dire « hé, on a besoin de plus de support PM » et d'essayer d'écrire plus de code à la place ? Ouais, tu dois comprendre les compromis. Je pense que c'est le truc que beaucoup de gens ne pigent pas quand ils poussent pour des choses. Un mode d'échec très courant : un ingénieur pousse pour une idée puis devient frustré quand personne d'autre n'y adhère ou ne veut la financer, ou que l'org n'écoute pas, ou que son leader n'écoute pas. Mais ce que tu dois faire, c'est comprendre les compromis. Et quel que soit celui que tu essaies de convaincre, vois-le de son point de vue. De quoi se soucie-t-il ? Quels projets fait-il ? Contre quoi ce compromis se fait-il ? S'il fait ce truc, verra-t-il son travail comme un succès ? Donc c'est vraiment important, et pour certaines orgs, parfois elles n'ont pas de PM parce que ce n'est peut-être juste pas un projet très sexy et c'est donc dur à recruter, et peut-être que le leader ressent déjà cette douleur. Pour d'autres orgs, elles essaient de recruter des PM mais il y a juste des choses bien plus importantes où ces PM devraient aller. Pour d'autres orgs encore, elles ont peut-être trop de PM. Et donc, en fait, si tu demandes, c'est la bonne chose à faire, parce qu'elles pourraient juste retirer un PM d'un projet moins important et le mettre sur le tien parce qu'il est plus important. Donc c'est vraiment important d'être conscient de la situation, comprendre le contexte dans lequel tu es, et comprendre comment tes décideurs y pensent. À ce stade, et c'est un peu la fin de la partie un de ton histoire : tu attribues beaucoup de ton succès aux quêtes annexes et à ces projets parallèles, ou à une liste courante d'idées que tu appelais « idées du 20% time ». As-tu des conseils sur comment trouver des opportunités pour les ingénieurs ? Ouais, à un moment il y avait probablement — j'oublie les chiffres exacts — genre 5000 ingénieurs qui travaillaient sur ces quêtes annexes que j'avais cadrées et lancées à divers moments. Et donc à peu près chaque semaine je pense à un projet, juste en courant ou peut-être en codant, je pense à une idée, je fais une validation de base, puis je ping un ingénieur que je connais en disant « yo, ça t'intéresse ? », et je le connecte avec quelques autres ingénieurs qui pourraient être intéressés. Et ça s'additionne très vite. Une façon dont je pense vraiment à mon travail, c'est : comment puis-je en faire moins ? Et en tant qu'ingénieur, notre super-pouvoir pour ça c'est l'automatisation. Le truc le plus fastidieux, tu peux l'automatiser. C'est quelque chose de vraiment dur pour d'autres domaines, mais pour nous c'est cette chose incroyable qu'on peut faire. Et c'est un truc que beaucoup d'ingénieurs ne font pas pour une raison ou une autre, mais qu'on devrait tous faire tout le temps. C'est tellement important. C'est du levier. Du levier gratuit. Donc un truc que je faisais souvent : chaque fois que je faisais une code review, si je commentais un type de problème particulier, genre un problème de style, j'avais littéralement un tableur où je comptabilisais ce problème et je postais le lien vers la pull request, et je faisais ça pour chaque code review, et quand je commentais le même genre de truc plus de quelques fois, j'écrivais juste une règle de lint pour automatiser ça. Donc c'est un exemple de levier. Et à un moment j'avais automatisé la plupart de mes code reviews parce que j'avais une nuée de règles de lint qui faisaient tout ce travail pour moi. Et c'est en fait similaire parce que toutes ces quêtes annexes amélioraient l'infra produit et l'infra dev. Et ce sont des choses qui me ralentissaient dans mon code au quotidien. Et c'est pour ça que, quand je faisais du vibe coding, c'était en fait très dangereux : en tant qu'ingénieur tu dois être ancré à la réalité. Tu as besoin de cette intuition, et si tu n'es plus dans le code alors tu la perds très vite. C'est un endroit très dangereux où être. Donc pour moi, quand j'étais beaucoup dans le code, il en sortait toutes ces idées vraiment cool, et c'était du levier pas seulement pour moi mais pour toute l'équipe, encore à cause de ce principe que si tu as un problème, probablement d'autres l'ont aussi. Et j'ai fait YC à l'époque, et chez YC on t'apprend que d'abord tu construis pour toi. Tu dois construire des trucs géniaux, des trucs que les gens adorent. Mais si tu essaies de trouver un marché pour qui construire, tu commences par construire pour toi. Et c'est un assez bon indicateur que d'autres gens ont probablement le même problème.

47:19 Ouais. Il y a une citation que tu as écrite que j'ai trouvée vraiment bonne. Tu as dit qu'une meilleure ingénierie est la façon la plus facile de faire grandir ton réseau et de gagner en influence en tant qu'ingénieur. Je vois totalement comment ta sphère d'influence allait bien plus loin que le code que tu écrivais parce que tu passais aux gens toutes ces super idées et tu les supervisais. Le levier est vraiment dingue.

47:44 Absolument. Ouais. Et c'est aussi juste un exemple d'être contextuellement, ou situationnellement, conscient.

47:50 Parce que chez Meta à l'époque les ingénieurs étaient évalués dans le cycle de performance, on regardait l'impact projet, les gens — tu te souviens de l'autre

47:58 direction

48:00 et l'excellence d'ingénierie

48:02 et l'excellence d'ingénierie, ouais. Et l'excellence d'ingénierie, c'est un truc avec lequel beaucoup d'ingénieurs galéraient, donc j'étais une des personnes qui arrivait et disait « hé, si tu veux faire de l'excellence d'ingénierie, voilà un projet », et les gens sont déjà incités à le faire. Donc ils le voient comme une opportunité. Et je pense que c'était une chance pour moi d'affûter mes compétences à travailler avec les gens, où tu ne veux jamais dire à quelqu'un quoi faire, dans aucun contexte. Dans un contexte personnel, dans un contexte de travail, tout le monde déteste qu'on lui dise quoi faire. Mais si tu comprends ce qu'une personne veut, alors tu peux aller voir la bonne personne avec une opportunité prête et elle la voit comme une opportunité. Et ça marche toujours mieux pour tout le monde. Quand je pense à ces idées du 20% time, il y a le haut du funnel — trouver les idées — et puis exécuter dessus, faire en sorte que quelqu'un le fasse, que ce soit toi ou un autre. Ce qui m'intéresse, c'est le haut du funnel : comment source-tu autant d'idées en tant qu'ingénieur pour ces quêtes annexes impactantes ?

49:06 Juste du bon sens. [rires] Je ne sais pas. Peut-être le sens d'araignée. Je ne connais pas le bon mot. Comment ? Quel serait un exemple concret ?

49:15 Ouais, un exemple vraiment concret : je pense que les règles de lint en sont un bon. Peut-être un autre : il y avait tous ces cas où on avait des SEV (incidents) parce que les groupes Facebook n'étaient pas testés avec de très grands ensembles de — c'est un peu une façon Facebook de dire des lignes dans une base. Donc tu pourrais imaginer un groupe Facebook avec 10 millions de membres. Personne n'a jamais testé ça. Il n'y a pas de test unitaire pour ça. Tu ne le vois qu'en production. Et quand j'ai regardé à travers l'org, j'ai commencé à voir des cas similaires. Par exemple, si tu as un profil avec 20 millions de followers, beaucoup de choses cassent. Mais évidemment personne ne teste ça de façon automatisée juste parce que c'est un peu pénible d'écrire un test unitaire avec autant de données. Et donc j'ai pitché un ingénieur pour construire une façon d'écrire des tests unitaires pour de grands ensembles de données — un très gros objet, un groupe avec beaucoup de membres, un profil avec beaucoup de followers, un événement avec beaucoup de participants. Et je crois que cette infra existe encore. Et ça prévient beaucoup de problèmes, et c'est quelque chose que tu peux cadrer, puis il a amené un tas d'autres ingénieurs pour faire le boulot et l'aider. Donc je suppose, pense juste aux problèmes que tu rencontres vraiment au quotidien.

50:27 Compris. Donc pense aux problèmes, et si tu rencontres ce problème de façon répétée, alors c'est le moment d'automatiser, et c'est un super projet de meilleure ingénierie.

50:38 Ouais. Exactement. Si tu rencontres le même problème genre deux ou trois fois, tu devrais probablement regarder autour pour voir si d'autres gens rencontrent ce problème aussi.

50:47 La dernière étape de ta carrière chez Meta, c'est là que tu as eu la promo E8. Je sais que tu as changé d'org. Tu as fait toute ta croissance dans les groupes Facebook puis tu es passé chez Instagram. Quelle est l'histoire derrière ce changement vers Instagram ? À l'époque ma femme et moi sortions encore ensemble. Et elle vivait à Berkeley, je vivais à SF. Et à un moment elle dit « j'ai trouvé le job de mes rêves ». Et je dis « génial, super ». Puis elle dit « on va devoir déménager ». Et je dis « OK, super ». On sortait ensemble depuis genre 3 mois à l'époque et on décidait un peu si on continuait à sortir ensemble, et elle disait « ouais, on devrait déménager si tu veux continuer à sortir ensemble », et je disais « ouais OK, je veux, faisons-le ». Et le job s'est avéré être dans le Japon rural, genre au milieu de nulle part, et j'essayais de comprendre comment faire parce que j'aimais vraiment le travail que je faisais.

51:46 Donc d'abord j'ai parlé au leadership des groupes Facebook et essayé de monter un bureau Japon pour les groupes Facebook. Ça n'a pas vraiment marché pour un tas de règles organisationnelles. Puis j'ai essayé avec l'org VR, et ça marchait en fait, mais la personne qui sponsorisait ça est partie chez genre YouTube. Et puis à l'époque Will Bailey m'a contacté, il était au bureau Instagram de Tokyo, il faisait partie de cette équipe de lancement pour Instagram, et il disait « hé, je veux faire grandir ce bureau, tu veux en faire partie ? ». Et j'ai dit « ouais, faisons-le ». Et je ne connaissais rien. Je n'avais même pas Instagram installé à l'époque. Je ne l'avais jamais utilisé de ma vie. Donc j'ai dit oui puis j'ai immédiatement téléchargé Instagram, et j'ai déménagé genre la semaine suivante. Enfin, en fait j'ai eu quelques semaines aux US. Mais j'ai déménagé assez vite. Et je suis vraiment tombé amoureux de la culture Instagram. C'était très différent de la culture Facebook. Gros accent sur construire des produits géniaux, livrer des trucs que les gens utilisent, penser les choses pas juste d'un point de vue données mais aussi humain et expérience. Et tu vois ça dans l'app et dans le soin qui y est mis. Des cultures d'ingénierie, de produit et de design complètement différentes entre les deux boîtes. J'ai tellement appris dans cette équipe et c'était un voyage tellement fun.

53:16 Tu as mentionné le « unshipping ». Qu'est-ce que c'est ?

53:21 Le unshipping, c'est l'idée que si tu ajoutes juste des fonctionnalités à une app, c'est cool pour un petit pourcentage d'utilisateurs, mais c'est en fait mauvais pour la plupart des utilisateurs qui n'utilisent pas la fonctionnalité. Donc tu peux imaginer une app où tu n'ajoutes que des fonctionnalités. Avec le temps, elles s'accumulent. Et si chaque fonctionnalité est utilisée par genre 10% des gens, l'utilisateur moyen voit un tas de fonctionnalités qu'il n'utilise pas. Donc ça semble encombré et confus. Et quand ils ouvrent l'app, ils ne savent pas quoi faire. Et avec le logiciel, fondamentalement, l'écran a une taille limitée. C'est l'espace limité, une ressource limitée pour laquelle toutes les fonctionnalités se battent. Donc en ajoutant une fonctionnalité, tu enlèves l'opportunité d'une autre que la personne aurait pu utiliser. Et donc le unshipping, c'est l'idée que tu dois atteindre une certaine barre d'usage, et si une fonctionnalité ne l'atteint pas, on supprime juste la fonctionnalité. Un petit pourcentage d'utilisateurs sera furieux, mais c'est en fait génial pour la majorité, et en moyenne c'est vraiment génial pour tout le monde.

54:22 À ce stade de ta carrière, tu n'as pas juste changé d'org, tu as déménagé à l'autre bout du monde pour bosser chez Instagram. Et quand tu es un tech lead si senior avec beaucoup de crédibilité dans ton org existante, c'est bien plus facile de faire avancer les choses ou au moins d'influencer parce qu'ils disent « oh je connais Boris et son travail passé ». Comment as-tu construit ta crédibilité chez Instagram alors que tu étais si loin de tout le monde ?

54:52 Je pense qu'au début beaucoup du mérite revient à Nam Nguyen, qui est toujours le VP of Eng chez Instagram, et Jeff Hang, mon director à l'époque qui est maintenant VP. Et Will. Il y a eu beaucoup de connexions faites par ces personnes. Par exemple, Nam disait « hé, tu aimes vraiment travailler sur la qualité du code et la réduction de tech debt, qu'on appelle better engineering chez Meta », et il m'a connecté avec les gens qui travaillaient dessus, comme Lucas Camera, Gabe et un tas d'autres. Donc ces connexions ont été vraiment utiles. Et puis beaucoup, c'est que j'ai juste dû regagner la confiance. Et honnêtement c'est une chose saine. Et c'est une des choses vraiment géniales de la culture d'ingénierie de Meta qu'il n'y ait pas de titres. Donc tu dois constamment regagner ta confiance. Même si j'étais un super ingénieur dans le passé, je ne l'étais peut-être pas chez Instagram. Et si je ne l'étais pas, alors je ne mérite pas d'influence, je ne mérite pas une voix très forte que les gens écoutent. Donc j'ai dû la gagner comme tout le monde. Mes premières semaines, j'ai passé beaucoup de temps à rencontrer des gens, cartographier l'org, cartographier les objectifs, écrire beaucoup de code pour connaître le codebase. Mais au Japon c'était totalement différent parce que 9h heure de Tokyo c'était genre 19h heure de New York. Il n'y avait juste aucun chevauchement de fuseau horaire.

56:25 C'était rude. Ouais. Mais c'était aussi génial parce que dans les quelques années d'avant je faisais tellement de réunions et de docs que je ne codais juste pas. Donc je commençais à me sentir assez malheureux parce qu'en tant qu'ingénieur on code, c'est ce qu'on fait, c'est la raison pour laquelle on choisit ce job. Pour moi, quand j'écris du code, j'ai une relation émotionnelle avec le code, et c'est quelque chose auquel je pense quand je suis vraiment plongé dans un problème. J'en rêve. Donc c'est tellement important pour moi de coder. Et quand je ne le faisais pas pendant des années, c'était rude. Et je commençais un peu à burnout. Donc c'était en fait un cadeau d'être dans ce fuseau horaire où je ne pouvais littéralement pas faire de réunions parce que les gens n'étaient pas réveillés ou ne voulaient pas faire de réunions à 21h juste pour parler. Donc je ne faisais plus de one-on-ones. Et c'est encore quelque chose que je ne fais pas. Je ne fais toujours pas de one-on-ones réguliers. Et je pouvais juste passer beaucoup de temps à coder. Et ce que j'ai réalisé, c'est que j'étais un des rares ingénieurs chez Instagram à l'époque qui codait autant. Les gens codent, mais pas tant parce qu'il y a tout ce truc qui remplit ton temps : réunions, docs et autres obligations. Et je pouvais faire un tas de trucs que tout le monde voulait faire mais n'avait pas le temps. Et c'était un peu un super-pouvoir dans cette org. Et assez tôt, Nam m'a connecté avec Joel Pamer, qui est toujours un bon ami et mentor, il est chez Google maintenant. Et on a commencé à parler — à l'époque le codebase était écrit en Python, et c'était rude pour plein de raisons, et vraiment le codebase aurait dû être migré vers Hack, le monolithe principal de Facebook, où est tout le support de langage. Il y a tellement d'infra, HHVM est une stack de serving web absolument phénoménale. Il n'y a rien d'autre comme ça en termes d'efficacité. Si tu utilises GraphQL, tu dois absolument l'utiliser parce que c'est tellement optimisé pour ce truc. Et Instagram n'utilisait juste rien de ça. Et l'ingénierie en souffrait. Aux tout débuts, quand Mike Krieger était chez Instagram, le principe de base pour les décisions était « fais le truc simple qui marche ». Et ça marchait vraiment bien. Mais à un moment ça a arrêté de marcher une fois qu'on arrive à genre mille, deux mille ingénieurs sur le codebase, et tant d'années de tech debt et de produits construits les uns sur les autres. Tu dois prendre des décisions légèrement différentes de celles que tu aurais prises au début. Donc même si Python était absolument la bonne décision au début, ce n'était pas la bonne au moment où j'y étais, et c'était douloureusement évident en tant qu'ingénieur, et beaucoup d'autres le voyaient, mais ce qui les arrêtait c'était juste la quantité de boulot que ça aurait pris. Donc j'ai commencé à cadrer ça et à comprendre ce qu'il faudrait. Et j'ai commencé par trouver les gens qui seraient en désaccord. Il y a un tas de ces vieux de l'infra qui pensaient que c'était une idée terrible et ne marcherait jamais. Donc je suis allé leur parler d'abord autour d'un repas à New York, on a pris un tas de bières et on a juste appris à les connaître comme personnes avant même de parler du problème technique. Tu dois construire la confiance. Et c'est encore beaucoup de mes amis aujourd'hui. Et après avoir construit cette confiance, j'ai aussi appris qu'il y avait un tas d'autres gens qui voulaient en fait faire ça et avaient un peu peur de le dire. Donc ces gens sont aussi sortis du bois. Et finalement on a commencé à cadrer ça et ce projet s'est lancé. Et il continue encore aujourd'hui. Et il y a beaucoup d'ingénieurs dessus. Mais c'est drôle parce que chez Facebook ce genre de problème arrive rarement parce que l'org est si orientée ingénierie. Chez Instagram il y avait beaucoup de problèmes de cette forme parce que l'org est très orientée produit. Donc il n'y a pas beaucoup de temps pour ces initiatives orientées ingénierie. Ce projet, à un moment tu l'as lancé, cette initiative bottom-up, puis à un moment c'est devenu assez prioritaire pour nécessiter le support en personne de quelqu'un qui n'était pas au Japon, et je comprends que Jake Bolam est quelqu'un que tu as aidé à entrer sur le projet et il a pris plus un rôle de lead, mais basé géographiquement proche de tout le monde pour aider à le piloter. Tes réflexions sur ce point de délégation ? Quand décides-tu de déléguer quelque chose d'aussi gros, et quand décides-tu « j'ai besoin d'être encore là », et comment navigues-tu ce compromis ? Jake est incroyable. On est amis. Chaque fois que je vais à Seattle on se voit, et c'est un des meilleurs ingénieurs que je connaisse. Donc c'était évident qu'il serait un bon owner. Les mêmes règles de délégation s'appliquent toujours. Tu ne délègues jamais le truc que tu ne veux pas faire. C'est un peu la règle la plus importante. Tu délègues toujours le truc que tu veux faire et que tu connais bien, parce qu'alors tu peux monitorer le progrès et t'assurer que ça va bien. Et il y a ce super livre, High Output Management d'Andy Grove, l'ancien CEO d'Intel, le titre le plus ennuyeux du monde, mais c'est le meilleur. Et un des conseils, c'est : délègue le truc que tu aimes faire pour pouvoir monitorer le progrès. Donc c'est un peu la même chose. Tu délègues un peu, tu checkes. Plus tu as de confiance, moins tu as à checker. Et avec Jake, il est si bon techniquement et si proactif qu'il y avait très peu à faire. C'était très en bonne voie dès le début. Et donc je pense que ça, couplé à d'autres travaux — une grosse migration vers GraphQL pour moderniser une partie du data model d'Instagram — a fini par te faire promouvoir à ce niveau principal avant de quitter Meta. Quelle était l'histoire derrière la promotion, ou tout ce que tu pourrais partager ?

1:01:58 Je pense que dans un one-on-one avec Will, mon manager, il a dit « hé, je pense qu'on devrait te présenter pour IC8 ». Et j'ai dit « cool ».

1:02:08 Et c'était à peu près tout. Je n'y avais pas vraiment pensé. Ouais, ce n'est pas quelque chose que j'avais vraiment demandé.

1:02:13 Je pense que Will fait juste un super boulot de reconnaître les gens et de défendre son équipe, et il sentait que j'étais prêt, et voilà. À aucun moment de ton parcours — parce qu'on dirait que tu étais impact et impact uniquement, et ton levier et ta crédibilité grandissaient, et les promos étaient ce truc à retardement qui arrivait comme sous-produit — je suis curieux : pour structurer ta pensée sur comment obtenir plus de levier ou plus d'impact, as-tu déjà pensé aux niveaux, ou dirais-tu qu'il vaut mieux ne pas penser « quel est le niveau suivant » mais plutôt en termes de levier ou d'impact ? Tu dois penser à ce à quoi servent les niveaux. Les niveaux existent pour que la boîte puisse communiquer à un ingénieur ce qu'elle attend de lui. Ils existent aussi pour qu'il y ait de la responsabilisation : par exemple en performance reviews, tu peux comparer un ingénieur d'un niveau à un autre du même niveau, et aussi côté finance, différents ingénieurs coûtent un montant différent. Donc tu peux penser au portefeuille que tu veux. Donc les niveaux existent pour des raisons d'entreprise, pas pour des raisons d'ingénieur. Et pour moi, ça n'a juste jamais été la façon dont j'ai pensé à tout ça. Ce que j'aime faire, c'est travailler sur des projets intéressants. J'aime cerner les problèmes et les résoudre. J'aime rendre les choses que les gens utilisent agréables, les produits qu'ils utilisent agréables. C'est ce qui me motive vraiment. Donc pour moi ça n'a jamais vraiment été la façon dont j'y pensais. Ma première semaine chez Facebook j'étais IC4 et j'avais toutes ces idées de trucs qu'on devrait construire. Donc j'ai juste commencé à écrire des briefs produit. Puis je suis allé voir le VP de connectivité et lui ai pitché une idée, et il n'a rien compris du tout et l'a trouvée terrible. Et ça n'a pas marché. Puis j'avais une autre idée pour Messenger et je l'ai pitchée, et ils ne l'ont pas faite non plus. Mais ils ont en fait fini par la construire quelques années plus tard, cette idée particulière. Donc ouais, pour moi c'est juste : quelles sont les idées cool, comment puis-je aider, qui d'autre est intéressé, et comment construire des trucs cool ? Tu as quitté Meta pour Anthropic. Je suis très curieux de ta réflexion sur l'aller chez Anthropic.

1:04:32 Je me souviens d'avoir utilisé ChatGPT pour la première fois à sa sortie. C'était il y a des années, et j'étais au Japon. J'étais le seul ingénieur de ma ville, la seule personne qui parlait anglais dans ma ville, et il n'y avait juste personne à qui parler de tech, et chaque matin je lisais Hacker News, et je me souviens d'avoir utilisé ChatGPT et d'avoir été époustouflé par le produit et par ce sentiment qu'il me donnait — de nos jours on le tient pour acquis, mais les LLM sont juste magiques. C'est une technologie absolument incroyable. Et maintenant ma vision a changé. Pour moi les LLM sont une sorte de forme de vie alienne qu'on a la chance de nourrir et de faire venir à l'existence. Ce n'est pas juste une technologie. Et je suis aussi un très gros lecteur. Je lis beaucoup de SF, c'est un peu mon grand genre. Et à l'époque je me suis dit « oh mon dieu, je dois travailler sur ce truc ». Et quels sont les labos qui travaillent dessus ? Donc je suis allé parler à des amis travaillant dans divers labos. Et quand je suis venu chez Anthropic, je me souviens de mon premier déjeuner, avec Ben Mann, un des fondateurs ici. On était à déjeuner avec lui et un tas d'autres gens. Et j'ai mentionné ce bouquin de SF bizarre que j'aime, je crois que c'était de Greg Egan, un auteur de hard SF. Et je n'avais littéralement jamais rencontré quelqu'un qui ait lu ce livre. Et à table j'ai donné une anecdote tirée de là. Et tout le monde à table a dit « oh ouais, ce livre était bon, mais et cet autre livre ? ». Et c'était juste ce groupe de gens, de nerds intenses de SF, ces gens qui pensent si profondément à ces mêmes problèmes qui me tiennent à cœur. Et l'autre partie pour moi, c'est qu'en lisant beaucoup de SF tu as une certaine idée, de façon très spéculative, de comment ce truc peut se dérouler. L'IA est tellement transformatrice pour la société. Je pense qu'elle frappe l'ingénierie d'abord et va frapper chaque partie de la société. Elle va tout affecter. Et on voit les toutes premières vagues de ça en ce moment. Et j'avais assez lu pour connaître les mauvaises façons dont ça peut se dérouler, et il peut y avoir tellement de façons dont ce truc tourne mal. Donc pour moi Anthropic était le choix évident parce que je voulais être à un endroit où, de la plus infime façon, je pourrais m'assurer que ce truc se passe bien — ce qui, en tant qu'ingénieur, c'est tout ce que je peux faire. Et c'est drôle. Avant de rejoindre, je prenais un peu la sécurité au sérieux, comme un truc qui peut arriver. Et chez Meta c'était toujours vu comme une sorte de taxe où les équipes d'intégrité te font faire des trucs mais ce n'est pas le truc que les gens sont vraiment excités de faire parce que ce n'est pas le produit. C'était ma vision de la sécurité avant, mais en même temps je savais spéculativement que ça pourrait être très différent. Et maintenant chez Anthropic, je sais que c'est complètement différent, et je vois chaque modèle qui sort et les nouveaux risques qui viennent avec, et comment en tant que boîte on joint le geste à la parole en termes de combien de compute va à la recherche en sécurité et en alignement, combien de gens travaillent dessus. On a retenu des sorties de modèles par le passé parce qu'on ne savait pas qu'ils étaient sûrs, donc on a dû s'assurer qu'ils l'étaient avant. Et avec Opus 4 les risques ont juste beaucoup monté : si le modèle peut concevoir des biovirus et faire ces choses vraiment dangereuses — et pas juste, le risque de base c'est genre la manipulation d'élections, ce qui était un gros sujet, un risque pour un modèle de bas niveau. À mesure que les modèles deviennent plus dangereux, les risques montent, et très vite tu entres dans ce territoire où les gens peuvent utiliser le modèle pour construire des choses réellement dangereuses pour l'humanité. Pas juste la politique d'un pays mais littéralement l'existence de l'humanité. Et ce n'est pas de la SF. C'est un vrai risque aujourd'hui qu'on doit activement combattre. Et donc pour moi, juste pouvoir faire partie de ça et y contribuer un peu, c'est ce qui m'a décidé. Et quand tu as rejoint, en pensant aux cultures d'ingénierie d'où tu venais comparées à Anthropic, y avait-il des différences vraiment frappantes ? Ouais, je dirais deux choses. Une, étant encore une startup, il y a beaucoup de bon sens. Et c'est drôle, c'est quelque chose que toute grande boîte perd, et c'est un truc que tu dois combattre parce qu'avec le temps les décideurs s'éloignent de l'impact de leurs décisions, que ce soit le produit, les gens ou autre. Tu dois inventer toutes sortes de processus pour les rapprocher et améliorer la qualité de décision, mais étant encore une startup, tout le monde a juste du bon sens et fait généralement la bonne chose. Donc je n'ai pas à passer beaucoup de temps à convaincre les gens. Si on devrait juste faire un truc, c'est évident et tout le monde le fait. La deuxième chose, pour moi personnellement, quelque chose que j'ai appris avec le temps, c'est que ce qui me motive le plus c'est la mission. C'est tellement important et c'est ce qui me fait venir au travail chaque jour excité. C'est ce qui me fait coder le week-end parce que je veux le faire, pas parce qu'il y a une deadline. Je l'ai beaucoup ressenti dans les groupes Facebook. C'était très orienté mission. Et pendant longtemps Jen Dolski était la VP, elle était l'ancienne CEO de change.org. Et elle dirigeait tous les groupes Facebook comme une association : elle avait une théorie du changement, cette théorie sur comment connecter les gens à des gens d'esprit similaire pour former des communautés, et c'était tellement motivant. Et chez Instagram, peut-être à cause de la distance géographique ou autre chose, je n'ai juste jamais tout à fait ressenti cette même mission. Mais chez Anthropic je la ressens si fortement, et c'est probablement le truc le plus excitant pour moi. Tu es crédité comme le créateur de Claude Code, et tu as raconté cette histoire à beaucoup d'endroits, mais je suis curieux : je parlais avec un ami de l'environnement quand Claude Code est arrivé, et il y avait en fait beaucoup d'outils concurrents existants qui se branchaient sur le modèle. Qu'est-ce qui était différent avec Claude Code, qui l'a fait gagner et prendre comme une traînée de poudre en interne ? À l'époque le code avait l'air très différent. Si tu pensais au code IA, les gens pensaient à l'autocomplétion. C'était essentiellement ça. Il y avait quelques agents très précoces, mais c'était une chose secondaire à côté de l'autocomplétion. Et souvent c'était utilisé pour du Q&A, pas vraiment pour coder. Donc quand les gens pensaient à l'IA pour le code, c'était un produit complètement différent qu'on imaginait : tab pour autocompléter. Et je pensais que c'était ça, et que c'était l'état des choses. Et puis Ben, qui était mon manager à l'époque, m'a poussé à penser un peu plus grand, et je pense qu'il a vraiment internalisé — parce qu'il était là depuis le début d'Anthropic et avait été dans d'autres labos avant — donc il comprenait vraiment les scaling laws en interne, à quelle vitesse les modèles s'améliorent. Et donc il m'a vraiment poussé fort : ne construis pas pour le modèle d'aujourd'hui, construis pour le modèle dans 6 mois. Et honnêtement, pendant longtemps Claude Code n'était pas un super produit, et même quand il était utilisé en interne je l'utilisais pour peut-être 10% de mon code. Tu l'utilises parfois mais il ne peut juste pas faire la plupart des choses parce que le modèle n'est pas assez capable. Puis à un moment on a sorti Sonnet et Opus 4, je crois que c'était mars de cette année, et le produit a juste marché, et on l'a vu dans les données d'usage, et je l'ai vu dans mon propre code. J'ai commencé à pouvoir l'utiliser pour probablement la moitié de mon code. Et c'était totalement confirmé parce que c'était littéralement 6 mois après le démarrage du projet. C'était ça la timeline. Et à ce point, la plupart de Claude Code est écrit avec Claude Code. C'est genre 80 ou 90%. Si tu regardes les équipes chez Anthropic, il y a des équipes où genre 90% de leur code est écrit avec Claude Code. Pas juste notre équipe. Et si tu regardes l'impact sur la productivité, même si Anthropic a triplé depuis le début de l'année, la productivité par ingénieur mesurée en coût (on en parlait avant) a augmenté de presque 70% par ingénieur grâce à Claude Code. Et donc, en tant que personne produit, je pense généralement une étape en avance, mais dans un labo tu dois penser un peu différemment : tu dois penser une étape en avance, pas deux, mais aussi être très conscient du modèle et du potentiel exponentiel sur lequel on est.

1:12:57 Tu as vu la récente interview de Karpathy ?

1:12:59 Je n'ai pas encore eu la chance de la regarder.

1:13:02 OK. Un truc qu'il a dit dans le podcast, c'était un peu un bémol, parce que le vibe coding, bien qu'il ait beaucoup de résultats miraculeux par ce qu'il peut générer, il y a aussi pas mal de ce qu'il a appelé du « slop » ou des inconvénients. Donc comment penses-tu à ça quand le modèle produit beaucoup de code mais peut-être pas exactement comme tu voudrais, ou le résultat final a des problèmes non évidents ? Le code IA est un outil comme tout autre outil qu'on utilise, et tu dois apprendre à l'utiliser. Karpathy sait évidemment coder. Beaucoup de gens nouveaux à ce genre d'outil tendent à juste lui demander des trucs un peu trop gros, ou ils tiennent une barre différente pour le code du modèle versus le leur. Et donc un truc que je fais pour l'équipe Claude Code, c'est qu'on a exactement la même barre, que le code soit écrit par le modèle ou par un humain. Donc si le code est nul, on ne le merge pas. C'est exactement la même barre, et tu demandes juste au modèle d'améliorer le code. Il y a aussi différentes façons de manier ces outils. Parfois tu veux vibe-coder, et c'est vraiment important pour du code jetable et des prototypes, du code pas dans le chemin critique. Et je fais ça tout le temps, mais ce n'est définitivement pas le truc que tu veux faire tout le temps, parce que parfois tu veux du code maintenable, tu veux être très réfléchi sur chaque ligne. Donc selon le problème, tu veux une approche différente. Et il y a un ensemble d'approches que j'utilise. Parfois je vibe-code des trucs, mais c'est en fait assez rare, surtout pour des prototypes et du code jetable. D'habitude je fais du pair avec un modèle pour écrire du code. Donc d'abord on s'aligne sur un plan — shift+tab dans Claude Code pour entrer en mode plan. D'abord le modèle fait un plan, puis je vois le code, puis je peux lui demander de l'améliorer, de le nettoyer, etc. Mais c'est un processus très impliqué, je fais du pair avec le modèle, on travaille ensemble pour écrire ce code. Et puis parfois j'écris encore le code à la main. Il y a des parties de notre boucle de requête principale où j'ai des opinions très fortes sur les noms de paramètres ou sur quelle ligne particulière du code est tel code, et pour ça je l'écris encore à la main. Mais le truc, c'est que les modèles, globalement, ne sont encore pas géniaux en code. Il y a encore tellement de marge d'amélioration, et c'est le pire que ça ne sera jamais. Mais c'est juste dingue de penser à où était l'état du code IA il y a un an, genre type-ahead, et c'est un monde complètement différent. Et tu penses à où ça se dirige et ce qui est sur le point d'arriver et à quoi ça ressemble sur les prochains mois et années. Et ouais, pour moi ce qui me garde vraiment excité, c'est juste d'avoir le contexte sur cette trajectoire sur laquelle on est. Quand les gens entendent Claude Code, ils pensent au code, mais il y a beaucoup de cas d'usage en dehors du génie logiciel, comme requêter des données pour un data scientist. Tes réflexions sur Claude Code pour tout ? C'était le truc le plus dingue quand je suis arrivé. Je me souviens d'entrer dans le bureau il y a peut-être 6 mois, et notre data scientist Brandon avait Claude Code sur son ordinateur. Il est assis à côté de nous et je dis « mec, qu'est-ce que tu fais, tu l'essaies ? ». Et il dit « non non, c'est genre il fait mon travail ». Et je dis « quoi ? ». Donc il avait trouvé comment utiliser un terminal, installer Node.js, puis installer Claude Code, et ça écrivait un tas de SQL et faisait de l'analyse pour lui. Et maintenant quand je passe devant les data scientists assis à côté de nous, chaque personne a un tas de Claude Code ouverts en même temps. Ce n'est plus juste un. Et ils font toutes sortes de trucs. Ils écrivent du SQL, crunchent des données, écrivent des pipelines dbt, écrivent du code. Donc il y a toutes ces applications en dehors du code, et c'est tellement cool de voir comment les gens utilisent ça pour toutes sortes de trucs, et il y a même des utilisateurs totalement non techniques : la moitié de notre équipe commerciale chez Anthropic utilise Claude Code pour son travail, ils peuvent le connecter à Salesforce et à différentes sources de données et faire leur travail comme ça. C'est tellement cool de voir ça, ce n'est pas comme ça qu'on l'a conçu, ce n'était pas l'intention. Quand j'entends Claude Code, je pense aussi à Codex, un des plus gros concurrents. Quelles sont tes réflexions sur la concurrence avec Codex et OpenAI ? Qu'est-ce que Claude Code fait mieux ? Et je suis aussi curieux de la fidélité (stickiness) de ces produits IA : qu'est-ce qui garde les gens dans Claude Code versus Codex par exemple ?

1:17:46 Tu sais, je ne suis pas totalement sûr. Personnellement, je n'utilise pas vraiment les autres produits. [rires]

1:17:51 OK. OK. Pour moi, le truc que je dis à l'équipe, c'est qu'il est si facile de se laisser distraire en regardant les concurrents. Et c'est quelque chose que j'ai vu : les grandes boîtes tombent souvent dans ce mode d'échec parce qu'il y a tant de concurrents et qu'il est si facile de voir le truc que tu pourrais construire juste en le copiant. C'est un peu plus dur de trouver des idées nouvelles et des trucs qui résolvent mieux le besoin de l'utilisateur. Donc le truc que j'essaie très fort de faire, et que je pousse notre équipe à faire, c'est de ne pas se laisser distraire par tous ces autres produits — il y en aura toujours beaucoup, et plus il y en a, plus c'est un signe de succès pour nous — et le truc sur lequel on reste laser-focus, c'est résoudre nos problèmes, les problèmes des chercheurs d'Anthropic et les problèmes de nos utilisateurs. Pour finir la conversation, je veux juste poser quelques réflexions de carrière. Un truc dont j'étais curieux : tu n'avais pas de diplôme de CS ou d'informatique, et tu es devenu un si fort ingénieur logiciel. Y a-t-il une partie de ta carrière où ça aurait pu te freiner, ou penses-tu que ce n'est pas nécessaire ou pertinent ?

1:19:05 Ouais, j'ai étudié l'économie et j'ai en fait décroché pour les startups. Pour moi, tout ce que tu fais, tu l'apprends sur le tas, et je pense que la programmation est une compétence tellement pratique. Je n'imagine pas — les genres de choses que tu apprends à l'école, si tu es dans un cours de structures de données mais que tu n'as jamais construit de produit, en quoi est-ce pertinent ? Donc je ne sais pas, ma recommandation serait : apprends le code de façon pratique. C'est une compétence très pratique. Et si tu veux ensuite revenir apprendre la théorie, fais-le. Mais personnellement je n'ai jamais senti que ça m'avait freiné du tout.

1:19:44 Et les conseils de productivité ? J'ai vu que tu disais travailler à peu près de 9h à 18h chaque jour et taper seulement avec deux doigts [rires], mais ta production est ridicule. Tu as tous ces projets parallèles et bien sûr ton truc principal n'est pas une blague. Quels sont tes meilleurs conseils de productivité, ou comment maintiens-tu ça ? Ouais, mes conseils de nos jours sont très différents de ce que j'aurais dit il y a quelques années. De nos jours le conseil, c'est juste : apprends à utiliser Claude Code et apprends à faire tourner un tas de Claude Code pour faire des trucs. On a lancé les plugins il y a quelques semaines, et Daisy, l'ingénieure qui l'a construit, a fait setup à ses Claude un board Asana, créer des tâches, puis elle a eu un essaim de genre 20 Claude qui ont juste construit des plugins le week-end, et elle l'a fait tourner dans un conteneur Docker en mode dangereux et c'était fini après quelques jours. Et c'est le genre de chose qui est le futur de l'ingénierie. Et de nos jours, quand on parle de conseils de productivité, c'est apprendre à utiliser Claude pour automatiser le labeur, et aussi comment utiliser un tas de Claude ensemble pour faire du travail. Donc tu orchestres au lieu d'écrire du code manuellement. Il y a des années mes conseils auraient été vraiment différents, bien plus prosaïques, genre bloquer du temps et des trucs comme ça.

1:21:03 Ouais, c'est intéressant avec Claude Code. Je me demande ce que ça fait au fameux maker schedule versus manager schedule. On dirait que ce que tu viens de dire, c'est que les ingénieurs logiciels deviennent plus un style de travail de manager, où tu as une flotte de ces Claude Code et tu n'as pas besoin de focus profond pour avancer, tu as besoin de context switching à travers genre 20 trucs différents. Donc tu n'as plus de gros blocs de focus pour coder, ou quelles sont tes réflexions ? Pas autant. J'ai tendance à coder le week-end aussi. J'adore le temps calme. Mais sinon je commence chaque matin en ouvrant Claude Code et l'app mobile. Il y a un onglet code dans Claude maintenant, qu'on vient de lancer cette semaine mais qu'on utilise depuis un moment. Donc chaque matin je me réveille et je lance quelques agents juste pour démarrer mon code de la journée. Et c'est dingue parce que si tu m'avais demandé il y a 6 mois si c'est comme ça que je coderais, j'aurais dit « non, t'es fou ? Comment peux-tu coder comme ça ? ». Mais ça marche. C'est là et ça marche, et c'est comme ça que j'écris beaucoup de mon code maintenant. Je lance quelques agents puis, quand j'arrive à un ordinateur, je checke le statut. Parfois je merge juste si le code a l'air bon. Parfois je le pull en local et je téléporte pour éditer un peu. Et je pense que tu vas parler à Fiona plus tard, et d'après ce qu'elle m'a dit elle n'avait pas codé depuis genre une décennie mais elle écrit du code plusieurs fois par semaine maintenant parce qu'en tant que manager, même avec son emploi du temps dingue, elle peut utiliser l'app mobile et le web, ouvrir un terminal pour écrire du code pour elle. Donc c'est juste dingue qu'on vive cette transition où le truc qu'on fait et le truc sur lequel j'ai grandi, ça change totalement, et c'est tellement cool. Ça devient accessible à tout le monde.

1:23:00 Et dernière question : sachant tout ce que tu sais maintenant dans ta carrière, si tu pouvais revenir à toi-même quand tu venais d'entrer dans l'industrie et te donner un conseil, que dirais-tu ? Utilise juste ton bon sens. [rires] Je pense qu'il y a beaucoup de trucs, surtout dans les grandes boîtes, qui t'éloignent du bon sens. Il y a beaucoup d'inertie organisationnelle : les choses sont comme ça parce qu'elles ont été comme ça. Il y a beaucoup d'incitations mal alignées. Il y a aussi beaucoup de bonnes choses, mais il y a aussi ces trucs. Donc c'est vraiment important d'utiliser le bon sens. Et au début de ma carrière je lançais un tas de startups et bossais dans beaucoup de startups, et là aussi c'est la même chose : utilise le bon sens pour comprendre ce que le marché veut et ce que les utilisateurs veulent, pour le construire. Donc ouais, fais-toi confiance et développe ton bon sens.

1:23:53 Génial. Merci infiniment, Boris, pour ton temps. On apprécie vraiment.

1:23:57 Ouais. Merci. Merci d'avoir écouté le podcast. Je ne vends rien et ne fais pas de sponsoring, mais si tu veux aider le podcast, tu peux soutenir en interagissant avec le contenu sur YouTube ou Spotify. Si tu veux laisser un avis, ce serait super utile. Et s'il y a des invités que tu veux qu'on reçoive, fais-le-moi savoir. J'ai l'impression que sourcer des IC très seniors, il n'y a pas de liste bien étudiée sur Google que je peux juste rechercher. Donc s'il y a quelqu'un dans ton org ou ta boîte que tu admires vraiment et dont tu veux entendre l'histoire de carrière, fais-le-moi savoir.

93 KiB Raw Blame History

Boris Cherny (créateur de Claude Code) sur ce qui a fait grandir sa carrière — Ryan Peterman

Détails de la vidéo

Transcript

Sources

93 KiB

Raw Blame History