Le fondateur d'Instagram, Mike Krieger, sur Fable 5 et l'avenir du développement logiciel piloté par l'IA

Invité : Mike Krieger, fondateur d'Instagram

Animateur : Dan Shipper

Source du podcast : Every

Mike Krieger laisse Fable 5 coder pendant qu'il dort

Date de diffusion : 11 juin 2026

Mike Krieger, ancien cofondateur d'Instagram, a créé l'une des applications grand public les plus influentes de la dernière décennie. Aujourd'hui, il se trouve à la pointe du développement de produits « AI-native » en tant que dirigeant d'Anthropic Labs, guidant son équipe pour explorer une question fondamentale : quand les modèles d'IA les plus avancés au monde sont remis aux vrais développeurs, jusqu'où peut-on pousser les limites de la technologie ?

Cinq mois avant la sortie officielle de Fable, lorsqu’il a obtenu pour la première fois un accès interne à ce modèle, l’impact et le sentiment de désorientation l’ont profondément marqué. « Bon, je me sens à nouveau un véritable débutant », a-t-il plaisanté auprès de son équipe à l’époque. Il s’est soudainement rendu compte que toutes les règles empiriques qu’il avait accumulées au cours des dernières décennies en matière d’optimisation de la productivité, de stratégie de développement et même de gestion du temps étaient soudainement obsolètes. La vitesse d’évolution du modèle avait totalement dépassé son flux de travail antérieur.

Dans cet épisode, l'hôte mène une discussion approfondie avec Mike Krieger pour explorer ce que cela fait de collaborer avec des modèles révolutionnaires comme Fable dans le développement logiciel. Dans ce nouvel état normal de coexistence homme-machine, quels nouveaux rythmes de recherche et développement, quels défis exigeants et quelles possibilités ultimes pleines d'imagination émergent-ils ?

Comment Fable a complètement transformé le flux de travail de Mike

Quand utiliser Sonnet, quand utiliser Fable ?

L'architecture Agent-native issue de Fable 5

Les coûts de construction ont effondré

La génie logiciel est-il mort ?

Mécanisme de vérification et prix

Workflow dynamique

Hôte Dan Shipper : L'invité d'aujourd'hui est Mike Krieger, directeur d'Anthropic Labs et cofondateur d'Instagram. Mike, je voudrais particulièrement t'entendre parler de ton expérience réelle après une utilisation intensive de ce modèle. Lorsqu'un modèle aussi puissant est lancé, il est très utile d'avoir quelqu'un qui l'utilise quotidiennement et qui dit : « Il est incroyablement fort à ces endroits, il a réellement transformé mon flux de travail ici, mais là, ce n'est pas si impressionnant » — cela aide vraiment les gens à comprendre comment intégrer technologiquement cette innovation dans leur vie quotidienne.

Mike Krieger :

C'est vrai. Cette expérience en elle-même est très intéressante. Pendant les mois précédant la sortie officielle de Fable, nous utilisions déjà internement plusieurs modèles de niveau Mythos. J'étais alors impatient de voir ce que les développeurs externes pourraient créer avec eux, mais comme vous l'avez dit, la véritable élévation cognitive vient d'une utilisation intensive et continue sur plusieurs semaines, et non d'une simple découverte le premier jour.

Nous avons déjà vécu cette réévaluation cognitive avec nos modèles précédents. À la fin décembre dernier et au début janvier, alors que tout le monde utilisait massivement Opus 4.5 et 4.6, avec le temps passé à les utiliser, les gens ont soudainement réalisé : « Je ne l’avais pas encore poussé assez loin. Je dois aller plus loin, et repenser les limites réelles de cette génération de modèles. »

L'hôte Dan Shipper : Notre équipe Every a déjà certains collègues qui l'utilisent. Certains ont réagi : « Je sens que je dois acquérir un tout nouvel arbre de compétences pour maîtriser ce modèle », en particulier les collègues non techniques, orientés vers le travail intellectuel, qui se sentent presque dépassés ; tandis que ceux qui travaillent sur l'orchestration d'agents s'exclament : « Il y a tellement de nouvelles choses à apprendre. »

Mike Krieger : Vous avez mentionné le « changement de flux de travail » — c’est exactement le point central : il ne s’agit pas seulement des étapes opérationnelles, mais aussi d’un changement de mentalité. Curieusement, l’apparition de ce modèle coïncide avec une période de transition dans mon travail : je venais de passer du poste de CPO (Chief Product Officer) à Labs, en revenant à un mode développeur. Environ un mois et demi à deux mois après ce changement, ce type de modèle a été pour la première fois mis en œuvre avec succès en interne. J’étais assis devant mon ordinateur et je me suis dit : « Bon, je suis de nouveau un débutant. » Car j’ai réalisé que mes anciennes habitudes d’écriture de prompts, voire ma façon de décomposer les tâches, étaient complètement obsolètes face à ce modèle.

Votre perception du cadre temporel et votre mode d'interaction doivent évoluer. Avant, je pourrais dire : « J'ai une idée de fonctionnalité, commençons par la première étape — » Maintenant, ce n'est absolument plus la bonne approche. La bonne méthode aujourd'hui consiste à transmettre une intention plus globale et plus complète, puis à laisser complètement l'IA agir. Je me souviens qu'en mars et avril, ses capacités étaient déjà impressionnantes — elle non seulement livrait des résultats époustouflants en une seule fois, mais, ce qui est encore plus effrayant, elle comprenait la trajectoire d'évolution future de cette fonctionnalité ainsi que le contexte global du projet.

Et cette évolution ne s'est absolument pas arrêtée. Ce matin, j'ai discuté du travail avec quelqu'un — pendant le vol, j'ai réalisé que « la grande majorité de mon travail, je peux en fait le faire à distance ». Je ne m'inquiète même plus de savoir si la connexion Wi-Fi va se couper, car tant que je lui donne le bon contexte et les bonnes instructions avant la coupure (par exemple, une commande en boucle), il peut suivre la tâche jusqu'au bout tout seul.

Au cours des deux derniers mois, j’ai souvent vécu ces moments marquants : dire bonsoir à Claude avant de me coucher, lui confier une tâche complexe, et me réveiller le lendemain pour découvrir qu’elle avait déjà tout accompli — généralement, elle avait terminé l’essentiel à 2 heures du matin, et les quatre heures suivantes étaient consacrées à affiner les détails.

Ce qui m’a le plus impressionné, c’est sa capacité à s’auto-fermer en boucle. Par exemple, il pense ainsi : « Mike m’a demandé d’exécuter une tâche complexe ce soir. Mais je suis bloqué parce que le serveur distant est hors ligne. D’accord, je vais d’abord créer moi-même un mock de backend pour le remplacer, noter ce problème dans la documentation, exécuter et enregistrer l’ensemble du processus, puis le corriger demain une fois le service rétabli. » Pour moi, pouvoir déléguer une tâche de ce niveau et faire entièrement confiance à son résultat final est une expérience extrêmement bouleversante.

