Dès son lancement, le destin de Fable 5 a été aussi mystique que le nom du modèle.
Du moment tant attendu de l'« apothéose de l'IA » à l'arrêt forcé par un décret gouvernemental américain, puis à l'interdiction d'accès pour les non-Américains, il a attiré l'attention du monde entier.
Aujourd'hui, la tempête s'est progressivement calmée. Les modèles finissent toujours par revenir à leur rôle de productivité.
C'est pourquoi Thariq Shihipar, ingénieur Claude Code, a publié un long billet de blog sur les réseaux sociaux, détaillant les techniques d'utilisation de Fable 5.
Cet article résout un doute qui perdure depuis longtemps. Alors que les capacités des modèles actuels ont évolué à un point si puissant, pourquoi ai-je toujours l'impression qu'ils n'exécutent pas correctement les tâches lorsque je les utilise ?
Le billet de Thariq offre une révélation. En résumé : Il existe un déficit d'information entre l'humain et le modèle, c'est-à-dire l'écart entre le prompt, les compétences, le contexte fournis par l'utilisateur et l'exécution réelle de la tâche.
Ainsi, tout l'article vise à vous apprendre à surmonter ce déficit d'information. Ci-dessous, Ji Qi Zhi Xin (Machine Heart) partage l'intégralité de l'article pour ses lecteurs.
Titre de l'article : A Field Guide to Fable: Finding Your Unknowns
Lien de l'article : https://x.com/trq212/status/2073100352921215386
Travailler avec Claude Fable 5 me rappelle sans cesse un vieil adage : la carte n'est pas le territoire.
La « carte » est la représentation du travail à accomplir, c'est-à-dire mon prompt, mes compétences et mon contexte, ce que je donne à Claude. Le « territoire », c'est l'endroit où le travail doit réellement se faire : le codebase, le monde réel, et les contraintes qui y existent vraiment.
J'appelle l'écart entre la carte et le territoire les « inconnues ». Lorsque Claude rencontre une inconnue, il doit prendre une décision basée sur sa meilleure hypothèse de mon intention. Plus le travail est complexe, plus Claude risque de rencontrer d'inconnues.
Fable est le premier modèle qui m'a clairement fait ressentir que la qualité du travail dépend de ma capacité à clarifier ses inconnues.
Il est important de noter que simplement planifier à l'avance n'est pas toujours suffisant. Vous pourriez découvrir des inconnues au cœur de l'implémentation ; ou bien découvrir que ces inconnues indiquent que vous devriez en réalité aborder le problème d'une manière complètement différente.
J'ai découvert que collaborer avec Fable est, par essence, un processus itératif de découverte d'inconnues avant, pendant et après l'implémentation.
L'auteur fournit quelques exemples pour découvrir les « inconnues », que les lecteurs peuvent consulter avec l'article complet.
Lien de l'exemple : https://thariqs.github.io/html-effectiveness/unknowns/
Connaître vos inconnues
Qu'est-ce qu'une inconnue ? Lorsque j'aborde Claude avec un problème, je le décompose généralement sous quatre angles :
Les connus connus : C'est essentiellement ce que j'écris dans mon prompt. Je dis à l'agent ce que je veux.
Les connus inconnus : Quelles sont les choses que je n'ai pas encore comprises, mais dont je sais que je ne les ai pas comprises ?
Les inconnus connus : Quelles sont les choses si évidentes pour moi que je ne les écrirais même pas, mais que je reconnaîtrais une fois vues ?
Les inconnus inconnus : Quelles sont les choses auxquelles je n'ai pas du tout pensé ? Quelles connaissances est-ce que j'ignore ne pas posséder ? Est-ce que je sais à quel point quelque chose peut être bien fait ?
Les meilleurs programmeurs en mode agent ont souvent relativement moins d'inconnues. Ils savent très clairement ce qu'ils veulent, avec beaucoup de détails. Ils sont très synchronisés avec le codebase et le comportement du modèle.
Mais ils anticipent aussi l'existence d'inconnues. À bien des égards, réduire et planifier vos inconnues à l'avance est la compétence centrale de la programmation en mode agent. Heureusement, c'est une compétence qui peut être développée en collaborant avec Claude.
Aidez Claude pour vous aider vous-même
Donner des instructions à Claude est un exercice d'équilibre subtil. Si vous êtes trop précis, Claude suivra strictement vos instructions même si une autre approche serait plus appropriée. Si vous êtes trop vague, Claude fera souvent des choix et des hypothèses basés sur les meilleures pratiques du secteur, qui ne sont pas forcément adaptées à votre tâche.
Les deux échouent lorsque vous n'avez pas suffisamment réfléchi à vos inconnues. Vous ne savez pas quand la route sera semée d'obstacles, ni quand elle sera en réalité très fluide, mais vous voulez quand même que Claude puisse s'adapter si nécessaire.
Claude peut vous aider à découvrir vos inconnues plus rapidement. Il peut rechercher à une vitesse folle dans votre codebase et sur Internet, et possède plus de connaissances générales que vous sur la plupart des sujets. Il peut aussi itérer plus rapidement à partir des échecs.
L'élément le plus important dans ce processus est de donner à Claude suffisamment de contexte de départ. Par exemple, lui dire où vous en êtes dans votre réflexion ; expliquer votre niveau de familiarité avec le problème et le codebase ; lui permettre de collaborer avec vous comme un partenaire de réflexion.
J'ai déjà écrit sur la façon d'utiliser Claude pour générer du HTML. Dans presque tous ces scénarios, l'artefact HTML est le meilleur moyen de visualiser et d'exprimer des idées.
Dans cet article, je vais détailler certaines des méthodes que j'utilise pour découvrir ces inconnues. Je n'utilise pas toutes les astuces à chaque fois, mais les avoir comme un ensemble de méthodes à disposition est très utile.
Avant l'implémentation
Scan des angles morts
L'une des choses les plus utiles avant de commencer à travailler est de comprendre vos angles morts. Par exemple, si vous écrivez une fonctionnalité dans un nouveau module du codebase, ou si vous demandez à Claude de vous aider avec un type de travail que vous ne connaissez pas bien, comme itérer sur un design, vous aurez probablement beaucoup d'« inconnus inconnus ».
Vous ne savez peut-être pas quelles questions poser, ce qui est considéré comme « bien fait », quels travaux historiques ont déjà été réalisés, ou quels pièges éviter.
Pour cela, vous pouvez demander à Claude de vous aider à identifier les « inconnus inconnus » et de vous les expliquer. J'aime utiliser directement les termes « blindspot pass » et « unknown unknowns ». Il est également souvent important de lui dire qui vous êtes et ce que vous savez.
Exemple de prompt :
« J'ajoute un nouveau fournisseur d'authentification, mais je ne connais rien du module d'authentification dans ce codebase. Peux-tu faire un « blindspot pass » pour m'aider à identifier les « unknown unknowns » pertinents et m'aider à mieux te rédiger un prompt ? »
« Je ne connais rien à l'étalonnage couleur (color grading), mais j'ai besoin de le faire pour cette vidéo. Peux-tu m'apprendre à comprendre mes « unknown unknowns » en matière d'étalonnage couleur, pour que je puisse écrire de meilleurs prompts ? »
Brainstorming et prototypage
Lorsque je travaille dans un domaine avec beaucoup d'« inconnus connus », c'est-à-dire des choses dont je ne sais définir les critères qu'après les avoir vues, je demande à Claude de faire du brainstorming et du prototypage avec moi.
Il est très précieux d'identifier et d'exprimer ces « inconnus connus » tôt, au stade du prototype, car les découvrir au stade de l'implémentation a souvent un coût plus élevé. De petits changements dans la fonctionnalité ou les spécifications peuvent entraîner des différences majeures dans l'implémentation du code, et il est plus difficile de faire revenir l'agent sur des modifications antérieures.
Par exemple, vous voudrez peut-être simplement voir à quoi ressemble l'ajout d'un bouton dans un certain framework, sans vouloir réellement connecter une route backend ou maintenir un état supplémentaire en frontend.
Le design visuel est quelque chose que j'ai du mal à exprimer clairement, mais je sais ce que je veux quand je le vois. Dans ce cas, je demande à Claude de proposer plusieurs directions de design différentes pour un artefact.
Je commence aussi presque chaque session de codage par une phase d'exploration ou de brainstorming. Cela m'aide à définir le périmètre du projet avec une intention claire. Claude découvre souvent des approches à haute valeur ajoutée que j'aurais manquées, mais il lui arrive aussi de ne pas voir la forêt derrière l'arbre. Le brainstorming m'évite de commencer avec un périmètre trop étroit ou trop large.
Exemple de prompt :
« Je veux créer un tableau de bord pour cet ensemble de données, mais je n'ai aucun goût visuel et je ne sais pas ce qui est possible. Aide-moi à créer une page HTML avec 4 directions de design très différentes, afin que je puisse donner un feedback basé sur les résultats. »
« Avant de faire les connexions réelles, crée un fichier HTML séparé avec des données fictives pour simuler la nouvelle barre d'outils de l'éditeur. Je veux d'abord donner mon avis sur la mise en page, puis tu pourras modifier l'application réelle. »
« Voici mon problème général : les utilisateurs désertent après l'onboarding. Recherche dans le codebase et fais un brainstorming de 10 endroits où nous pourrions intervenir, de l'option la moins coûteuse à la plus ambitieuse. Je te dirai quelles directions me semblent meilleures. »
Questionnement inversé
Après avoir fait suffisamment de brainstorming, j'ai généralement encore des inconnues.
Dans ce cas, je demande à Claude de m'interviewer autour de tout point peu clair ou ambigu. Lorsque vous demandez à Claude de vous interviewer, fournissez suffisamment de contexte sur le problème pour qu'il puisse poser des questions plus pertinentes. Voici quelques exemples.
Exemple de prompt :
« Pose-moi une seule question à la fois, en m'interviewant sur tout point ambigu. Priorise les questions dont ma réponse changerait la conception de l'architecture. »
Références
Parfois, vous ne pouvez pas décrire en détail ce que vous voulez. Par exemple, vous n'avez peut-être pas le langage pour l'exprimer, ou c'est trop complexe et cela prendrait trop de temps de le décrire complètement.
Dans ce cas, la meilleure réponse est une référence. Vous pouvez fournir des diagrammes, de la documentation ou des images, mais la meilleure référence est généralement le code source.
Si une bibliothèque implémente une fonctionnalité d'une manière spécifique, ou si vous avez un composant de design que vous aimez beaucoup, pointez simplement Fable vers le dossier correspondant et dites-lui quoi regarder. Même si le code de référence est dans un autre langage, ce n'est pas grave.
C'est aussi ainsi que fonctionne Claude Design. Vous n'êtes pas obligé de lui donner un fichier, bien que vous puissiez le faire. Vous pouvez le pointer vers un module d'un site web que vous aimez, et il lira le code sous-jacent, pas seulement une capture d'écran. Cela fournit des détails plus riches, incluant la structure du balisage, l'organisation des composants, et comment ce composant est réellement construit.
Exemple de prompt :
« Cette crate Rust dans vendor/rate-limiter implémente exactement le comportement de retry avec backoff que je veux. Lis-la et réimplémente les mêmes sémantiques dans notre client API TypeScript. »
Plan d'implémentation
Lorsque je me sens prêt à commencer l'implémentation, je demande généralement à Claude de préparer d'abord un plan d'implémentation pour que je le révise, en me concentrant sur les parties les plus susceptibles de changer, comme le modèle de données, les interfaces de types ou les flux UX. Cela permet à Claude de révéler à l'avance des points que je pourrais effectivement devoir ajuster.
Exemple de prompt :
« Écris un plan d'implémentation en HTML, mais commence par présenter les points de décision que je suis le plus susceptible de modifier : les changements de modèle de données, les nouvelles interfaces de types, et tout contenu orienté utilisateur. Place les refactorisations mécaniques en bas, c'est une partie dont je suis sûr que tu peux t'occuper. »
Pendant l'implémentation
Notes d'implémentation
Lorsque je suis satisfait du plan, j'ouvre une nouvelle session et j'inclus les artefacts pertinents dans le prompt. Par exemple, je peux inclure un fichier de spécifications et un prototype, puis demander à l'agent de les implémenter.
Mais la réalité est que, quelle que soit votre planification, des inconnus inconnus se cachent toujours. L'agent peut découvrir en cours de travail qu'il doit changer d'approche à cause d'un cas limite dans le code.
Je demande à Claude Code de maintenir un fichier temporaire implementation-notes.md, ou un fichier .html, pour enregistrer les décisions qu'il prend, afin que nous puissions apprendre pour la prochaine tentative.
Exemple de prompt :
« Veuillez maintenir un fichier implementation-notes.md. Si vous rencontrez un cas limite qui vous oblige à dévier du plan initial, choisissez l'option la plus conservatrice, enregistrez la raison sous 'Deviations', puis continuez. »
Après l'implémentation
Documentation de présentation et d'explication
Lors de la publication de quelque chose, l'une des choses les plus importantes est d'obtenir la compréhension, le soutien et l'approbation des autres. Intégrer des artefacts de type présentation et explication dans la documentation finale aide à :
Accélérer la compréhension des relecteurs qui commencent avec les mêmes inconnues que vous.
Accélérer l'approbation lorsque des experts veulent s'assurer que vous avez pris en compte les inconnues et les points de défaillance courants qu'ils auraient anticipés.
Exemple de prompt :
« Regroupe le prototype, les spécifications et les notes d'implémentation en un seul document que je puisse partager directement sur Slack pour obtenir du soutien. Commence par un GIF de démonstration. »
Test de connaissances
Après une longue session de travail, Claude a peut-être accompli plus de travail que je ne le réalise. Ne regarder que le diff de code ne me donne souvent qu'une compréhension superficielle de ce qui s'est passé, car beaucoup de comportements dépendent des chemins de code existants.
Demander à Claude de me tester sur ces changements après m'avoir donné beaucoup de contexte m'aide à vraiment comprendre ce qui s'est passé. Je ne fusionne le code qu'après avoir parfaitement réussi le test.
Exemple de prompt :
« Je veux m'assurer de comprendre tout ce qui s'est passé dans ce changement. Donne-moi un rapport HTML pour m'aider à lire et comprendre ces modifications, incluant le contexte, des explications intuitives, ce qui a été fait concrètement, etc., et ajoute en bas un test que je dois réussir. »
Enchaîner les méthodes : l'exemple de la sortie de Fable
La vidéo de lancement de Fable a été entièrement montée par Claude Code. C'était un domaine entièrement nouveau pour moi, et je n'en suis absolument pas un expert.
J'ai donc commencé par ce que je connaissais. Je savais que Claude pouvait utiliser du code pour éditer des vidéos et faire de la transcription, mais je n'étais pas sûr que la précision serait suffisante. J'ai donc demandé à Claude de m'expliquer comment fonctionnent des technologies de transcription comme Whisper, et si je pouvais utiliser ffmpeg pour couper précisément des interjections comme « hum » ou des pauses longues.
Je voulais que Claude crée une interface utilisateur synchronisée avec les mots que je prononçais, mais je ne savais pas si c'était possible. J'ai donc demandé à Claude de créer un prototype vidéo en utilisant Remotion et le texte transcrit, pour voir si l'idée était réalisable.
Enfin, la vidéo elle-même semblait un peu terne. Je savais que c'était un problème d'étalonnage couleur (color grading), mais je ne comprenais pas vraiment ce qu'était l'étalonnage couleur. Ma première tentative a été de demander à Claude de faire plusieurs versions pour que je choisisse, mais j'ai réalisé que, en matière d'étalonnage couleur, je ne savais pas ce qui était « bien ». Au lieu de continuer à générer des versions aveuglément, j'ai demandé à Claude de m'enseigner l'étalonnage couleur, pour découvrir mes inconnues.
Faire correspondre la carte au territoire
Plus le modèle est puissant, plus vous pouvez accomplir de choses avec la bonne méthode. Lorsqu'une tâche longue retourne un résultat erroné, c'est probablement un signe que vous devez passer plus de temps à définir vos inconnues, ou à créer un plan d'implémentation permettant à Claude de s'adapter face à ces inconnues.
Chaque document d'explication, session de brainstorming, interview, prototype et référence est une méthode à faible coût pour découvrir ce que vous ne saviez pas, avant que le coût de la correction ne devienne élevé.
Alors, avant de commencer votre prochain projet, demandez d'abord à Claude de vous aider à trouver vos inconnues.
Cet article provient du compte public WeChat « 机器之心 » (Ji Qi Zhi Xin - Machine Heart), édité par la rédaction de Machine Heart.
