Entretien avec le fondateur d’Instagram : sortie d’Anthropic Fable 5, l’ère du codage entièrement manuel appartient désormais au passé
TechFlow SélectionTechFlow Sélection
Entretien avec le fondateur d’Instagram : sortie d’Anthropic Fable 5, l’ère du codage entièrement manuel appartient désormais au passé
Sonnet et Fable 5 ne sont pas du tout comparables en termes d’expérience utilisateur.
Dédié à des analyses Web3 approfondiesRédaction & traduction : TechFlow
Invité : Mike Krieger, cofondateur d’Instagram
Animé par : Dan Shipper
Source du podcast : Every
Titre original : Mike Krieger Lets Fable 5 Code While He Sleeps
Date de diffusion : 11 juin 2026
Résumé des points clés
Mike Krieger, cofondateur d’Instagram, a personnellement contribué à la création de l’une des applications grand public les plus influentes au monde ces vingt dernières années. Aujourd’hui, il se trouve à la pointe du développement de produits « natifs IA », en tant que chef de file d’Anthropic Labs. Avec son équipe, il s’attaque à une question fondamentale : lorsqu’on place les modèles d’intelligence artificielle les plus avancés au monde entre les mains de véritables développeurs, jusqu’où peut-on repousser les limites techniques ?
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 qu’il en a ressenti fut si puissant qu’il s’en souvient encore aujourd’hui. « Bon, je me sens à nouveau complètement débutant », s’était-il moqué auprès de son équipe. Il venait de réaliser que toutes les règles empiriques qu’il avait accumulées au fil de décennies — sur l’optimisation de l’efficacité, les stratégies de développement ou la gestion du temps — étaient désormais obsolètes. La vitesse d’évolution du modèle avait tout simplement dépassé sa propre façon de travailler.
Dans cet épisode, l’animateur entame une conversation approfondie avec Mike Krieger afin d’explorer ensemble ce que signifie réellement coconstruire des logiciels aux côtés d’un modèle révolutionnaire tel que Fable. Dans cette nouvelle normalité de symbiose homme-machine, quelles nouvelles dynamiques de développement émergent-elles ? Quels défis majeurs se posent ? Et surtout, quelles possibilités imaginatives et ultimes s’ouvrent à nous ?
Résumé des idées marquantes
Comment Fable a radicalement transformé le flux de travail de Mike
- « Une véritable montée en compétence cognitive ne survient pas dès la première utilisation, mais après plusieurs semaines d’utilisation intensive… Au fil du temps, les utilisateurs prennent soudainement conscience : “Je n’ai pas encore exploité pleinement ses capacités. Je dois aller plus loin, repenser les limites réelles de cette génération de modèles.” »
- « La bonne approche aujourd’hui consiste à lui transmettre une intention globale et suffisamment précise, puis à laisser totalement libre cours à son exécution. Non seulement il produit immédiatement des résultats impressionnants, mais ce qui est encore plus remarquable, c’est sa capacité à comprendre l’évolution future de cette fonctionnalité ainsi que le contexte global du projet. »
- « Ce qui m’a le plus impressionné, c’est sa capacité à boucler automatiquement les tâches. Par exemple, il pourrait penser : “Mike m’a demandé d’exécuter une tâche complexe ce soir. Or, je suis bloqué car le serveur distant est hors ligne. Très bien, je vais d’abord écrire moi-même un backend simulé (mock) pour pallier ce problème…” Pour moi, pouvoir déléguer un niveau de responsabilité aussi élevé, et faire confiance aveuglément à son résultat final, constitue une expérience profondément bouleversante. »
- « Autrefois, nous comparions ces modèles à des “assistants” ou à des “compagnons”. Aujourd’hui, ils ressemblent davantage à de véritables coéquipiers capables d’assumer la responsabilité et de livrer une grande partie du travail central. »
Quand utiliser Sonnet, quand utiliser Fable
- « Ce n’est même pas une question de magnitude comparable. Cela n’a rien à voir avec le nombre de tokens générés par seconde, mais concerne plutôt la quantité de “capacité mentale” requise pour résoudre le problème. Parfois, une réponse simple ne nécessite absolument pas ce genre de réflexion approfondie. »
- « La plupart du temps, lorsque j’ouvre une application iOS, ce n’est certainement pas pour effectuer des tâches assez lourdes pour justifier l’appel à Fable… Récemment, j’ai moi-même ressenti très intensément cette nuance subtile : “Ce problème ne mérite même pas Fable ; je devrais plutôt solliciter Sonnet.” »
- « Fable est également le premier modèle que j’ai rencontré qui me pousse activement à régler le “niveau d’effort raisonné” (Reasoning Effort). Avant, avec Opus, je ne réglais presque jamais ce paramètre, car la plage de flexibilité du modèle était alors bien plus étroite. Mais avec Fable, cette marge peut vraiment être très large. »
L’architecture native Agent rendue possible par Fable 5
- « L’architecture “native Agent” commence par une exigence fondamentale : chaque composant central et chaque donnée du produit doivent être entièrement accessibles aux Agents, et dotés d’interfaces d’appel dédiées. Cela devient rapidement la ligne de base minimale du secteur logiciel — même si, hélas, la majorité des logiciels actuels sur le marché ne remplissent même pas ce critère minimal. »
- « En maintenant appuyé le bouton de discussion dans l’application, on active notre Agent géré pour recevoir des instructions de modification de code… Lorsque je joue avec mon enfant à l’extérieur, je remarque que “ce bouton flottant est trop bas sur iOS”, et je lui donne directement l’instruction dans l’application : il va aussitôt modifier le code en arrière-plan. »
- « Comment intégrer Claude dans les logiciels ? Ce ne doit pas se limiter à une simple “utilisation” ; Claude doit s’insérer profondément dans la “construction” même du logiciel, jusque dans ses os. »
Le coût de construction s’est effondré
- « En comparaison avec la version V1 d’Instagram — certes plus fonctionnelle que le traceur de médias que j’ai réalisé ce week-end — il n’y a aucune différence qualitative ni quantitative essentielle. Pourtant, à l’époque, Kevin et moi avons dû veiller cinq nuits d’affilée pour produire cette V1… Aujourd’hui, le temps de construction s’est réduit à un niveau stupéfiant. »
- « Le fossé entre “intention” et “exécution” s’est comblé, même pour les personnes non techniciennes… C’est la première fois de ma vie que je ressens une parfaite continuité entre ce que j’imagine dans mon esprit et ce qui existe réellement dans le monde physique. Je peux le créer directement. »
- « La créativité humaine est infinie. Ce que nous faisons aujourd’hui de plus extraordinaire, c’est d’élargir sans fin la frontière du groupe de personnes capables de transformer leurs idées en réalité concrète. »
L’ingénierie logicielle est-elle morte ?
- « Le sens même de l’ingénierie logicielle a complètement changé. Elle vit une transformation radicale. … L’ère du développeur artisan, uniquement focalisé sur la frappe de code, est probablement révolue pour toujours. »
- « Le rôle des ingénieurs seniors demeure irremplaçable : leur expérience accumulée dans la gestion d’incidents leur permet de garder un sang-froid absolu, de collecter exhaustivement les journaux, d’appliquer des mesures d’urgence, puis de concevoir des solutions correctives durables. »
- « Autrefois, dans la Silicon Valley, on disait souvent “le code tranche les débats” (Code wins arguments). Personnellement, j’ai toujours été plutôt sceptique face à cette formule, car elle sous-entend que celui qui sait coder détient le pouvoir décisionnel. Or, aujourd’hui, l’évolution prend une tournure fascinante : parfois, lorsqu’un désaccord persiste sur la direction d’un produit, c’est un chef de produit (PM), qui ne code pas, qui arrive en disant : “J’ai juste fait moi-même une démonstration…” Cela ouvre instantanément un dialogue hautement qualifié, d’un tout autre niveau. »
- « Le trait le plus marquant est une parallélisation extrême du développement, ainsi qu’une nécessité absolue pour les équipes de procéder à des abstractions de haut niveau de leur flux de travail. Toutefois, une chose est restée inchangée depuis le début : la “propriété” et la “responsabilité” humaines vis-à-vis du produit. »
Mécanismes et coûts de vérification
- « Le concept même de “coût” s’est aujourd’hui multi-dimensionnel — il ne s’agit plus seulement du coût d’une seule requête, mais bien du coût global pour mener une tâche à son terme. Ce qui m’a le plus impressionné chez Fable, c’est précisément ce dernier aspect : il tend systématiquement à accomplir la tâche correctement du premier coup, sans que je doive m’asseoir devant mon ordinateur pour lutter avec lui pendant huit ou neuf itérations. »
- « S’adapter à cette nouvelle normalité, comprendre comment collaborer efficacement avec ce modèle, est une compétence que chacun doit apprendre. … À chaque fois que je construis quelque chose, je m’assure que chaque PR générée par Claude soit accompagnée d’une photo ou d’une vidéo — que ce soit pour une PR iOS ou pour une modification au niveau de l’interface utilisateur. Cela renforce considérablement ma confiance. »
- « La vidéo constitue un outil extrêmement sous-exploité pour Claude. Récemment, j’ai conçu un prototype où je fournis à Claude une vidéo de l’élément qu’il a créé, en combinaison avec FFmpeg, et je le regarde analyser chaque image individuellement, puis dire : “Cette animation présente des saccades ; je vais la corriger.” Une capture d’écran ne pourrait jamais révéler cela, car elle manquerait précisément ce moment fugace. »
Flux de travail dynamique
- « Dans les générations précédentes de modèles, les projets étaient confrontés à un “plafond de complexité”. Dès que le code métier ou la logique atteignaient un certain volume, les grands modèles commençaient à “regarder devant sans regarder derrière”… Aujourd’hui, cette collègue non technicienne, assistée d’un modèle de niveau Fable, fait évoluer son système en arrière-plan depuis plusieurs mois. On voit clairement ce logiciel croître comme un organisme vivant, nourri constamment par l’IA, s’adaptant, évoluant, se transformant de façon spectaculaire. »
- « Le flux de travail représente un bon compromis intermédiaire : vous l’orchestrez via le chat, mais il est exprimé en code, puis exécuté dans une interface utilisateur claire, où chaque étape est explicitement visualisée. Je pense que nous allons progressivement adopter ce type d’approche pour relier les tâches à long terme au chat. »
Comment Fable a radicalement transformé le flux de travail de Mike
Dan Shipper, animateur : Nous avons le grand plaisir d’accueillir aujourd’hui Mike Krieger, responsable d’Anthropic Labs et cofondateur d’Instagram. Mike, j’aimerais beaucoup entendre ton ressenti personnel après avoir utilisé intensivement ce modèle. Lorsqu’un modèle aussi puissant est lancé, si une personne qui l’utilise quotidiennement dit : “Il excelle de façon exceptionnelle ici, il transforme réellement mon flux de travail là, et dans certains domaines, il reste finalement assez banal”, cela aide grandement les gens à comprendre comment intégrer concrètement cette technologie dans leur quotidien.
Mike Krieger :
Exactement. Cette expérience est en soi fascinante. Plusieurs mois avant la sortie officielle de Fable, nous avions déjà mis en œuvre en interne plusieurs modèles de niveau Mythos. J’attendais avec impatience de voir ce que les développeurs externes allaient en faire. Mais comme tu l’as souligné, la véritable montée en compétence cognitive ne survient pas dès le premier jour, mais après plusieurs semaines d’utilisation intensive.
Nous avions déjà connu ce type de reconfiguration cognitive avec les modèles antérieurs. Entre la fin décembre et le début janvier, lors de l’utilisation concentrée d’Opus 4.5 et 4.6, les utilisateurs ont pris soudainement conscience, au fil du temps : « Je n’ai pas encore exploité pleinement ses capacités. Je dois aller plus loin, repenser les limites réelles de cette génération de modèles. »
Dan Shipper : Notre équipe Every utilise déjà ce modèle en interne. Certains collègues rapportent : “Je dois apprendre une toute nouvelle arborescence de compétences pour maîtriser ce modèle”, notamment ceux qui n’ont pas de formation technique, mais travaillent dans des fonctions axées sur la connaissance — ils se sentent même un peu perdus ; tandis que les spécialistes de l’orchestration d’Agents (intelligents) s’exclament : “Il y a tellement de choses nouvelles à apprendre !”
Mike Krieger : Ton observation sur la « transformation du flux de travail » touche juste — il ne s’agit pas seulement de changer des gestes opérationnels, mais bien d’une mutation mentale. Par hasard, l’apparition de ce modèle coïncide avec une période de transition professionnelle pour moi : je venais juste de passer du poste de Chief Product Officer (CPO) à celui de chef des Labs, revenant ainsi pleinement au mode développeur. Environ un mois et demi à deux mois après ce changement, le modèle a été validé en interne pour la première fois. Devant mon ordinateur, je me suis dit : « Bon, je suis redevenu débutant. » Car j’ai réalisé que mes habitudes antérieures de rédaction de prompts, voire même ma manière de décomposer les tâches, étaient désormais obsolètes face à ce modèle.
Votre perception du temps et vos modes d’interaction doivent évoluer. Autrefois, j’aurais pu dire : « J’ai une idée de fonctionnalité, commençons par la première étape… » Aujourd’hui, c’est absolument impossible. La bonne méthode est désormais la suivante : transmettre une intention globale et suffisamment précise, puis laisser totalement libre cours à son exécution. Je me souviens qu’en mars-avril, ses capacités étaient déjà impressionnantes — non seulement il produisait immédiatement des résultats saisissants, mais ce qui était encore plus remarquable, c’était sa capacité à comprendre l’évolution future de cette fonctionnalité ainsi que le contexte global du projet.
Et cette évolution ne s’arrête pas. Ce matin encore, je discutais avec quelqu’un de mon travail — en avion — et j’ai pris conscience que « la majeure partie de mon travail peut effectivement être réalisée à distance ». Je ne m’inquiète même plus de savoir si la connexion Wi-Fi va tomber, car tant que j’ai défini correctement le contexte et les instructions avant la coupure (par exemple, une commande exécutée en boucle), il poursuivra la tâche jusqu’à son achèvement.
Au cours des deux derniers mois, j’ai vécu plusieurs moments de grâce : je dis bonne nuit à Claude avant de me coucher, lui confie une tâche complexe, et au réveil, je découvre qu’elle est entièrement terminée — généralement vers 2 heures du matin, le corps principal étant achevé, les quatre heures suivantes étant consacrées au raffinement des détails.
Ce qui m’a le plus impressionné, c’est sa capacité à boucler automatiquement les tâches. Par exemple, il pourrait penser : « Mike m’a demandé d’exécuter une tâche complexe ce soir. Or, je suis bloqué car le serveur distant est hors ligne. Très bien, je vais d’abord écrire moi-même un backend simulé (mock) pour pallier ce problème, documenter ce blocage, faire fonctionner l’ensemble du processus, sauvegarder l’état, et attendre la restauration du service pour appliquer la correction définitive. » Pour moi, pouvoir déléguer un niveau de responsabilité aussi élevé, et faire confiance aveuglément à son résultat final, constitue une expérience profondément bouleversante.
Bien sûr, vous devez ensuite examiner les résultats — ce qui implique un mécanisme complet de vérification, dont nous parlerons plus tard, car il s’agit d’un maillon crucial de la boucle fermée. Mais cela me force à repenser radicalement : face à un tel modèle, qu’est-ce que la « productivité » ? Autrefois, nous comparions ces modèles à des « assistants » ou à des « compagnons ». Aujourd’hui, ils ressemblent davantage à de véritables coéquipiers capables d’assumer la responsabilité et de livrer une grande partie du travail central.
Dan Shipper : À quoi ressemble donc ton flux de travail quotidien ? J’ai remarqué un phénomène : lorsque tu lui confies une tâche ambitieuse, que tu lui fournis une description longue et détaillée, puis que tu laisses le modèle travailler plusieurs heures, voire toute la nuit, ses performances sont maximales. Mais face à des petites tâches quotidiennes, il semble trop lent, trop coûteux, et on hésite à l’utiliser. Comment fais-tu ce choix dans la pratique ? Où se situe-t-il dans ta pile technologique ?
Mike Krieger :
Aujourd’hui, je l’utilise principalement pour la planification architecturale initiale et l’alignement des solutions. C’est une évolution intéressante, et c’est aussi un défi que tous les modèles doivent encore relever.
À cet égard, je suis reconnaissant de mon expérience passée avec Instagram — de la mise en place rapide d’une version minimale sur un seul serveur à Los Angeles, à la gestion de la concurrence massive, à la montée en échelle, puis à l’intégration progressive dans l’infrastructure de Facebook. Ce parcours forge une intuition naturelle : « À quel stade du projet faut-il employer quel niveau d’abstraction architecturale et de complexité ? »
Ainsi, je continue à dialoguer fréquemment avec Fable. Parfois, il propose une solution d’implémentation apparemment parfaite, et je lui demande : « Je prévois effectivement de déployer ceci prochainement — nous devons donc envisager la capacité de charge au-delà d’un seul serveur. » Cette interaction bidirectionnelle est cruciale. 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 l’équipe. Même un simple fichier Markdown ferait l’affaire, mais je préfère nettement les formats illustrés.
Cela crée un paradigme intéressant : réfléchir et planifier conjointement avec lui, puis produire un document pour aligner l’équipe. Puisque la vitesse de prototypage est aujourd’hui fortement compressée, il devient encore plus essentiel d’obtenir un accord préalable et un alignement — même si vous comptez d’abord faire une démonstration rapide (« petit pas, itération rapide »), puis en déduire rétroactivement une architecture système plus rigoureuse, la communication initiale reste primordiale. C’est précisément là que la réflexion humaine et la collaboration restent profondément ancrées dans l’ensemble du processus.
Lors de la phase d’exécution, que ce soit la nuit ou pendant de longues périodes diurnes, lui confier des tâches distinctes à traiter simultanément signifie que je maintiens simultanément bien plus de conversations concurrentes qu’auparavant. J’aime parfois garder une session Claude Code ouverte en continu, lui permettant de déléguer toutes les tâches aux sous-Agents en arrière-plan, afin que le fil principal puisse répondre immédiatement à mes nouvelles instructions ; d’autres fois, j’ouvre carrément cinq ou six onglets dans mon navigateur, chacun traitant une tâche complexe à long terme.
Ce mode de fonctionnement, doté d’une vision à long terme et porté par une attitude « Ne vous inquiétez pas, je m’en occupe — cela prendra un peu de temps », recèle un potentiel immense. Nous explorons également, au niveau produit, comment mieux soutenir cette expérience — vous souhaitez certainement concilier les deux états « réponse immédiate » et « exécution prolongée en arrière-plan », dont l’interaction est particulièrement intéressante. Ma préférence personnelle est de garder au moins une fenêtre Claude à contexte élevé et à latence ultra-faible, avec une sensation intuitive de « Je suis prêt à intervenir à tout moment, une seule phrase suffit pour que je lance ou déclenche une sous-tâche. »
Quand utiliser Sonnet, quand utiliser Fable
Dan Shipper : Par exemple, si vous marchez dans la rue et qu’une question surgit soudainement — allez-vous sortir Fable ? N’est-ce pas un peu comme « utiliser un lance-roquettes pour tuer une mouche » ? Ou bien passez-vous fréquemment d’un modèle à l’autre ?
Mike Krieger :
Récemment, j’utilisais effectivement Fable pour tout, et l’expérience était exactement celle que tu décris — vous fixez l’écran, le voyant réfléchir intensément, sans fin.
Jusqu’à la semaine dernière, j’ai cherché une question si simple que j’en ai eu presque honte — concernant la finale NBA. J’ai alors basculé sur Sonnet sur mon mobile, et j’ai immédiatement compris : « Ah oui ! Pour ce genre de questions rapides, j’utilisais toujours Sonnet. » Ce n’est même pas une question de magnitude comparable. Cela n’a rien à voir avec le nombre de tokens générés par seconde, mais concerne plutôt la quantité de « capacité mentale » requise pour résoudre le problème. Parfois, une réponse simple ne nécessite absolument pas ce genre de réflexion approfondie.
Pour notre équipe produit, cela pose également une question passionnante. Globalement, vous ne voulez certainement pas que vos utilisateurs hésitent chaque jour devant l’interface pour choisir le modèle approprié. Idéalement, à long terme, nous pourrions regrouper les modèles dans quelques scénarios intuitifs et prêts à l’emploi ; ou encore, les répartir directement selon l’interface utilisateur — car, en toute honnêteté, la plupart du temps, lorsque je navigue dans une application iOS, ce n’est pas pour accomplir des tâches assez lourdes pour justifier l’appel à Fable. Une répartition transparente des modèles au niveau de l’interface pourrait donc être une piste. Nous devons explorer sérieusement ce que cela implique au niveau produit. Mais cette nuance subtile — « ce problème ne mérite même pas Fable ; je devrais plutôt solliciter Sonnet » — je l’ai moi-même ressentie très intensément ces derniers temps.
Tu as raison : pour les tâches interactives fréquentes et granulaires, Fable a tendance à approfondir systématiquement la réflexion. En fait, Fable est le premier modèle qui me pousse activement à régler le « niveau d’effort raisonné » (Reasoning Effort) — parfois, je me dis : « Je veux juste modifier un style d’interface utilisateur ; je vais régler son effort à “moyen” pour voir l’effet. » Avant, avec Opus, je ne réglais presque jamais ce paramètre, car la plage de flexibilité du modèle était alors bien plus étroite. Mais avec Fable, cette marge peut vraiment être très large.
Ce que le traceur de médias de Mike, réalisé le week-end, révèle sur l’architecture native Agent
Dan Shipper : Peux-tu nous montrer des exemples de ce que tu as réalisé avec lui ?
Mike Krieger :
Lors du lancement de cette nouvelle génération de modèles, nous avons lancé une initiative — encourager toute l’équipe à les utiliser sur leurs comptes personnels, notamment pendant les week-ends. Cela s’est révélé très intéressant, car Anthropic dispose de nombreux outils de productivité personnalisés en interne. Il est donc rafraîchissant, de temps à autre, de revenir à l’état le plus pur : « Je n’utilise que Claude Code, et je crée moi-même, le week-end, des petits projets amusants. » Cette sensation est formidable.
Dan Shipper : Tu l’exécutes dans l’application terminal ou dans l’application bureau ?
Mike Krieger :
Bonne question. Je passe la majeure partie de mon temps dans le terminal. Mais ce qui est amusant, c’est ma femme — elle n’est pas ingénieure, son profil est plutôt orienté design d’expérience utilisateur (UX) et gestion de produit (PM) — elle est tombée amoureuse de Claude Code via l’application bureau. Je pense que l’application bureau l’a aidée à ignorer de nombreux concepts abstraits complexes du niveau inférieur. Moi-même, pour ce projet, j’ai utilisé Ghostty et le terminal.
Je voulais simplement un « traceur de progression média » parfait — je joue à des jeux, regarde des séries, et reçois des recommandations de la part d’amis ; j’avais besoin d’un outil parfaitement adapté à mes propres habitudes d’organisation. Mes deux critères essentiels étaient : premièrement, ajouter des éléments doit être extrêmement facile — je dis simplement à Claude, verbalement ou par écrit, « ajoute ce lien à ma liste de suivi », et il recherche automatiquement sur le web, complète les informations et les classe soigneusement ; deuxièmement, une notification proactive — par exemple, lorsqu’une nouvelle saison ou une suite de jeu sort, il doit la détecter et la rechercher automatiquement.
La majeure partie de l’interface utilisateur a été réalisée d’un seul coup par Fable, ce qui est déjà remarquable. Mais l’une des pistes que je poursuis activement au sein des Labs cette année est la suivante : comment rapprocher au maximum l’équipe logicielle — qui est aujourd’hui Claude — du logiciel lui-même ?
C’était un samedi matin. Mon week-end était entièrement occupé par des activités avec mon enfant, donc le développement était entièrement « discontinu » : randonnée avec l’enfant, retour à la maison, quelques lignes de code, puis sortie à nouveau. Parfois, même en pleine randonnée, je ne pouvais m’empêcher de vérifier l’avancement — bien que je ne devrais pas consulter mon téléphone pendant que je joue avec mon enfant, surveiller à distance l’état d’avancement de sa tâche procure une sensation incroyablement satisfaisante.
J’ai alors eu une idée : pourquoi ne pas réaliser, à titre expérimental, un test radical — permettre au logiciel de se modifier lui-même depuis l’intérieur ?
Je lui ai demandé de développer à la fois une version mobile et une version web. J’avais déjà conçu une interface de discussion qui permet de dire directement à Claude : « Ajoute cette URL à ma liste de suivi. » Mais je souhaite que tous les logiciels acquièrent cette capacité — je ne veux plus jamais naviguer dans des menus complexes à plusieurs niveaux pour trouver une fonctionnalité.
Dan, sur de nombreux plans, j’essaie en réalité d’explorer les limites extrêmes de l’architecture native Agent.
La première étape de l’architecture native Agent consiste à ce que chaque composant central et chaque donnée du produit soient entièrement accessibles aux Agents, et dotés d’interfaces d’appel dédiées. Cela devient rapidement la ligne de base minimale du secteur logiciel — même si, hélas, la majorité des logiciels actuels sur le marché ne remplissent même pas ce critère minimal.
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 était extrêmement long et difficile à retenir, mais j’ai simplement mentionné vaguement le nom au système, et Claude l’a immédiatement trouvé et classé avec précision. Cette expérience est bien supérieure à une recherche aléatoire sur Google guidée uniquement par l’intuition.
Mais ce qui me passionne vraiment, c’est l’étape suivante : que signifierait, dans un contexte mobile, la modification directe du logiciel depuis l’intérieur même de l’application ?
Ce que j’ai fait — ou plutôt, ce que j’ai demandé à Claude de faire — est une interaction de ce type : dans l’application, un appui long sur le bouton de discussion active notre Agent géré pour recevoir des « instructions de modification de code », puis utilise la fonction de prévisualisation en direct (Live Preview) de Vercel pour voir immédiatement le résultat. L’ensemble du module fonctionnel a été validé d’un seul coup, ce qui est très impressionnant. J’y ai ensuite ajouté progressivement de nouvelles idées. Si vous êtes un joueur confirmé, vous pouvez même afficher la vue des différences (Diff) ou consulter l’historique des dialogues de l’Agent géré pour voir exactement ce qu’il a modifié en profondeur — bien que je ne consulte presque jamais ces détails, car pour un projet personnel, la maintenabilité à long terme ne m’importe pas du tout (rire).
Ce système est littéralement addictif. Lorsque je joue avec mon enfant à l’extérieur, je remarque que « ce bouton flottant est trop bas sur iOS », et je lui donne directement l’instruction dans l’application — il va immédiatement modifier le code en arrière-plan. Grâce à la chaîne d’outils de développement Expo, il réalise même un rechargement à chaud (Hot Reload) directement sur mon téléphone — cette expérience est tout simplement exceptionnelle.
Ce système doit-il atteindre un niveau de production capable de supporter un million d’utilisateurs simultanés ? Absolument pas. Mais il me procure un sentiment de maîtrise exceptionnel : vous n’êtes pas obligé de suspendre votre projet dès la fin du week-end, lorsque vous fermez votre ordinateur — vous pouvez l’utiliser intensivement tout en le modifiant à tout moment pendant son utilisation. Ce cycle de boucle fermée en temps réel vous permet d’itérer indéfiniment.
Ce n’est pas seulement une démonstration remarquable des capacités d’ingénierie robuste de Fable, mais aussi une illustration parfaite de la question fondamentale que nous explorons depuis longtemps : comment intégrer Claude dans les logiciels ? Ce ne doit pas se limiter à une simple “utilisation” ; Claude doit s’insérer profondément dans la “construction” même du logiciel, jusque dans ses os.
Le coût de construction s’est effondré
Dan Shipper : Je tiens particulièrement à ce que tout le monde prenne conscience d’un fait : des outils de ce type auraient pu être réalisés il y a dix ou vingt ans, mais certainement pas de cette manière. Le coût de construction logicielle a subi un effondrement spectaculaire. Pensez à l’époque d’Instagram : combien de ressources fallait-il investir pour porter un projet à ce niveau d’achèvement ? Et combien aujourd’hui ? Quantifie-nous cette rupture historique.
Mike Krieger :
Je me remémore souvent cette période. Au début d’Instagram, je me considérais moi-même comme un ingénieur extrêmement efficace — passionné par le développement mobile, doté d’une forte intuition sur la direction produit. Malgré cela, passer d’une idée dans ma tête à sa réalisation complète prenait encore au moins quatre ou cinq nuits blanches de travail acharné. Veiller jusqu’à 4 heures du matin, puis dormir jusqu’à midi — ce rythme était incompatible avec la vie familiale, mais c’était bel et bien mon « mode constructeur » à l’époque.
En comparaison avec la version V1 d’Instagram — certes plus fonctionnelle que le traceur de médias que j’ai réalisé ce week-end — il n’y a aucune différence qualitative ni quantitative essentielle. Pourtant, à l’époque, Kevin et moi avons dû veiller cinq nuits d’affilée pour produire cette V1 : j’ai assumé seul l’intégralité du frontend et du backend, tandis que Kevin s’est chargé des premiers filtres d’images. Et cela reposait sur notre expertise commune de plusieurs années en développement iOS.
Sans parler du rythme d’itération extrêmement frustrant à l’époque. Après le succès retentissant du lancement du produit, nous avions des milliers d’idées nouvelles en tête, mais toute notre énergie était absorbée par la nécessité de garantir que les serveurs ne tombent pas en panne sous le flux massif de trafic, ou par l’effort de glisser un minuscule ajout fonctionnel dans notre emploi du temps. Prenez la fonctionnalité des hashtags (étiquettes) : il m’a fallu une semaine entière rien que pour l’écrire, alors que j’avais encore des milliers d’autres idées bloquées dans la file d’attente des priorités.
Ainsi, il ne s’agit pas seulement d’une compression du temps — bien que le temps de construction soit effectivement réduit à un niveau stupéfiant — mais surtout de l’autre face de la médaille : vous pouvez désormais itérer instantanément et de façon fluide sur ce que vous possédez déjà.
Et cet avantage commence à déborder largement du cercle restreint des ingénieurs logiciels professionnels et des fondateurs comme moi. Autrefois, si vous aviez une excellente idée commerciale mais que vous ne saviez pas coder, vous n’aviez que deux options : soit faire appel à des prestataires externes — ce qui entraînait une distorsion extrême de l’information et des livrables médiocres ; soit chercher frénétiquement du financement. Aujourd’hui, le fossé entre “intention” et “exécution” s’est comblé, même pour les personnes non techniciennes.
Il y a quelques jours, j’ai reçu un message (Ping) de l’un de mes collègues internes. Nous lui avons configuré un outil interne, en connectant les capacités de Fable aux autorisations d’accès à certains de nos protocoles MCP (Model Context Protocol) internes. Elle travaille dans le domaine des ressources humaines (RH), et elle m’a dit, enthousiaste : « C’est la première fois de ma vie que je ressens une parfaite continuité entre ce que j’imagine dans mon esprit et ce qui existe réellement dans le monde physique. Je peux le créer directement. »
Ce moment a été pour elle un instant de stupeur marquant, véritablement historique. Il y a quatre ou cinq ans, si elle avait voulu un outil métier spécifique, elle aurait dû soit se contenter de bricoler avec des logiciels existants, soit supplier désespérément les ingénieurs de l’équipe outils internes — dont la file d’attente Jira comportait probablement encore 50 demandes prioritaires. Aujourd’hui ? Elle explore joyeusement le monde du code, conquérant de nouveaux territoires.
C’est aussi ce que je considère comme le plus prometteur pour l’avenir : la créativité humaine est infinie, et ce que nous faisons aujourd’hui de plus extraordinaire, c’est d’élargir sans fin la frontière du groupe de personnes capables de transformer leurs idées en réalité concrète.
L’ingénierie logicielle est-elle morte ?
Dan Shipper : Je partage totalement ton avis. Mais je pense que beaucoup de gens se posent secrètement une question ultime. Après avoir écouté ta description de tout cela : l’ingénierie logicielle, cette discipline, est-elle définitivement morte ?
Mike Krieger :
Disons plutôt que le sens même de l’ingénierie logicielle a complètement changé. Elle vit une transformation radicale.
Si, à l’époque d’Instagram, vous m’aviez demandé : « Qu’est-ce que l’ingénierie logicielle ? », j’aurais probablement répondu : « Réfléchir en profondeur aux problèmes de conception complexes, concevoir l’architecture du système, puis passer des heures interminables dans TextMate ou Xcode. Se battre contre les détails obscurs de l’ORM Django (Object-Relational Mapping), puis déployer, puis corriger les bogues avec acharnement. » La plupart de ces étapes ont aujourd’hui été bouleversées, et le domaine se rapproche de plus en plus de la gestion de produit. Aujourd’hui, la frontière entre chefs de produit et ingénieurs est devenue extrêmement floue. Cela se manifeste très clairement au sein de notre propre équipe de R&D.
Mais si vous vous libérez de la définition trop rigide du terme « ingénierie logicielle » pour examiner la « production logicielle » ou le « développement logiciel » dans un sens plus large — sans vous limiter à la seule petite portion du gâteau représentée par la frappe pure de code par les programmeurs — vous constaterez que ce secteur ne se porte pas seulement bien, mais occupe une position centrale sans précédent.
L’apparition de Fable m’a véritablement porté à un nouveau niveau de confiance dans les modèles IA — je commence à leur confier la « boucle fermée entièrement automatisée », voire même la conception d’architectures système raisonnables. Sur le plan de l’exécution technique, l’IA a parcouru un chemin extrêmement long. Mais « maîtriser l’âme de l’artisanat logiciel » — par exemple, identifier précisément la douleur utilisateur que vous atténuez, ou juger si l’expérience utilisateur de votre produit est suffisamment bluffante — ces jugements de haut niveau restent des traits humains extrêmement purs, impossibles à remplacer par une machine.
Bien sûr, cette transition douloureuse n’est pas sans douleur pour beaucoup.
Dans le monde, de nombreuses personnes ont été profondément attachées à l’« artisanat de la programmation manuelle ». Moi-même, à l’époque, j’étais ainsi. « Ce bogue m’a pris trois jours, et aujourd’hui, je l’ai résolu magnifiquement ! » Ce sentiment de satisfaction est irremplaçable. Vous pouviez même rêver de code — si vous avez connu cette expérience, vos rêves étaient peuplés de logique en pleine résolution, et au réveil, une illumination soudaine vous apportait la solution. Cette ère pure de l’artisanat est probablement révolue pour toujours.
Récemment, j’ai discuté avec certains des ingénieurs les plus talentueux et les plus chevronnés que je connaisse dans le secteur, et ils m’ont tous exprimé une émotion complexe intense : d’un côté, un profond sentiment de perte face à la disparition progressive de cet artisanat traditionnel ; de l’autre, une excitation extrême face à une productivité parallèle qui dépasse l’entendement.
Comment fonctionne aujourd’hui l’équipe d’ingénierie d’Anthropic
Dan Shipper : Puisque cette hypothèse est valable — l’ingénierie logicielle ne seulement pas morte, mais en pleine santé — comment votre propre équipe de R&D fonctionne-t-elle concrètement au quotidien au sein d’Anthropic ?
Mike Krieger :
Plusieurs axes très clairs émergent, que je peux illustrer à partir du cycle de vie complet du logiciel et de mes observations quotidiennes sur la R&D.
Avant tout, il subsiste encore une grande quantité d’« alignement humain ». Les équipes se réunissent en salle de réunion pour faire un brainstorming sur la prochaine évolution de Cowork, puis décomposent le plan directeur en zones de responsabilité attribuées à chaque membre. Cette étape reste cruciale, car de nombreux contextes globaux, propres à l’humain, ne peuvent pas être perçus à distance par Claude actuel — par exemple, l’intention commerciale réelle du produit, les lignes directrices cachées de la R&D, ou encore les informations sur d’autres lignes de produits qui seront bientôt retirées ou intégrées de façon très subtile.
Bien que chaque membre de notre équipe dispose de plusieurs « tours Claude » à sa disposition, au niveau de la gestion, chacun conserve un titre de DRI (Directly Responsible Individual — personne directement responsable), chargé de la responsabilité d’un module spécifique du produit. Je pense que ce mécanisme ne disparaîtra pas à court terme, car il existe un fossé fondamental entre la vision macroscopique collective — « nous collaborons de façon distribuée pour perfectionner le produit » — et l’exécution microscopique — « comment faire aujourd’hui pour que Claude exécute correctement cette tâche précise ». Bien que nous promouvions activement un régime de réunions minimaliste, ces séances préalables de brainstorming et d’alignement restent indispensables.
Ensuite, il y a une grande quantité de « délégation asynchrone ». De nombreux ingénieurs de notre équipe ont eux-mêmes personnalisé des tableaux de bord individuels pour surveiller l’activité de leur « armée Claude » : « À quel stade en est ma session Claude Code ? », « Quelles tâches sont bloquées en file d’attente en attendant mon approbation ? », « Quelles PR nécessitent mon intervention — parce qu’elles ont été refusées par un collègue ou par la revue de code d’un grand modèle ? »
Aujourd’hui, une grande partie de l’énergie des ingénieurs est consacrée à la maintenance de ce travail. Certains de ces outils de collaboration sont en cours de standardisation, mais la plupart conservent encore une forte coloration geek personnelle — tout comme les programmeurs d’antan personnalisaient leur bureau et leurs fenêtres, ils personnalisent aujourd’hui leur flux de travail avec les grands modèles.
Ensuite, il y a la compréhension du comportement réel du code dans l’environnement de production. C’est un autre front avancé sur lequel les grands modèles concentrent actuellement leurs efforts. Fable a déjà réalisé des progrès significatifs dans ce domaine, mais le chemin reste long : par exemple, comprendre en profondeur ce qui se produit réellement une fois le code déployé. Le système peut planter, des pannes imprévues et bizarres peuvent survenir — en toute honnêteté, entre 2012 et 2016, j’ai passé une grande partie de ma vie à gérer ces incidents en production et à faire évoluer l’architecture pour la rendre évolutive. Face aux urgences en production, le rôle des ingénieurs seniors demeure irremplaçable : leur expérience accumulée dans la gestion d’incidents leur permet de garder un sang-froid absolu, de collecter exhaustivement les journaux, d’appliquer des mesures d’urgence, puis de concevoir des solutions correctives durables.
Enfin, je tiens à souligner un point crucial : le rôle des « prototypes d’ingénierie » a complètement changé aujourd’hui.
Vous devez définir avec une extrême clarté si ce que vous avez entre les mains est un simple prototype (Demo) ou un code destiné à la production. Autrefois, dans la Silicon Valley, on disait souvent « le code tranche les débats » (Code wins arguments). Personnellement, j’ai toujours été plutôt sceptique face à cette formule, car elle sous-entend que celui qui sait coder détient le pouvoir décisionnel. Or, aujourd’hui, l’évolution prend une tournure fascinante : parfois, lorsqu’un désaccord persiste sur la direction d’un produit, c’est un chef de produit (PM), qui ne code pas, qui arrive en disant : « J’ai juste fait moi-même une démonstration, certes rugueuse sur huit détails — mais regardez, cette voie est assurément praticable ! » Cela ouvre instantanément un dialogue hautement qualifié, d’un tout autre niveau.
En y regardant de plus près, presque toutes nos postures de R&D actuelles sont méconnaissables comparées à celles d’il y a six mois. Le trait le plus marquant est une parallélisation extrême du développement, ainsi qu’une nécessité absolue pour les équipes de procéder à des abstractions de haut niveau de leur flux de travail.
Mais une chose est restée inchangée depuis le début : la « propriété » et la « responsabilité » humaines vis-à-vis du produit.
Mécanismes de vérification
Dan Shipper : Fable est aussi coûteux. Lors de mes tests, j’ai l’impression d’être un enfant entré dans une boutique de bonbons, criant d’excitation : « Je veux celui-ci, celui-ci, et encore celui-ci ! » Mais au moment de payer, je tremble chaque fois avant d’appuyer sur Entrée : « Cette action ne va-t-elle pas me coûter 100 dollars, voire bien plus ? » Je pense que ce prix élevé crée une barrière invisible, déterminant « qui peut l’utiliser » et « à quoi on peut l’utiliser ». Que penses-tu de son rapport qualité-prix commercial ?
Mike Krieger :
Dans le domaine professionnel de l’ingénierie logicielle, ce calcul est en fait très clair. Concernant la tarification, de nombreux facteurs internes sont pris en compte. Il est effectivement bien plus cher qu’Opus, mais si vous évaluez le volume de travail impressionnant qu’il livre à chaque requête, il apparaît, dans de nombreux cas commerciaux, incroyablement bon marché — voire gratuit — bien que chacun ait sa propre échelle économique.
Depuis la perspective d’une équipe logicielle, si la première étape consiste à faire accepter la programmation IA par les employés — le modèle est encore immature, les outils insuffisants ; la deuxième étape consiste à instaurer des classements pour voir qui l’utilise le plus, ce qui crée des mécanismes d’incitation peu optimaux ; alors la troisième étape consiste à identifier qui l’utilise le plus efficacement, à lui permettre d’en faire un usage maximal, tout en disposant d’un processus clair pour éviter les gaspillages.
Le modèle Fable correspond parfaitement à la logique de cette troisième étape. Si vous produisez régulièrement des résultats solides et créez réellement de la valeur tangible dans votre activité, une dynamique budgétaire positive s’instaure naturellement au sein de l’entreprise pour vous soutenir sans limite.
Pour l’usage personnel, je teste moi-même le service avec ma propre carte bancaire. Dans ce cas, vous devenez effectivement plus radin et plus prudent. Mais curieusement, le traceur de médias que j’ai réalisé ce week-end n’a coûté qu’un peu plus que d’habitude — pour un projet personnel, il n’est absolument pas question de dépenser des milliers de dollars.
Ce qui est réellement freiné par le prix, ce sont les passionnés open source ou les développeurs indépendants (Indie Hackers), qui ne bénéficient pas de la protection d’une grande entreprise et sont extrêmement sensibles au coût. Mon conseil pour eux est : lancez-vous, testez-le, et voyez combien il peut livrer d’un seul coup, sans subir d’interminables allers-retours.
Le « coût » s’est aujourd’hui transformé en un concept multidimensionnel — il ne s’agit plus seulement du coût d’une seule requête, mais bien du coût global pour mener une tâche à son terme. Ce qui m’a le plus impressionné chez Fable est précisément ce dernier aspect : il tend systématiquement à accomplir la tâche correctement du premier coup, sans que je doive m’asseoir devant mon ordinateur pour lutter avec lui pendant huit ou neuf itérations, en criant désespérément : « Non ! Ce n’est pas ce que je voulais ! »
Dan Shipper : Ce qui m’a le plus impressionné, c’est que lorsque vous lui confiez une tâche ambitieuse, il vous la rend avec une attention minutieuse à chaque détail, une finesse étouffante que je n’ai jamais ressentie avec aucun autre modèle. Pouvez-vous nous révéler un peu les secrets de sa formation ? Quelle alimentation a permis de développer une telle capacité d’analyse ?
Mike Krieger :
Sur de nombreux plans, il s’agit de la continuation d’un travail colossal mené par l’équipe — je ne peux qu’exprimer mon plus profond respect pour nos équipes de pré-entraînement et de RL (Reinforcement Learning). Pour moi, l’évolution la plus flagrante est une « perception globale du système », et non seulement une perception de la tâche en cours.
Je suis souvent sidéré par certaines de ses actions divines. Par exemple, après avoir rédigé un morceau de code, il peut soudain afficher spontanément : « Patron, je sais que, dans un environnement de production réel, la configuration ici pourrait être différente. Votre interrupteur de fonctionnalité est-il bien activé ? Si non, ce que je viens d’écrire ne sera pas effectif à la mise en production. »
Ou encore, observez sa réaction aux commentaires de revue de code — qu’ils proviennent d’un humain ou d’un autre Claude — il ne se contente pas de dire simplement : « Oh oui, c’est un problème, je vais le corriger. » Il réfléchit réellement à savoir s’il faut accepter un risque à ce niveau de fidélité, ou même contester un autre relecteur — souvent un autre modèle Fable — en disant : « Je comprends votre point de vue, mais je dois le contester, car je pense que vous avez tort. »
Doter le modèle de ce type de jugement est extrêmement important. Si je devais pointer son progrès le plus marquant, ce serait précisément qu’il ne réagisse pas immédiatement, par réflexe conditionné, en disant « Oui, oui, je vais corriger ». Il agit plutôt comme s’il disait : « Laissez-moi y réfléchir. Je ne suis toujours pas d’accord. » Cette capacité est très utile.
Le fait d’avoir un produit comme Claude Code sur le marché est extrêmement précieux, car il offre une matière concrète : les gens peuvent dire « Voici ce que le modèle fait bien, voici ce qu’il fait mal ». Nous plaçons les partenaires d’Every très haut dans notre liste de sources de feedback les plus fiables et prioritaires, car ils soumettent le modèle à des tâches intensives sur plusieurs jours, ce qui est essentiel pour nous aider à réfléchir à ce qu’il faut améliorer dans la prochaine génération.
Dan Shipper : Le chat est-il l’interface d’interaction la plus adaptée à ce modèle ? Ce n’est pas un échange tour à tour, mais plutôt une délégation de tâche à une personne. Comment cela influence-t-il la façon dont vous l’utilisez, ou la façon dont vous percevez cette interface ?
Mike Krieger :
Le modèle fondamental d’envoi et de réception de messages n’est pas totalement faux, mais nous devons évoluer dans certaines directions.
Premièrement : votre ordinateur portable est-il l’endroit approprié ? C’est là que j’ai mentionné précédemment à quel point l’application mobile est pratique pour les projets personnels. Les créateurs de Claude Code sont toujours en avance d’une demi-longueur sur la façon dont ces modèles sont utilisés : il y a environ neuf mois, je parlais avec lui, et il m’a dit : « J’ai déplacé la majeure partie de mon travail Claude Code sur mobile. » À l’époque, j’étais sceptique, mais surtout avec Fable, car il peut maintenir la conversation active et nous disposons, chez Anthropic, de machines de développement à distance, donc le premier point est : dissocier l’endroit où le travail se produit de l’endroit où vous discutez du travail.
Le deuxième point reprend ce que j’ai dit précédemment : comment rendre compréhensible tout ce que Fable a discuté, décidé et suggéré ? C’est un domaine sur lequel nous réfléchissons activement. Certains « skills » lui permettent de dessiner des diagrammes, mais l’interface de chat actuelle n’est pas suffisante : Fable vous fournit parfois des textes extrêmement longs, et vous devez sortir faire une promenade pour être prêt à les assimiler. J’ai commencé à expérimenter ceci : « Vous possédez bien plus de contexte que moi sur cette question. Ne pourrions-nous pas revenir en arrière — et procéder à une révélation progressive de la complexité ? »
Le troisième point concerne le mode multijoueur, sur lequel nous sommes encore en phase d’exploration préliminaire. Dans une certaine mesure, notre structure DRI et de zones de propriété signifie qu’une tâche importante circule généralement entre une seule personne et plusieurs instances Claude. Mais dans certains cas, ce n’est pas aussi évident — par exemple, lors d’une gestion d’incident, plusieurs personnes réfléchissent simultanément ; ou encore, dans des projets où plusieurs domaines spécialisés se croisent. Le partage de chat résout une partie du problème, mais je pense qu’à l’avenir, une demande émergera : vous avez une instance Claude indépendante, lancée par une personne et ayant accompli beaucoup de travail, mais peut-elle rester synchronisée avec tous les autres travaux en cours au sein de l’équipe ? C’est le prochain domaine fascinant, encore largement inexploité. Ce qui est excitant, c’est que les modèles ont désormais la capacité de devenir de véritables coéquipiers, et c’est presque notre incapacité à concevoir les bonnes abstractions qui les freine.
Dan Shipper : Cela me fait penser que j’utilise principalement ce modèle pour mes projets personnels de « vibe coding », mais lorsqu’on l’utilise dans une organisation, un problème se pose : je comprends réellement toutes les parties que le modèle vient de réaliser ? Comment transférer le contexte de ce que le modèle vient de faire dans mon propre esprit ? C’est un goulot d’étranglement majeur. Comment définir la ligne qui délimite « combien dois-je réellement savoir ? », et comment garantir que j’ai suffisamment de contexte pour me sentir en sécurité ?
Mike Krieger :
Deux grandes parties. La première est la vérification. Au début de cette année, j’ai été totalement convaincu par la vérification, ce qui rejoint une expérience de mon époque de développeur à plein temps : trouver la boucle de développement la plus serrée autour de votre idée. À l’époque d’Instagram, cela signifiait parfois créer une nouvelle cible de build dans Xcode, contenant uniquement cet écran et des données synthétiques, pour itérer uniquement sur cette boucle. J’aidais les nouveaux ingénieurs en leur disant : « Si je ne pouvais enseigner qu’une seule chose, ce serait de créer cette boucle pour votre projet — cela accélérerait considérablement le processus. »
Aujourd’hui, la situation est la suivante : chaque fois que je construis quelque chose, je m’assure que chaque PR générée par Claude soit accompagnée d’une photo ou d’une vidéo — que ce soit pour une PR iOS ou pour une modification au niveau de l’interface utilisateur. Cela renforce considérablement ma confiance. Fable peut travailler plusieurs heures en arrière-plan, puis revenir vous dire : « J’ai terminé », et vous voyez « Voici la galerie complète des captures d’écran de l’interface utilisateur », ce qui est extrêmement utile. Vous dites alors : « Dans la huitième capture d’écran, cet état d’erreur — je ne l’ai jamais vu, mais je peux clairement imaginer ce qui arriverait à l’utilisateur s’il le rencontrait. Modifions cela. » La vérification exhaustive est une pratique que nous menons activement en interne.
Deuxièmement : vous restez finalement responsable de votre travail. Beaucoup de gens utilisent quotidiennement Claude, mais ils conservent une responsabilité totale — « Claude a peut-être écrit le code, mais vous devez comprendre quelles décisions globales ont été prises. » Je vois de nombreux ingénieurs adopter une pratique : dès que Claude termine une tâche, ils engagent immédiatement une conversation suivante — « Puis-je m’assurer de comprendre parfaitement tous les choix que tu as faits ? » Quel que soit l’artefact produit, aussi petit soit-il, s’il facilite la compréhension, il vaut la peine d’être réalisé.
Les réunions sont très intéressantes — quelqu’un dira : « Cette PR est prête », une autre personne demandera : « As-tu choisi X ou Y ? », et il y aura un instant de silence : « Honnêtement, je ne suis pas sûr — je vais vérifier avant la fusion. » S’adapter à cette nouvelle normalité, comprendre comment collaborer avec ce modèle, est une compétence que chacun doit apprendre.
Dan Shipper : Ce « cycle de vérification » que tu viens d’évoquer est plein de potentiel. Outre les captures d’écran automatisées et le partage d’écran, quels autres axes plus avancés explorez-vous ?
Mike Krieger :
Notre point d’entrée central est le suivant : pouvez-vous faire exécuter au modèle des flux réels, plutôt que de lui injecter uniquement des données statiques ? À mesure que les systèmes deviennent plus complexes, cela devient de plus en plus difficile. Par exemple, nous devons faire en sorte que l’application iOS créée par Fable puisse se connecter d’un seul clic à notre environnement de simulation, en utilisant des comptes de test réels et des flux de données réalistes à haute fidélité. Mais en même temps, nous ne voulons pas qu’il doive, à chaque fois qu’il ajuste un simple bouton, passer par les huit étapes fastidieuses de l’inscription d’un nouvel utilisateur. Nous avons donc développé spécifiquement pour l’IA un système spécial de privilèges élevés et de clés de partage chiffrées, permettant à l’IA de franchir directement les étapes préliminaires et d’accéder immédiatement au cœur du terrain opérationnel, afin que son expérience de test corresponde presque pixel par pixel à celle d’un utilisateur réel.
Le deuxième axe est la combinaison entre les chemins connus et les chemins de modification actuels — ce dernier étant très précieux pour les tests de régression. Nous avons déjà exprimé certains workflows idéaux sous forme textuelle, et Claude peut les vérifier de façon répétée. De plus, Claude exprime très bien l’intention derrière la modification qu’il est en train d’apporter, ce qui permet une pratique approfondie. La combinaison de ces deux éléments est cruciale.
La vérification visuelle est également essentielle, et la vidéo est un outil extrêmement sous-exploité pour Claude. Récemment, j’ai réalisé un prototype : je fournis à Claude une vidéo de l’élément qu’il a créé, en combinaison avec FFmpeg, et je le regarde analyser chaque image individuellement, puis dire : « Cette animation présente des saccades ; je vais la corriger. » Une capture d’écran ne pourrait jamais révéler cela, car elle manquerait précisément ce moment fugace.
Pour les parties difficiles à tester de bout en bout, faire en sorte que Claude construise un backend simulé fiable, ou utiliser un backend existant, est également très intéressant. À l’ère des artefacts, nous avions déjà des tests très complets à l’époque pré-LLM. Chaque infrastructure disposait d’une implémentation en mémoire très robuste, pouvant être exécutée rapidement dans les tests unitaires. Aujourd’hui, nous étendons cette pratique au domaine de Claude : je développe un élément avec un backend très solide, mais difficile à lancer sur mon serveur de développement — il crée immédiatement un excellent substitut. Au fil du temps, ce substitut évolue en parallèle avec le code lui-même. Autrefois, j’aurais dit : « La synchronisation serait trop laborieuse. » Aujourd’hui, je pense simplement : « Claude lira les modifications, adaptera le substitut, et maintiendra la synchronisation des deux parties. C’est tout. »
Dan Shipper : Certaines architectures très intéressantes émergent : lorsqu’un bug est signalé, un agent le corrige automatiquement, puis envoie un message à l’utilisateur pour l’informer que la correction est effectuée. As-tu remarqué des changements dans ce type de flux avec Fable ?
Mike Krieger :
Plusieurs aspects. Au niveau humain-Claude, une chose que je vois fréquemment est la suivante : lorsqu’un bug est signalé dans notre canal de feedback Slack, ce fil de discussion est directement injecté dans une session Claude Code. Grâce à Slack MCP, il peut réellement récupérer ce fil de discussion, puis poster une réponse en mon nom : « Ceci est le Claude de Mike, j’ai corrigé le bug, voici le lien vers la PR. » Mais ensuite, il ajoute : « Attendez — ce n’est pas encore déployé. Je vous notifierai à nouveau une fois le déploiement effectué. » Quelques heures plus tard : « Ce déploiement est maintenant en production. Veuillez tester si la correction fonctionne. » Ce suivi bouclé est relativement nouveau. J’ai plusieurs sessions Claude Code en cours depuis longtemps qui interagissent en mon nom. J’y ai également inclus quelques clauses de non-responsabilité.
Le deuxième axe renvoie à ce goût et ce jugement dont nous parlions plus tôt. Un niveau est « un bug est signalé, donc je dois le corriger », un autre niveau est le « bon jugement ». Ce week-end, j’ai rencontré une situation : nous avions un système interne qui tournait depuis longtemps sans redémarrage, et une fuite de mémoire est apparue. Le bon jugement était : « Mike, c’est le week-end. Redémarrez simplement le serveur — cela résoudra immédiatement le problème, et j’ouvrirai une PR asynchrone pour une correction durable. » Si vous souhaitez que Claude intervienne dans ce flux de correction de bug, vous espérez réellement qu’il comprenne ce que tout bon SRE ou ingénieur comprendrait : résoudre le problème immédiat, et décider éventuellement d’une refonte de plateforme est une autre question. Comprendre cet équilibre est crucial.
Que devrait-on construire avec ce modèle ?
Dan Shipper : Ce qui rend cette nouvelle génération de modèles si passionnante, c’est qu’ils ne se contentent pas de relever le plancher — permettant à n’importe quel profane de créer instantanément son propre application — mais qu’ils font aussi sauter le plafond des experts. Si vous êtes aujourd’hui un ingénieur professionnel ou le fondateur d’une startup, vous êtes tout à fait capable, seul, de réaliser des projets techniques d’une complexité inimaginable auparavant. Selon toi, quels sont les domaines de pointe que beaucoup n’ont pas encore pleinement intégrés, mais qu’ils pourraient pourtant aborder sans hésitation avec cette génération de modèles ?
Mike Krieger :
Quelques idées, que nous pourrions commencer par celles qui sont amusantes. Les gens ont toujours des idées créatives sur la façon d’exprimer la complexité de leur univers ; chaque domaine possède quelque chose que vous maîtrisez particulièrement bien, et il y a toujours une version de la question : “Comment l’expliquer à autrui ? Puis-je appliquer des techniques issues d’un autre domaine à mon propre domaine ?” Prenons l’exemple de ma femme : elle s’attaque actuellement, de façon transversale, à l’ingénierie environnementale — en se concentrant sur l’énergie géothermique — un domaine parsemé de modèles mathématiques complexes et de simulations de mécanique des fluides qui donnent le tournis. Mais avec la mise à niveau générationnelle de Fable, elle a réussi à intégrer parfaitement des technologies extrêmement avancées, totalement étrangères à son domaine d’expertise, dans ses propres travaux de recherche. Aujourd’hui, elle peut même demander à Fable de lui construire un système de simulation d’apprentissage profond end-to-end complet, basé sur PyTorch — ce qui, pour une chercheuse non informaticienne, était autrefois tout à fait impensable.
Le deuxième axe est sa capacité à combiner des logiciels pour résoudre des problèmes extrêmement spécifiques à vous-même. Une grande partie de notre travail interne consiste à rendre MCP autant de nos systèmes internes que possible, en combinant la bonne structure de permissions et les bons paramètres de déploiement. Des plateformes PaaS externes très performantes existent également, et vous pouvez simplement demander à Claude, qui vous les configure. Mais ce que j’apprécie particulièrement, c’est ce sentiment de « créer quelque chose que vous avez toujours voulu ».
Une autre chose m’a récemment profondément impressionné. L’un de nos collègues de l’équipe commerciale, qui n’a pas de formation technique, a intégré Claude de façon profonde dans chaque capillaire de son flux de travail quotidien. Ce qui est encore plus impressionnant, c’est qu’elle ne s’est pas arrêtée après la version V1 — elle utilise cet outil en continu, en collaboration étroite avec le grand modèle, depuis plusieurs mois, avec une intensité constante.
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 les générations précédentes, les projets étaient confrontés à un « plafond de complexité ». Dès que le code métier ou la logique atteignaient un certain volume, les grands modèles commençaient à « regarder devant sans regarder derrière », et toute tentative d’ajouter une nouvelle fonctionnalité déclenchait des erreurs massives, détruisant littéralement l’architecture existante.
Aujourd’hui, cette collègue non technicienne, assistée d’un modèle de niveau Fable, fait évoluer son système en arrière-plan depuis plusieurs mois. Vous pouvez clairement voir ce logiciel croître comme un organisme vivant, nourri constamment par l’IA, s’adaptant, évoluant, se transformant de façon spectaculaire. Aujourd’hui, elle commence même à déployer l’intégralité de ce système extrêmement vaste et complexe, qu’elle a construit elle-même, à l’ensemble du département commercial de notre entreprise.
Une personne totalement dépourvue de formation en programmation peut aujourd’hui, seule, pousser la complexité d’un logiciel à long terme à une hauteur étouffante — c’est un miracle sans précédent dans l’histoire de la technologie humaine.
Flux de travail dynamique
Dan Shipper : Tu as mentionné un autre outil extrêmement puissant : le flux de travail dynamique. Pourrais-tu l’expliquer plus en détail ?
Mike Krieger :
Nous modifions fréquemment en interne ce type d’outils de pointe, puis je harcèle sans relâche les ingénieurs qui les ont créés dans mon bureau : « Quand ce truc sera-t-il enfin publié publiquement ? » Parfois, c’est effectivement une contrainte technique fondamentale qui impose une utilisation interne exclusive, mais nous faisons tout notre possible pour mettre ces pépites sur le marché le plus rapidement possible. Pour moi, le flux de travail dynamique est vraiment un produit susceptible de marquer le monde.
Fable et les modèles similaires sont particulièrement puissants pour deux grandes raisons. La première est sa capacité à vous fournir des structures de support pour des travaux profonds et significatifs. L’une des choses les plus folles que j’ai réalisées avec lui consiste à lui confier directement un projet Python interne assez complexe, et à lui demander de refactoriser entièrement l’ensemble de la logique métier en TypeScript — nous avions alors une contrainte de déploiement en production très précise.
À l’époque d’Instagram, la direction avait sérieusement envisagé la question suivante : « Devrions-nous réécrire entièrement la couche fondamentale d’Instagram en langage Hack, afin de l’intégrer sans heurt dans l’infrastructure de Facebook ? » Notre conclusion avait été : absolument pas — cela n’aurait jamais été réalisable dans la pratique.
Mais le week-end dernier, face à une base de code centrale tout aussi complexe et enchevêtrée, j’ai simplement envoyé en arrière-plan un flux de travail dynamique, puis je suis parti profiter de mon week-end. J’ai défini ce flux de travail comme suit : approfondir la compréhension du code existant, générer une documentation très similaire à une spécification expliquant le fonctionnement de chaque élément, puis traduire module par module, tester de façon incrémentale, effectuer des vérifications adversariales, et vérifier les éléments manquants. Lundi, lorsque je suis revenu à mon ordinateur, un miracle s’était produit — il s’agissait désormais d’un système entièrement nouveau, fonctionnant sur TypeScript et la chaîne d’outils de développement Bun, et sur certains plans architecturaux, il était même plus élégant et plus rapide que ma version originale en Python.
La deuxième raison, encore plus séduisante à long terme, est la suivante : à mesure que le flux de travail dynamique se généralisera, nous pourrons, dans un avenir proche, distribuer sans heurt des sous-tâches de différentes difficultés à des modèles de complexité correspondante.
Dan Shipper : Pour ceux qui ne l’ont jamais utilisé, pourriez-vous nous expliquer comment vous avez conçu ce flux de travail ? Comment l’avez-vous conçu ? Comment vous assurez-vous qu’il est bon ?
Mike Krieger :
Le processus d’ajustement est en réalité rempli d’un plaisir itératif très geek. J’ai commencé simplement en ouvrant Claude Code et en lui disant : « Frère, j’ai une tâche de refactorisation extrêmement complexe entre les mains — allons-y, concevons ensemble un flux de travail entièrement automatisé. »
Il m’a présenté un plan, et j’ai répondu : « C’est très proche, mais j’ai besoin de trois ou quatre niveaux de vérification supplémentaires pour détecter les fonctionnalités manquantes. » Il a alors 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, car vous pouvez voir exactement ce qu’il s’apprête à faire.
Après le transfert complet, j’ai eu quelques petits ajustements à effectuer, que j’ai traités comme des mini-flux de travail, construits sur la base de la sortie du flux précédent. Cela ramène à la question : le chat est-il l’interface appropriée ? Le flux de travail représente un bon compromis intermédiaire : vous l’orchestrez via le chat, mais il est exprimé en code, puis exécuté dans une interface utilisateur claire, où chaque étape est explicitement visualisée. Je pense que nous allons progressivement adopter ce type d’approche pour relier les tâches à long terme au chat.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
深潮TechFlow