Bien sûr, vous devrez ensuite vérifier les résultats — cela implique un mécanisme de validation complet, dont nous pourrons discuter plus tard, car c'est un maillon essentiel de la boucle fermée. Mais cela m'oblige effectivement à repenser : face à un tel modèle, qu'est-ce que signifie vraiment « efficace » ? Par le passé, nous comparions toujours ces modèles à des « assistants » ou des « compagnons », mais maintenant, il ressemble davantage à un coéquipier sérieux, capable de prendre la responsabilité et de livrer un volume important de tâches cruciales.

Animateur Dan Shipper : Alors, à quoi ressemble exactement ton flux de travail quotidien ? J'ai remarqué un phénomène : si tu lui donnes une tâche ambitieuse, lui fournis un long discours, puis tu la laisses s'exécuter pendant plusieurs heures ou même toute la nuit, c'est à ce moment-là qu'elle performe le mieux. Mais face à des tâches petites et quotidiennes, elle semble trop lente et trop coûteuse, ce qui décourage son utilisation. Comment équilibres-tu cela dans la pratique ? Où se situe-t-elle dans ta pile technologique ?

Mike Krieger :

Je l'utilise maintenant davantage pour la planification architecturale initiale et l'alignement des solutions. C'est un changement intéressant, et c'est toujours un défi majeur que tous les modèles doivent relever.

À cet égard, je suis reconnaissant d’avoir travaillé sur Instagram à l’époque — depuis la version minimale construite sur un serveur à Los Angeles, jusqu’à la gestion de volumes massifs de requêtes simultanées et à l’échelle, puis jusqu’à l’intégration finale dans l’infrastructure de Facebook. Ce parcours vous développe une intuition : « À quel stade du projet, quel niveau d’abstraction et de complexité architecturale doit-on utiliser ? »

Je continuerai donc à avoir des échanges fréquents avec Fable. Parfois, il propose une solution qui semble parfaite, et je le relance : « Je prévois effectivement de mettre cela en ligne prochainement — mais nous devons prendre en compte la capacité au-delà d’un seul serveur. » Ce type d’interaction bidirectionnelle est essentiel. Toutefois, lors de la planification architecturale, je lui demande généralement de générer directement une page HTML pour visualiser nos discussions, afin de la partager avec mon équipe. Même un fichier Markdown suffirait, mais je préfère les versions avec des graphiques.

Cela crée un paradigme intéressant : réfléchissez et planifiez ensemble les choses, puis produisez un document pour aligner l’équipe. Puisque la vitesse de construction des prototypes est désormais considérablement accélérée, il est encore plus essentiel d’établir un consensus et un alignement préalables — même si vous prévoyez de commencer par « avancer rapidement » avec un démonstrateur, puis d’en déduire rétroactivement une architecture système plus rigoureuse, la communication initiale reste cruciale. Et c’est précisément là que la réflexion et la collaboration humaines restent profondément intégrées à l’ensemble du processus.

Au stade de l'exécution, qu'il s'agisse d'utiliser la nuit ou de longues périodes de la journée pour déléguer différents modules de tâches, cela signifie que je maintiens simultanément bien plus de sessions concurrentes qu'auparavant. J'aime parfois laisser une session Claude Code ouverte sur le long terme, afin qu'elle fork (prenne en charge) les tâches en arrière-plan via des sous-agents, permettant ainsi au thread principal de répondre immédiatement à mes nouvelles instructions ; parfois, j'ouvre simplement cinq ou six onglets simultanément dans mon navigateur, afin qu'ils gèrent chacun des tâches complexes à long terme.

Ce modèle de fonctionnement, qui repose sur une vision à long terme et un esprit du type « Ne vous inquiétez pas, laissez-moi m’en occuper, cela prendra un peu de temps », offre réellement de grandes possibilités. Nous réfléchissons actuellement au niveau du produit à la meilleure façon de soutenir cette expérience — vous souhaitez certainement concilier les états « réponse immédiate » et « exécution à long terme », dont l’interaction est particulièrement intéressante. Mon préférence personnelle est de garder au moins une fenêtre Claude avec un contexte élevé et une réponse extrêmement rapide, offrant l’intuition que « je suis toujours prêt, un seul mot de vous et je démarre immédiatement ou lance une sous-tâche ».

L'hôte Dan Shipper : Et si, par exemple, vous marchez dans la rue et que vous avez soudainement une question — sortiriez-vous Fable ? Cela ne ressemble-t-il pas un peu à « utiliser un lance-roquettes pour tuer un moustique » ? Ou bien basculez-vous fréquemment entre différents modèles ?

Mike Krieger :

Récemment, j'utilisais vraiment Fable pour tout, et l'expérience était exactement comme vous l'avez décrite — vous fixez l'écran en le regardant s'efforcer désespérément de réfléchir.

Jusqu’à la semaine dernière, je voulais vérifier une question simple qui me faisait même un peu honte : concernant les Finales de la NBA. À ce moment-là, j’ai basculé sur la version mobile de Sonnet sur mon téléphone et j’ai immédiatement réalisé : « Ah oui ! Je utilisais toujours Sonnet pour ce genre de questions rapides. » C’était une expérience complètement différente. Ce n’était même pas une question de nombre de tokens générés par seconde, mais plutôt de la quantité de capacité cognitive nécessaire pour réfléchir à la question. Parfois, une réponse simple n’a tout simplement pas besoin de tant de réflexion en profondeur.

Pour notre équipe produit, c’est également une question très intéressante. Globalement, vous ne voulez certainement pas que les utilisateurs se torturent chaque jour sur le choix du modèle à utiliser en interface. Idéalement, à long terme, nous pourrions regrouper ces modèles dans quelques scénarios extrêmement intuitifs et prêts à l’emploi ; ou bien directement segmenter selon l’interface elle-même — car, honnêtement, la plupart du temps, quand je navigue dans une app iOS, ce n’est pas pour accomplir des tâches exigeant l’intervention de Fable. Ainsi, une fixation transparente du modèle au niveau de l’interface pourrait être une piste à explorer. Nous devons désormais approfondir ce que cela signifie concrètement au niveau produit. Mais ce sentiment subtil — « ce problème ne mérite pas Fable, je devrais plutôt appeler Sonnet pour y répondre » —, je l’ai récemment ressenti profondément.

Vous avez raison : pour les tâches interactives à haute fréquence et à granularité fine, Fable a tendance à s’engager automatiquement dans une réflexion plus approfondie. En réalité, Fable est le premier modèle avec lequel j’ai eu à ajuster activement le « niveau d’effort » (Reasoning Effort) — parfois, je me retrouve assis à penser : « Je veux simplement modifier le style de l’interface utilisateur, je vais régler son effort à ‘moyen’ pour voir l’effet. » Avec Opus, je ne modifiais presque jamais ce paramètre, car la plage d’adaptabilité du modèle n’était pas aussi large. Mais la gamme de Fable peut vraiment s’étendre considérablement.

L'hôte Dan Shipper : Peux-tu nous montrer ce que tu as fait avec ?

Mike Krieger :

Lors de ce lancement de nouveau modèle, nous avons fait une chose — encourager toute l'équipe à l'utiliser sur leurs comptes personnels, en particulier pendant le week-end. C'était assez amusant, car Anthropic dispose de nombreux outils de productivité personnalisés, donc il était parfois agréable de faire un pas en arrière et de revenir à l'état le plus pur : « Je n'utilise que Claude Code pur pour me faire de petites choses amusantes pendant le week-end. » C'était génial.

Animateur Dan Shipper : Utilises-tu l'application mobile ou l'application de bureau ?

Mike Krieger :

Bonne question. Je passe encore la majeure partie de mon temps dans le terminal. Mais ce qui est amusant, c’est que ma femme — qui n’est pas ingénieure professionnelle, mais plutôt spécialisée en conception UX (expérience utilisateur) et en gestion de produit — est devenue complètement fan de Claude Code grâce à l’application de bureau. Je pense que l’application de bureau lui a permis d’ignorer beaucoup de concepts abstraits complexes en coulisses. Toutefois, lors de la réalisation de ce projet, j’ai utilisé Ghostty et le terminal.

Je voulais dès le départ un « suivi médiatique parfait » — je joue souvent à des jeux, regarde des séries, et reçois des recommandations de mes amis ; j’avais besoin d’un outil entièrement adapté à mes habitudes de rangement. Mes deux critères principaux étaient : premièrement, ajouter des éléments devait être extrêmement simple — il suffisait de dire ou d’écrire une phrase à Claude, qui recherchait automatiquement sur le web, complétait les informations et les classait ; deuxièmement, il devait envoyer des notifications actives, par exemple en trouvant automatiquement une nouvelle saison ou une suite d’un jeu.

La plupart de l'interface utilisateur a été réalisée en une seule fois par Fable, ce qui est déjà impressionnant. Mais une piste que j'ai poursuivie sans relâche dans les Labs cette année, c'est : comment rapprocher davantage l'équipe logicielle — ici, Claude — du logiciel lui-même ?

C'était un samedi matin, et j'avais en fait toute la fin de semaine remplie d'activités avec les enfants, donc mon développement était entièrement « discontinu » : emmener les enfants faire de la randonnée, rentrer, écrire deux lignes, puis repartir. Parfois, pendant la randonnée, je ne pouvais pas m'empêcher de jeter un coup d'œil à l'avancement — même si je ne devrais pas regarder mon téléphone quand je suis avec les enfants, surveiller à distance sur mon téléphone jusqu'où en était sa tâche, c'était vraiment agréable.

J’ai eu une idée : et si je faisais une expérience audacieuse en permettant au logiciel de se modifier lui-même depuis son propre fonctionnement ?

J'ai créé à la fois une version mobile et une version web. J'avais déjà développé une interface de chat interactive où je peux simplement dire à Claude : « Aide-moi à ajouter cette URL à la liste de suivi ». Mais je souhaite que tous les logiciels puissent évoluer pour intégrer cette fonctionnalité — je ne veux plus jamais avoir à naviguer à travers des menus complexes pour trouver une fonction.

Dan, à de nombreux niveaux, j'essaie en réalité de pousser l'architecture native des agents à ses limites les plus extrêmes.

L'architecture dite « agent-native » a pour première étape que chaque composant et donnée essentielle du produit soit entièrement ouvert à l'agent et dispose d'une interface d'appel d'outil correspondante. Cela devient rapidement la ligne de base de l'industrie logicielle — bien que, de façon triste, la majorité des logiciels actuellement sur le marché ne parviennent même pas à atteindre ce niveau.

J'ai un excellent exemple positif : récemment, quelqu'un m'a recommandé une série brésilienne exceptionnelle sur la fuite de matières radioactives à Goiânia. Le titre est extrêmement long et difficile à retenir ; j'ai simplement mentionné vaguement le sujet au système, et Claude m'a immédiatement trouvé la série et l'a classée avec précision. Cette expérience est bien supérieure à une recherche aléatoire sur Google que j'aurais effectuée moi-même.

Mais la prochaine étape qui me passionne vraiment est : dans un contexte mobile, modifier directement le logiciel depuis son propre interface — à quoi cela pourrait-il aboutir ?

Ce que j'ai fait — plus précisément, ce que j'ai demandé à Claude de faire — est une interaction telle que : en appuyant longuement sur le bouton de discussion dans l'application, notre agent géré se déclenche pour recevoir des instructions de modification de code, puis affiche directement les résultats grâce à la fonctionnalité de prévisualisation en temps réel de Vercel. L'ensemble du module a presque fonctionné du premier coup, c'était très cool ; par la suite, j'ai ajouté progressivement quelques nouvelles idées. Si vous êtes un utilisateur avancé, vous pouvez également consulter la vue Diff (différences de code) ou entrer dans l'historique des conversations de l'agent géré pour voir exactement ce qu'il a modifié en coulisses — mais je ne le fais presque jamais, car pour un projet personnel, je m'en fiche complètement de sa maintenabilité à long terme (rires).

C’est absolument addictif. J’étais en train de jouer avec mes enfants quand j’ai remarqué que « le bouton flottant est trop bas sur iOS » ; j’ai simplement dit cela à l’application, et elle s’est automatiquement connectée à l’arrière-plan pour corriger le code. En combinant avec l’écosystème de développement Expo, elle a même effectué un hot reload directement sur mon téléphone — l’expérience à ce moment-là était tout simplement incroyable.

Faut-il que cela atteigne un niveau de production capable de supporter un million d’utilisateurs simultanés ? Absolument pas. Mais il me procure un sentiment d’entière maîtrise : vous n’avez pas à arrêter le projet au moment où le week-end se termine et où vous fermez votre ordinateur — vous pouvez l’utiliser intensivement tout en le modifiant en temps réel au fur et à mesure. Cette boucle en temps réel, de bout en bout, vous permet d’itérer indéfiniment.

Cela ne représente pas seulement une excellente démonstration des compétences techniques robustes de Fable, mais aussi une synthèse de la question ultime que nous avons toujours discutée : comment intégrer Claude profondément dans les logiciels ? Il ne devrait pas se limiter au niveau de l’« utilisation » ; il doit être intégré en profondeur dans la moelle même de la construction des logiciels.

L’animateur Dan Shipper : Je veux particulièrement attirer votre attention sur un point : des outils comme celui-ci, vous auriez pu les créer il y a dix ou vingt ans, mais certainement pas de cette manière. Le coût de développement logiciel a connu une chute vertigineuse. Pensez à l’époque où Instagram a été créé : combien de ressources fallait-il investir pour mener un projet à un niveau de finition similaire ? Et aujourd’hui, combien en faut-il ? Aidez-nous à quantifier ce changement d’époque.

Mike Krieger :

Je me souviens souvent de cette époque. Au début d’Instagram, je me considérais comme un ingénieur extrêmement efficace — passionné par le développement mobile et doté d’une forte intuition pour la direction produit. Mais même ainsi, passer d’une idée dans ma tête à sa réalisation complète impliquait au moins quatre à cinq nuits blanches intenses. Travailler jusqu’au petit matin était mon quotidien : rester éveillé jusqu’à 4 heures du matin, puis dormir jusqu’à midi — un rythme de vie totalement incompatible avec la vie familiale, mais c’était bien mon « mode constructeur » à l’époque.

Revoyez la version V1 d’Instagram — elle offrait effectivement plus de fonctionnalités que mon traceur médiatique que j’ai fait ce week-end, mais il n’y avait pas de différence fondamentale d’échelle. Pour créer cette V1 à l’époque, Kevin et moi avions travaillé sans relâche pendant cinq nuits consécutives : j’ai pris en charge seul tout le frontend et le backend, tandis que Kevin s’est occupé des filtres d’images initiaux. Et tout cela reposait sur le fait que nous avions tous deux plusieurs années d’expérience en développement iOS.

Sans parler de la frustration liée au rythme de développement à l’époque. Après le lancement du produit, qui a connu un succès immédiat, nous avions des centaines d’idées nouvelles en tête, mais toute notre énergie était consacrée à garantir que les serveurs ne s’effondrent pas sous le poids du trafic massif, ou à peine à trouver du temps pour ajouter une petite fonctionnalité incrémentale. Prenons la fonctionnalité Hashtag : il m’a fallu une semaine entière pour simplement l’implémenter, tandis que vous aviez encore dix mille autres idées bloquées en attente de planification.

Ainsi, il ne s'agit pas seulement du temps compressé — bien que le temps de construction ait effectivement été réduit à un niveau incroyable — mais surtout de l'autre côté de la médaille : vous pouvez désormais itérer instantanément sur ce que vous possédez déjà, de manière extrêmement fluide et dynamique.

De plus, cet élan a déjà débordé bien au-delà du cercle des ingénieurs logiciels et fondateurs comme moi. Autrefois, si vous aviez une excellente idée commerciale mais ne saviez pas coder, vos seules options étaient soit de sous-traiter — ce qui entraînait une distorsion informationnelle extrême et des livrables médiocres —, soit de chercher frénétiquement des financements. Mais aujourd'hui, le fossé entre l'« intention » et la « mise en œuvre » a été comblé pour les personnes non techniques.

Il y a quelques jours, j'ai reçu un message d'une collègue interne. Nous lui avions configuré un outil interne pour connecter les capacités de Fable à l'accès à certains de nos MCP (Model Context Protocol). Elle travaille dans le recrutement (RH) et elle m'a dit avec enthousiasme : « C'est la première fois de ma vie que je sens qu'il n'y a aucune distance entre ce que je pense dans ma tête et ce qui existe dans le monde réel. Je peux directement le créer. »

Ce moment-là a été pour elle un choc absolument marquant. Il y a cinq ou six ans, si elle voulait un outil métier dédié, elle devait soit assembler péniblement divers logiciels existants, soit supplier les ingénieurs de l'équipe outils internes — dont la file d'attente Jira comportait probablement 50 demandes d'une priorité plus élevée. Mais aujourd'hui ? Elle s'amuse à explorer et à conquérir le monde du code.

C’est aussi ce que je trouve le plus prometteur pour l’avenir : la créativité humaine est infinie, et ce que nous faisons aujourd’hui de plus remarquable, c’est élargir sans limite les frontières de ceux qui ont la capacité de transformer leurs idées en réalité.

L'hôte Dan Shipper : Je suis entièrement d'accord avec vous. Mais je suppose que beaucoup d'entre eux se posent maintenant la question ultime : après tout ce que vous venez de décrire, la profession d'ingénieur logiciel est-elle définitivement terminée ?

Mike Krieger :

On peut dire que le contenu du génie logiciel a complètement changé. Il traverse une transformation radicale.

Si, à l'époque où vous faisiez de l'Instagram, vous m'aviez demandé : « Qu'est-ce que l'ingénierie logicielle ? », je vous aurais probablement répondu : comprendre en profondeur les problèmes de conception complexes, construire une architecture système solide, puis passer des heures et des heures dans TextMate ou Xcode. Se battre avec les détails sous-jacents de Django ORM, puis déployer et passer des jours à corriger des bugs. La plupart des étapes de ce processus ont été bouleversées et s'accélèrent vers les frontières du management produit. Aujourd'hui, la ligne de démarcation entre les produits et les ingénieurs est devenue extrêmement floue. Cela se manifeste très clairement au sein de notre propre équipe de développement.

Mais si vous sortez de la définition trop rigide de « génie logiciel » pour examiner la « production logicielle » ou le « développement logiciel » dans un sens plus large — et non pas uniquement la petite partie consistant en la programmation pure — vous constaterez que cette industrie non seulement prospère, mais occupe également une position centrale sans précédent.

L'apparition de Fable a véritablement poussé ma confiance dans les modèles d'IA à un nouveau niveau — j'ai commencé à lui laisser gérer des boucles automatisées complètes, voire à concevoir des architectures système raisonnables. Du côté de l'exécution technique, l'IA a parcouru un chemin extrêmement long. Mais « maîtriser l'âme de l'art du logiciel » — par exemple, comprendre réellement quelles douleurs des utilisateurs vous cherchez à soulager, ou si l'expérience de ce que vous créez est suffisamment époustouflante — ces jugements de haut niveau restent des qualités humaines extrêmement pures, impossibles à remplacer par une machine.

Of course, this painful transition is not painless for many people.

Dans ce monde, trop de personnes ont autrefois été profondément fascinées par l’artisanat du « codage entièrement manuel ». J’étais exactement comme ça, autrefois. Ce sentiment de satisfaction inégalable, quand tu bloquais sur un bug pendant trois jours et que tu le résolvais enfin avec élégance. Autrefois, tu rêvais même de code — si tu as vécu cela, tes rêves étaient remplis de logiques que tu tentais désespérément de déchiffrer, et au moment où tu te réveillais, une illumination soudaine te révélait la solution. Cette ère purement artisanale a probablement définitivement disparu.

J'ai récemment discuté avec certains des ingénieurs les plus chevronnés que je connaisse dans l'industrie, et ils m'ont tous exprimé une émotion complexe : d'un côté, une immense tristesse face à la disparition des savoir-faire traditionnels, et de l'autre, une excitation extrême : « Mon Dieu, ma productivité concurrentielle est tout simplement incroyable. »

Animateur Dan Shipper : Puisque cette proposition est valide — que le génie logiciel non seulement vit, mais prospère — comment votre équipe de recherche et développement interne à Anthropic travaille-t-elle concrètement au quotidien ?

Mike Krieger :

Il y a plusieurs indices très clairs ici, et je peux les aborder en combinant le cycle de vie complet du logiciel avec mon quotidien de développement que je vois chaque jour.

Tout d'abord, il existe encore beaucoup de « synchronisation humaine ». Les équipes se réunissent en salle de réunion pour brainstormer sur la prochaine évolution de Cowork, puis décomposent le plan en domaines de responsabilité pour chaque membre. Cette étape reste essentielle, car de nombreux contextes globaux que seuls les humains peuvent saisir échappent actuellement à la perception de Claude — par exemple, l'intention commerciale réelle de ce produit, les lignes de développement en cours, ainsi que les informations sur d'autres produits qui vont être mis hors ligne ou intégrés de manière subtile.

Bien que notre équipe ait doté chaque membre de plusieurs tours Claude, en matière de gestion, chaque personne porte toujours le titre de DRI (Directly Responsible Individual, responsable direct), chargée de la prise en charge d’un module spécifique du produit. Je pense que ce mécanisme ne disparaîtra pas à court terme, car il existe une fracture fondamentale entre la vision globale visant à « favoriser la collaboration distribuée et l’effort collectif pour affiner le produit » et l’exécution microscopique consistant à « comment faire fonctionner cette tâche concrète avec Claude aujourd’hui ». Même si nous promouvons activement un système de réunions minimaliste, ces réunions préalables de cerveau collectif et d’alignement restent indispensables.

Ensuite, il y a une grande quantité de « commandes asynchrones ». Beaucoup de nos ingénieurs ont développé leur propre tableau de bord personnalisé pour surveiller ce que font leurs armées de Claude : « À quel stade en est mon Claude Code ? », « Qu'est-ce qui est bloqué en file d'attente et attend mon approbation ? », « Quelles sont les demandes d'intégration qui nécessitent mon intervention, car elles ont été rejetées par un collègue ou par une revue de code d'un grand modèle ? »

Aujourd'hui, une grande partie de l'effort des ingénieurs est consacrée à la maintenance de ce type de travail. Certains outils de collaboration que nous sommes en train de standardiser, mais la plupart conservent encore une forte touche personnelle de geek — tout comme les programmeurs d'autrefois aimaient personnaliser leurs environnements de bureau, ils personnalisent maintenant leurs flux de travail de grands modèles.

En outre, il s'agit de comprendre le fonctionnement réel du code en production. C'est un autre domaine de pointe que les grands modèles s'efforcent activement de maîtriser. Fable a déjà accompli des progrès significatifs dans ce domaine, mais il reste encore un long chemin à parcourir : par exemple, comprendre en profondeur ce qui se passe réellement après le déploiement du code. Les systèmes peuvent planter ou présenter diverses pannes imprévisibles et étranges — honnêtement, pendant les années 2012 à 2016 à Instagram, j'ai passé la majeure partie de mon énergie à gérer ces incidents en production et à mettre à l'échelle l'architecture. Lors de la gestion d'incidents en production, le rôle des ingénieurs seniors reste irremplaçable : vous devez compter sur des années d'expérience en réponse aux incidents pour rester parfaitement calme, collecter intégralement les données de journalisation, mettre en œuvre des mesures d'urgence pour contenir les dégâts, puis analyser en profondeur les solutions durables et fondamentales.

Le dernier point que je souhaite souligner est que le rôle du « prototype technique » a complètement changé aujourd'hui.

Vous devez définir avec une extrême clarté si ce que vous avez entre les mains est une démonstration ou un code de production prêt à être mis en ligne. Autrefois, à Silicon Valley, on disait couramment : « Le code gagne les débats » (Code wins arguments) — personnellement, je n’ai jamais été très sensible à cette phrase, car elle sous-entendait que celui qui sait coder détenait le pouvoir de parole. Mais aujourd’hui, l’évolution des choses est devenue très intéressante à l’inverse : parfois, nous sommes bloqués sur la direction d’un produit, et c’est souvent un PM qui ne code pas qui vient nous dire : « J’ai juste créé moi-même une démo — même si elle est encore brutale sur huit détails — mais regardez, ce chemin fonctionne absolument ! » Et là, une conversation entièrement nouvelle, d’un niveau supérieur, s’ouvre instantanément.

En regardant en arrière, presque toutes nos pratiques de développement actuelles sont méconnaissables par rapport à il y a six mois. Le trait le plus évident est la parallélisation effrayante du développement, ainsi que le besoin absolu de la team d’abstraire hautement ses flux de travail.

Mais une chose n'a jamais changé depuis le début : la "propriété et la responsabilité" des humains envers les produits.

L’animateur Dan Shipper : Fable est aussi très cher. Lorsque je l’ai testé, j’avais l’impression d’être un enfant dans une boutique de bonbons, excité et criant : « Je veux celui-là, celui-là, et celui-là ! » Mais au moment de payer, avant chaque pression sur Entrée, je me demandais : « Est-ce que ça va me coûter 100 dollars ou plus d’un coup ? » Je pense que ce prix élevé crée en réalité une barrière invisible pour déterminer « qui peut l’utiliser » et « à quoi le servir ». Qu’en pensez-vous en termes de rentabilité commerciale ?

Mike Krieger :

Dans le domaine professionnel du génie logiciel, ce compte est en réalité le plus clair. En ce qui concerne le prix, de nombreuses dimensions sont prises en compte en interne. Il est effectivement bien plus cher qu'Opus, mais si l'on évalue la quantité impressionnante de travail livré à chaque fois, il est, sur de nombreux plans commerciaux, presque donné. Bien sûr, chacun a son propre compte économique.

Du point de vue de l’équipe logicielle, si la première phase consiste à faire adopter l’IA aux développeurs par l’entreprise — les modèles étant encore primitifs et les outils insuffisants — et que la deuxième phase consiste à établir des classements pour voir qui l’utilise le plus, ce qui crée des mécanismes d’incitation peu optimaux, alors la troisième phase consiste à identifier qui l’utilise le plus efficacement, à encourager ces personnes à en faire un usage maximal, tout en mettant en place un processus clair pour éviter tout gaspillage.

Le modèle du niveau Fable s'aligne parfaitement sur la logique de la troisième phase. Si vous parvenez à produire continuellement des résultats concrets et à créer une véritable valeur financière dans les opérations en l'utilisant, une boucle de financement positive s'établira naturellement au sein de l'entreprise pour vous soutenir sans limite.

Concernant l'utilisation personnelle, je paie moi-même mes tests avec ma carte bancaire personnelle pour acheter nos propres services. À ce moment-là, on devient effectivement plus économe et plus prudent. Mais ce qui est intéressant, c'est que le traceur médiatique que j'ai développé le week-end ne m'a coûté qu'un peu plus cher que d'habitude — réaliser un projet personnel comme celui-ci ne coûte absolument pas des milliers de dollars.

Ceux qui sont vraiment bloqués par le prix sont en réalité les passionnés de logiciel libre ou les développeurs indépendants (Indie Hackers) qui ne bénéficient pas de la protection des grandes entreprises et qui sont extrêmement sensibles au prix. Mon conseil pour eux : lâchez prise et voyez combien de choses ils peuvent livrer en une seule fois, sans subir de va-et-vient interminables.

Le coût actuel a évolué en un concept multidimensionnel — il ne s'agit plus seulement de calculer le « coût d'une seule question », mais bien le « coût global pour accomplir complètement une tâche ». Ce qui m'a le plus impressionné chez Fable, c'est précisément ce dernier point : il tend toujours à faire les choses correctement du premier coup, sans que je doive rester devant mon ordinateur à lutter pendant huit ou neuf échanges, en criant désespérément : « Non ! Ce n'est pas ce que je voulais dire ! »

L’animateur Dan Shipper : Ce qui m’a le plus impressionné, c’est que lorsque vous lui donnez une tâche macro, en voyant sa réponse, vous vous rendez compte qu’elle a poussé chaque détail, même les plus minuscules, jusqu’au bout — une subtilité écrasante que je n’avais jamais expérimentée sur aucun modèle précédent. Pouvez-vous révéler un peu de ce qui se passe en coulisses lors de l’entraînement ? Qu’est-ce qui a nourri une telle puissance d’analyse ?

Mike Krieger :

À de nombreux niveaux, c’est la continuation d’un énorme travail d’équipe — j’admire profondément notre équipe de pré-entraînement et de RL. Pour moi, l’évolution la plus évidente est une « perception de l’ensemble du système », et non seulement de ce travail en cours.

Je suis souvent impressionné par certaines de ses interventions géniales. Par exemple, dès qu’il termine un morceau de code, il affiche soudainement : « Grand maître, je sais que dans un environnement de production réel, cette configuration pourrait être différente. Ton interrupteur fonctionnel est-il activé ? S’il ne l’est pas, ce que j’ai écrit ne sera pas actif en production. »

Ou bien, il réagit aux commentaires de revue de code — qu'ils viennent d'une personne ou d'un autre Claude — en ne se contentant pas de dire « Oh oui, c'est un problème, je vais le corriger ». Il réfléchit vraiment à accepter ou non un risque selon la fidélité actuelle, ou à contester un autre relecteur — souvent un autre modèle Fable — en disant : « Je comprends votre point de vue, mais je conteste : je pense que c'est incorrect ».

Il est extrêmement important que le modèle possède cette capacité de jugement. Si je devais indiquer le domaine où il a progressé le plus, ce serait qu’il ne répond plus automatiquement par « Oui, oui, j’y vais » — il dit plutôt : « Laissez-moi réfléchir. Je reste en désaccord. » Cette capacité est extrêmement utile.

Avoir un produit comme Claude Code sur le marché est extrêmement précieux, car vous avez quelque chose de concret sur lequel les gens peuvent dire : « Voici où le modèle excelle, voici où il échoue ». Nous plaçons les partenaires d'Every parmi nos sources de retour les plus fiables et prioritaires, car ils soumettent le modèle à des tâches intensives et prolongées sur plusieurs jours, ce qui est essentiel pour réfléchir à ce qu'il faut améliorer pour la prochaine génération.

L’animateur Dan Shipper : Le chat est-il l’interface la plus adaptée pour ce modèle ? Ce n’est pas vraiment une interaction réciproque, mais plutôt une manière de déléguer des tâches à quelqu’un. Comment cela influence-t-il la manière dont vous devriez l’utiliser ou percevoir cette interface ?

Mike Krieger :

Le modèle de base d'envoi et de réception de messages n'est pas entièrement incorrect, mais nous devons évoluer dans certaines directions.

Premièrement : votre ordinateur portable est-il le bon endroit ? C’est exactement là où je mentionnais précédemment à quel point le mobile est pratique pour les projets personnels. Les créateurs de Claude Code sont toujours en avance d’un pas sur la manière dont ces modèles sont utilisés ; il y a environ neuf mois, lors d’une conversation avec lui, il m’a dit : « J’ai déplacé la majeure partie de mon travail sur Claude Code vers le mobile. » J’étais sceptique à l’époque, mais surtout à ce niveau de Fable, car il permet de maintenir les sessions en cours, et nous disposons chez Anthropic de machines de développement à distance ; donc le premier point est : désolidariser l’endroit où le travail se fait de l’endroit où je discute du travail.

Le deuxième point, en lien avec ce que j'ai dit précédemment : comment prenez-vous tout ce que Fable a discuté, décidé ou recommandé, et le rendez-vous compréhensible ? C’est le domaine sur lequel nous réfléchissons actuellement. Il existe certaines compétences pour créer des graphiques, mais l’interface de chat actuelle n’est pas suffisante ; Fable vous donne parfois une quantité énorme de texte, au point que vous devez faire une promenade pour être prêt à le comprendre. Une chose que j’ai commencé à faire est : « Vous avez beaucoup plus de contexte sur ce sujet que moi. Pourrions-nous revenir en arrière — et adopter une approche plus progressive de la révélation de la complexité ? »

Le troisième est le mode multijoueur, et nous sommes encore en phase de découverte précoce. Dans une certaine mesure, comme nous avons une structure de DRI et de zones de propriété, un travail important consiste souvent à faire circuler un flux entre une personne et plusieurs Claude. Mais dans certains cas, ce n’est pas aussi évident — par exemple, lors d’une réponse à un incident, plusieurs personnes réfléchissent simultanément ; ou lors de projets où plusieurs domaines se croisent. Le partage de discussions résout une partie du problème, mais je pense qu’il y aura un besoin futur : vous avez un Claude indépendant, lancé par une personne qui a accompli beaucoup de travail, mais peut-il rester synchronisé avec tout le reste du travail en cours au sein de l’équipe ? C’est la prochaine frontière intéressante et sous-exploitée. Ce qui est passionnant, c’est que les modèles ont désormais la capacité d’être de véritables coéquipiers, et nous les freinons presque en ne disposant pas des bonnes abstractions.

L’animateur Dan Shipper : Cela me fait penser que la plupart du temps, j’utilise ce modèle pour mes propres projets de vibe coding, mais il y a un problème lorsque vous l’utilisez au sein d’une organisation : comprends-je vraiment toutes les parties que le modèle vient de produire ? Comment transférer le contexte de ce que le modèle vient de faire dans ma tête ? C’est un gros goulot d’étranglement. Comment déterminez-vous la limite de « combien je dois vraiment savoir » et comment vous assurez-vous d’avoir suffisamment de contexte pour vous sentir à l’aise ?

Mike Krieger :

Deux grandes parties. La première, c’est la validation. J’ai été complètement convaincu par la validation au début de cette année, ce qui résonne avec une expérience que j’ai eue quand j’écrivais du code à plein temps : trouver le cycle de développement le plus court pour tourner autour de votre idée. À l’ère d’Instagram, cela signifie parfois créer une nouvelle cible de build dans Xcode, contenant uniquement cet écran et des données synthétiques, et itérer uniquement sur ce cycle. Je conseillais aux nouveaux ingénieurs : « Si je ne devais enseigner qu’une seule chose, ce serait de mettre en place cela pour votre projet — ça accélérerait tout ».

La situation actuelle est la suivante : chaque fois que je développe quelque chose, je m'assure que chaque PR de Claude inclut des photos ou des vidéos — que ce soit pour une modification iOS ou pour une modification au niveau de l'interface utilisateur. Cela vous donne beaucoup de confiance. Fable pourrait travailler seul pendant plusieurs heures, puis revenir vous dire « J'ai fini », et vous verriez alors « Voici une galerie de captures d'écran de l'ensemble de l'interface utilisateur » — ce qui est extrêmement utile. Vous pourriez dire : « Dans cette capture d'écran, l'état d'erreur — je ne l'ai jamais vu, mais je peux comprendre ce que l'utilisateur ressentirait s'il le rencontrait. Modifions cela. » Effectuer une validation complète est une priorité majeure au sein de notre équipe.

Deuxième point : vous restez finalement responsable du travail que vous effectuez. Beaucoup de gens utilisent Claude quotidiennement, mais il existe toujours une forme de responsabilité : « Claude a peut-être écrit le code, mais vous devez comprendre quelles décisions globales ont été prises ». Je constate qu’un nombre croissant d’ingénieurs adoptent une pratique consistant à effectuer, après que Claude a terminé son travail, une discussion de suivi : « Puis-je m’assurer que je comprends parfaitement tous les compromis que vous avez faits ? » Quel que soit l’artéfact produit, s’il permet de le rendre plus facile à comprendre, cela vaut la peine d’être fait.

C’était amusant pendant les réunions — quelqu’un disait : « J’ai préparé ce PR », et quelqu’un d’autre demandait : « Tu as fait X ou Y ? » Puis il y avait un moment de silence : « Honnêtement, je ne suis pas sûr — je vais vérifier avant de fusionner. » S’adapter à cette nouvelle norme et apprendre à travailler avec, c’est ce que nous devons tous apprendre.

Animateur Dan Shipper : Ce « cycle de vérification » que vous venez de mentionner offre un potentiel incroyable. Outre les captures d’écran automatisées et le partage d’écran, quelles autres approches plus avancées explorez-vous ?

Mike Krieger :

Notre point d'entrée principal est : pouvez-vous faire exécuter le processus réel, et non simplement injecter des données statiques ? À mesure que le système devient de plus en plus complexe, cela devient de plus en plus difficile. Par exemple, nous devons permettre à l'application iOS générée par Fable de se connecter en un seul clic à notre environnement de simulation, en utilisant uniquement des comptes de test réels et des flux de données hautement fidèles. Toutefois, nous ne voulons pas que, lorsqu'elle teste un simple ajustement de bouton, elle doive systématiquement parcourir le long et fastidieux processus d'inscription de nouvel utilisateur en huit étapes. Nous avons donc développé un système spécialisé de permissions avancées et de clés de partage chiffrées dédiées à l'IA, permettant à celle-ci de sauter directement les étapes préalables et d'accéder immédiatement au cœur du processus métier, afin que son expérience de test soit quasi identique à celle d'un utilisateur réel.

La deuxième partie est la combinaison du chemin connu et du chemin modifié actuel — le premier est très précieux pour les tests de régression. Nous avons déjà exprimé par écrit certains flux de travail idéalisés que Claude peut vérifier répétitivement. De plus, Claude s'exprime très bien sur l'intention des modifications qu'il effectue actuellement, ce qui permettra de les exercer en profondeur. La combinaison de ces deux éléments est essentielle.

La vérification visuelle est également cruciale, et la vidéo est un outil extrêmement sous-utilisé pour Claude. Récemment, j’ai développé un prototype : je fais enregistrer en vidéo ce que Claude a créé, puis je lui fournis cette vidéo avec FFmpeg, en le regardant analyser chaque image frame par frame, puis dire : « Cette animation a des saccades, je vais la corriger ». Une capture d’écran ne pourra jamais capturer cela, car elle manque ce moment précis.

Pour les parties difficiles à tester de bout en bout, il est également très intéressant de faire construire par Claude un backend simulé fiable, ou d’utiliser une solution existante. À l’ère d’Artifact, nous avions déjà, dans l’ère pré-LLM, des tests très complets : chaque composant d’infrastructure disposait d’une implémentation mémoire optimale, permettant un fonctionnement rapide lors des tests unitaires. Maintenant, étendons cette approche au domaine de Claude : je développe un système avec un backend relativement robuste, difficile à démarrer sur mon serveur de développement, mais il a immédiatement généré une excellente alternative. Au fil du temps, cette alternative évolue en parallèle avec le code lui-même. Avant, je disais : « Cela nécessiterait trop de synchronisation ». Maintenant, je pense simplement : « Claude va lire les changements, adapter l’alternative et maintenir la synchronisation entre les deux. C’est tout. »

L’animateur Dan Shipper : Il y a des architectures très intéressantes : lorsque vous recevez un bogue, un agent le corrige automatiquement, puis envoie un message au client pour dire « Corrigé ». Avez-vous remarqué une évolution de ce processus sur Fable ?

Mike Krieger :

Plusieurs aspects. Au niveau de l'interaction entre les humains et Claude, il y a une chose que je vois constamment : lorsque quelqu'un signale un bogue dans le canal de feedback de notre Slack, ce fil est transféré à une session Claude Code. Grâce au MCP Slack, il peut réellement récupérer ce fil et répondre en mon nom : « C'est Claude de Mike, j'ai corrigé le problème, voici le lien vers la PR. » Mais ensuite, il ajoute : « Ne vous précipitez pas — ce n'est pas encore en production. Je vous notifierai une fois que ce sera en ligne. » Quelques heures plus tard : « Le déploiement a été effectué. Vous devriez essayer pour voir si le correctif fonctionne ? » Ce suivi en boucle fermée est relativement nouveau. J'ai eu plusieurs sessions Claude Code à long terme qui interagissaient en mon nom, et j'y ai inclus quelques mentions de non-responsabilité.

La deuxième chose revient à ce que nous venons de discuter : le goût et le jugement. D’un côté, il y a « il y a un bug à signaler, donc je dois le corriger » ; de l’autre, il y a un bon jugement. Un week-end, j’ai rencontré une situation : nous avions un système interne qui fonctionnait depuis longtemps sans redémarrage et présentait une fuite mémoire. Un bon jugement consiste à dire : « Mike, c’est le week-end. Redémarre le serveur maintenant, ça résout le problème immédiatement ; je créerai un PR en arrière-plan pour une correction à long terme. » Si vous faites intervenir Claude dans ce processus de diagnostic à correction, vous souhaitez vraiment qu’il comprenne ce que tout bon SRE ou ingénieur comprend : résoudre le problème immédiat, et la question de remplacer ou重构 la plateforme peut être traitée plus tard. Comprendre cet équilibre est essentiel.

L'hôte Dan Shipper : Ce qui rend ces nouveaux modèles les plus excitants de cette génération, ce n'est pas seulement qu'ils élèvent le niveau de base, permettant à n'importe qui, même sans expérience, de créer en un seul clic son propre app, mais aussi qu'ils font tomber le plafond des experts. Si vous êtes actuellement ingénieur professionnel ou fondateur d'une équipe de start-up, vous avez tout à fait la capacité de réaliser seul des projets complexes que vous n'auriez jamais osé envisager auparavant. Selon vous, quels domaines de pointe pourraient encore être sous-estimés, mais sont entièrement accessibles avec ces modèles pour une mise en œuvre immédiate ?

Mike Krieger :

Quelques idées, peut-être commençons par quelque chose de amusant. Les gens ont toujours de nombreuses idées créatives pour exprimer la complexité de leur monde ; dans chaque domaine, il y a quelque chose que vous connaissez particulièrement bien, et il y a toujours une version de : « Comment puis-je l'expliquer aux autres ? Puis-je appliquer des technologies d'autres domaines à mon propre travail ? » Prenez mon amie Tai Tan : elle travaille actuellement à la croisée des chemins en ingénierie environnementale, en se concentrant sur l'énergie géothermique, un domaine rempli de modèles mathématiques complexes et de simulations en mécanique des fluides. Mais avec la mise à niveau révolutionnaire des modèles de raisonnement de la génération Fable, elle a réussi à intégrer parfaitement des technologies extrêmement techniques, totalement étrangères à son domaine d'expertise, dans son propre travail de recherche. Aujourd'hui, elle peut même demander à Fable de lui construire un système complet de simulation d'apprentissage profond end-to-end avec PyTorch — ce qui, auparavant, aurait été une pure fantaisie pour une chercheuse non spécialisée en informatique.

La deuxième partie est sa capacité à combiner des logiciels pour résoudre des problèmes extrêmement uniques pour vous. À l'intérieur, nous avons accompli un grand nombre de travaux en transformant autant que possible nos systèmes internes en MCP, accompagnés de la bonne structure de permissions et de paramètres de déploiement. Il existe également d'excellentes plateformes PaaS externes ; vous n'avez qu'à demander à Claude, et il vous les configurera. Mais j'apprécie particulièrement cette sensation de « avoir créé quelque chose que je voulais depuis longtemps ».

Une autre chose qui m’a profondément impressionné récemment : un collègue de notre équipe commercialisation, qui n’est pas issu du domaine technique, a intégré Claude en profondeur dans chaque aspect de ses processus opérationnels quotidiens. Ce qui est le plus effrayant, c’est qu’elle n’a pas arrêté après la version V1 — elle a continué, avec cet outil, à itérer intensément pendant plusieurs mois, en arrière-plan, en collaboration étroite avec le modèle de grande taille.

Cela révèle précisément le point le plus sous-estimé et le plus séduisant de cette génération de modèles de raisonnement : dans la limite de survie des générations précédentes, les projets présentaient souvent un « plafond de complexité ». Dès que votre code métier ou votre logique atteignait un certain volume, le grand modèle commençait à « négliger la fin au profit du début » ; dès que vous tentiez d’ajouter une nouvelle fonctionnalité, il déclenchait des erreurs folles et détruisait littéralement votre architecture existante.

Mais maintenant, cette collègue non technique, soutenue par un modèle du niveau de Fable, a fait croître son système en arrière-plan pendant plusieurs mois. Vous pouvez clairement voir ce logiciel évoluer comme un organisme vivant, se développant, se développant, évoluant follement sous l’irrigation de l’IA. Aujourd’hui, elle commence à déployer ce système auto-construit, extrêmement vaste et complexe, à l’ensemble du département commercial de notre entreprise.

Un simple particulier sans aucune formation en programmation parvient aujourd’hui, grâce à ses propres moyens, à pousser la complexité d’un logiciel à long terme à un niveau aussi étouffant — c’est un miracle sans précédent dans l’histoire de la technologie humaine.

L'animateur Dan Shipper : Un autre élément très puissant que vous avez mentionné est le workflow dynamique ; pouvez-vous m'en dire plus ?

Mike Krieger :

Nous créons régulièrement en interne des outils de pointe de ce type, et je pousse sans relâche les ingénieurs qui les développent : « Quand est-ce que ce truc va être publié officiellement ? » Parfois, des contraintes techniques fondamentales obligent à les tester en interne en premier, mais nous faisons tout notre possible pour les lancer sur le marché le plus tôt possible. Pour moi, le workflow dynamique est absolument l’un de ces outils qui vont épater le monde.

Il y a deux grandes raisons pour lesquelles les modèles comme Fable sont particulièrement puissants. La première est qu'ils peuvent vous aider à créer une structure pour des travaux approfondis et significatifs. La chose la plus folle que j'aie faite avec Fable, c'est de lui soumettre directement un projet Python interne assez complexe, afin qu'il me réécrive entièrement un ensemble de fonctions métier essentielles en TypeScript — nous avions alors des considérations spécifiques de déploiement en production.

À l'époque sur Instagram, la direction avait également débattu avec une grande sévérité : « Devrions-nous réécrire entièrement le code sous-jacent d'IG en langage Hack afin de l'intégrer parfaitement à l'infrastructure de Facebook ? » Notre conclusion à l'époque était : Pas question, ce n'est tout simplement pas réalisable.

Mais juste le week-end dernier, face à une base de code centrale tout aussi complexe, j’ai simplement lancé un flux de travail dynamique en arrière-plan, puis je suis parti profiter de mon week-end. J’ai configuré le flux de travail comme suit : comprendre en profondeur le code existant, générer un document détaillé ressemblant à une spécification expliquant comment tout fonctionne, traduire les modules un par un, effectuer des tests incrémentaux, réaliser des validations adversariales et vérifier les éléments manquants. Lorsque je suis revenu lundi, j’ai allumé mon ordinateur et j’ai vu un miracle s’être produit — il avait déjà transformé tout cela en un tout nouveau système fonctionnant sur la chaîne d’outils TypeScript et Bun, et, à certains niveaux d’architecture, il était même plus élégant et plus rapide que ma version originale en Python.

Une autre raison à plus long terme, plus séduisante : avec la popularisation des flux de travail dynamiques, nous pourrons bientôt répartir de manière transparente des sous-tâches de difficulté variée entre une hiérarchie de modèles adaptés à leur complexité respective.

Animateur Dan Shipper : Pour ceux qui n'ont jamais utilisé cela, expliquez-moi comment vous avez conçu ce flux de travail. Comment l'avez-vous conçu ? Comment avez-vous assuré qu'il était bon ?

Mike Krieger :

L'ensemble du processus de formation est en réalité rempli d'un intérêt geek itératif. Au départ, j'ai simplement ouvert Claude Code et lui ai dit : « Frère, j'ai actuellement un projet de refonte extrêmement complexe — viens, travaillons ensemble sur la conception d'un flux de travail entièrement automatisé. »

Il m'a montré le plan, et j'ai dit : « C'est presque ça, mais j'ai besoin de trois à quatre niveaux de vérification supplémentaires pour vérifier les fonctionnalités manquantes. » Ensuite, il a répondu : « Voici votre plan. Êtes-vous prêt ? » Le flux de travail est exprimé en code, et je trouve cela extrêmement précieux : on peut voir exactement comment il va procéder.

Après avoir effectué la migration complète, j’ai quelques ajustements mineurs à apporter, que je vais traiter comme des mini-workflows en continuant à partir de la sortie du workflow précédent. Cela ramène à la question : le chat est-il la bonne interface ? Le workflow constitue un bon compromis : vous utilisez le chat pour l’orchestrer, mais il est exprimé en code, puis exécuté dans une interface propre où chaque étape montre ce qui se passe. Je pense que nous utiliserons par la suite une approche similaire pour relier les tâches à long terme au chat.

Organisé et compilé par Shenchao TechFlow