Guide de terrain Fable : trouver mes inconnues

• L’essentiel du travail avec Claude Fable 5 consiste à repérer et réduire l’écart entre la carte (map : prompts, skills, contexte) fournie par l’utilisateur et le territoire (territory : base de code, réalité, contraintes) où le travail se déroule réellement, c’est-à-dire les inconnues (unknowns)
• Fable est le premier modèle dont la qualité du travail dépend de la capacité de l’utilisateur à clarifier les inconnues ; plus la quantité de travail augmente, plus les inconnues rencontrées augmentent aussi
• Les inconnues se répartissent en quatre catégories : Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns ; les réduire et s’y préparer est une compétence clé du codage agentique
• Avant, pendant et après l’implémentation, on découvre les inconnues avec des techniques itératives comme le blindspot pass, le brainstorming, les entretiens, les références, les plans d’implémentation, les notes d’implémentation et les quiz
• Explications, brainstorming, entretiens, prototypes et références sont des moyens de découvrir les inconnues à faible coût avant que le problème ne devienne coûteux ; il est important de démarrer le prochain projet en demandant à Claude de chercher les inconnues

---

La carte, le territoire et les inconnues (Unknowns)

• La carte est la représentation de la tâche à accomplir : prompts, skills, contexte, autrement dit ce que l’on donne à Claude ; le territoire est l’endroit où le travail se déroule réellement : base de code, réalité, contraintes concrètes
• La différence entre la carte et le territoire correspond aux inconnues (unknowns) ; lorsque Claude se heurte à une inconnue, il doit prendre une décision en faisant sa meilleure supposition sur ce que l’utilisateur veut
• Fable est le premier modèle dont la qualité du travail est limitée par la capacité à clarifier les inconnues
• La planification en amont ne suffit pas : les inconnues se découvrent parfois au cœur de l’implémentation, ou indiquent qu’il faut résoudre le problème d’une manière entièrement différente
• Travailler avec Fable est un processus itératif de découverte des inconnues avant, pendant et après l’implémentation
• Quelques exemples de ressources utiles pour trouver les inconnues à consulter plus tard

Connaître ses inconnues (Knowing your unknowns)

• Décomposer le problème en quatre catégories
  • Known Knowns : ce qui figure dans le prompt, ce que l’on dit à l’agent que l’on veut
  • Known Unknowns : ce que l’on n’a pas encore compris, mais dont on sait que l’on ne l’a pas compris
  • Unknown Knowns : ce qui semble si évident qu’on ne l’écrit pas, mais que l’on reconnaît quand on le voit
  • Unknown Unknowns : ce que l’on n’a pas du tout envisagé, les connaissances dont on n’a pas conscience, ce dont on ignore à quel point cela pourrait être meilleur
• Les excellents codeurs agentiques ont relativement peu d’inconnues : ils sont profondément synchronisés (in-sync) avec la base de code et le comportement du modèle, et savent en détail ce qu’ils veulent
• Réduire les inconnues et s’y préparer est une compétence que l’on peut améliorer en travaillant avec Claude

Aider Claude à vous aider (Help Claude help you)

• Les instructions demandent un équilibre : si elles sont trop précises, Claude les suivra même quand il vaudrait mieux changer de direction ; si elles sont trop vagues, il fera des choix fondés sur des bonnes pratiques du secteur (best practices) qui ne conviennent pas forcément à la tâche
• Sans prise en compte des inconnues, on échoue des deux côtés : on veut que Claude change de cap sans savoir quand une voie est bloquée ni quand elle s’ouvre
• Claude accélère la découverte des inconnues, car il peut rechercher rapidement dans la base de code et sur Internet, en sait davantage sur les sujets moyens, et itère rapidement à partir des échecs
• Le plus important est de fournir le contexte du point de départ : indiquer où l’on en est dans sa réflexion, son expérience du problème et de la base de code, et collaborer comme avec un partenaire de réflexion
• J’ai déjà écrit sur l’utilisation de HTML avec Claude ; dans la plupart des cas, les artefacts HTML sont optimaux pour la visualisation et la représentation

Avant l’implémentation (Pre-implementation)

• Blind Spot Pass

  • Dans les tâches peu familières, comme écrire une fonctionnalité dans une nouvelle zone ou itérer sur un design, il y a beaucoup d’unknown unknowns : on peut ne pas savoir quelles questions poser, ce qui est bon, ce qui a été fait par le passé, ni quels pièges éviter
  • Il faut demander à Claude de trouver et d’expliquer les unknown unknowns ; il est important d’utiliser explicitement les expressions « blindspot pass » et « unknown unknowns », et de fournir le contexte sur qui l’on est et ce que l’on sait
  • Exemples de prompts
    • « Je travaille à l’ajout d’un nouveau fournisseur d’authentification, mais je ne connais pas du tout le module d’authentification de cette base de code. Fais un blindspot pass pour identifier les unknown unknowns pertinents et m’aider à mieux prompter. »
    • « Je ne sais pas ce qu’est le color grading, mais je dois étalonner cette vidéo. Apprends-moi à comprendre les unknown unknowns du color grading afin que je puisse mieux prompter. »

• Brainstorming et prototypes (Brainstorms and prototypes)

  • Dans les domaines où les unknown knowns sont nombreux, c’est-à-dire lorsqu’il existe beaucoup de critères que l’on reconnaît en les voyant mais qu’il est difficile de définir à l’avance, il faut brainstormer et prototyper avec Claude
  • Il est utile d’identifier et de formuler les unknown knowns tôt dans le prototypage, plutôt qu’en cours d’implémentation, car une petite modification de la spécification peut changer fortement l’implémentation du code et rendre difficile le retour en arrière
    • Exemple : lorsque l’on veut seulement voir à quoi ressemblerait l’ajout d’un bouton dans un cadre, sans route backend ni état frontend
  • Le design visuel est un domaine difficile à exprimer clairement, mais où l’on sait ce que l’on veut quand on le voit ; il faut demander plusieurs approches de design
  • Commencer presque chaque session de code par une phase d’exploration et de brainstorming permet de définir le périmètre avec intention et évite qu’il devienne trop étroit ou trop large
  • Exemples de prompts
    • « Je veux un dashboard pour ces données, mais je n’ai pas de sens visuel et je ne sais pas ce qui est possible. Crée une page HTML avec quatre directions de design complètement différentes pour que je puisse réagir. »
    • « Avant le travail de connexion, crée un fichier HTML unique qui maquette la nouvelle toolbar de l’éditeur avec de fausses données. Je veux réagir au layout avant de toucher à la vraie application. »
    • « Le problème approximatif est l’attrition des utilisateurs après l’onboarding. Parcours la base de code et brainstorme 10 points d’intervention possibles, du moins coûteux au plus ambitieux. »

• Entretiens (Interviews)

  • S’il reste des inconnues après suffisamment de brainstorming, demander à Claude de mener un entretien sur les inconnues et les ambiguïtés, en fournissant le contexte du problème pour orienter ses questions
  • Exemple de prompt
    • « Pose-moi les questions ambiguës une par une, et donne la priorité à celles dont la réponse changerait l’architecture. »

• Références (References)

  • Lorsqu’on ne peut pas décrire en détail ce que l’on veut, la meilleure réponse est une référence ; il peut s’agir de diagrammes, de documents ou de dessins, mais le code source est de loin la meilleure référence
  • Si une bibliothèque implémentée d’une certaine façon, ou un composant de design que l’on apprécie, existe, il faut pointer vers le dossier et demander de l’examiner, même s’il est dans un autre langage
  • Claude Design fonctionne de la même manière : si l’on pointe vers un module d’un site web que l’on aime, il lit le code sous-jacent plutôt qu’une capture d’écran, fournissant des informations riches sur le markup, la structure et la façon réelle dont c’est implémenté
  • Exemple de prompt
    • « Ce crate Rust dans vendor/rate-limiter implémente exactement le comportement de backoff que je veux. Lis-le et réimplémente la même sémantique dans notre client API TypeScript. »

• Plans d’implémentation (Implementation Plans)

  • Lorsque l’on est prêt à implémenter, demander un plan d’implémentation à relire qui se concentre sur les parties les plus susceptibles de changer (modèle de données, interfaces de types, flux UX), afin de faire émerger les points à corriger
  • Exemple de prompt
    • « Rédige le plan d’implémentation en HTML, en mettant en premier les décisions que je serai le plus susceptible de modifier (changements du modèle de données, nouvelles interfaces de types, éléments visibles par l’utilisateur), et relègue les refactorings mécaniques tout en bas. »

Pendant l’implémentation (During implementation)

• Notes d’implémentation (Implementation notes)

  • Une fois satisfait du plan, créer une nouvelle session et transmettre au prompt les artefacts comme le fichier de spécification ou le prototype, puis demander à l’agent d’implémenter
  • Quelle que soit la planification, les unknown unknowns restent toujours tapis ; un cas limite découvert par l’agent pendant le travail peut imposer une autre approche
  • Demander à Claude Code de consigner les décisions prises dans un fichier temporaire implementation-notes.md (ou .html) afin d’apprendre lors de la tentative suivante
  • Exemple de prompt
    • « Maintiens un fichier implementation-notes.md. Si tu rencontres un cas limite qui t’oblige à t’écarter du plan, fais un choix conservateur, consigne-le dans ‘Deviations’, puis continue. »

Après l’implémentation (Post implementation)

• Pitches et documents explicatifs (Pitches and explainers)

  • L’un des éléments les plus importants pour lancer quelque chose est d’obtenir l’accord et l’approbation ; créer des artefacts de pitch et d’explication dans la documentation finale aide beaucoup
    • Lorsque les reviewers partent des mêmes inconnues que vous, cela accélère la compréhension
    • Lorsque des experts veulent vérifier que vous avez pris en compte les inconnues et les points d’échec fréquents, cela accélère l’approbation
  • Exemple de prompt
    • « Regroupe le prototype, la spécification et les notes d’implémentation en un document unique à poster sur Slack pour obtenir l’accord. Mets le GIF de démo en premier. »

• Quiz (Quizzes)

  • Après une longue session de travail, Claude a peut-être accompli plus que prévu ; un simple diff de code ne donne qu’une compréhension superficielle des comportements qui dépendent des chemins de code existants
  • Après avoir donné le contexte, demander à Claude de vous interroger sur les changements afin de vérifier votre compréhension, et ne merger qu’après avoir réussi le quiz parfaitement
  • Exemple de prompt
    • « Je veux comprendre tout ce qui s’est passé dans ce changement. Produis un rapport HTML avec le contexte, les intuitions et ce qui a été fait, puis ajoute en bas un quiz que je dois absolument réussir. »

Comment tout cela s’articule avec le lancement de Fable (How this comes together)

• La vidéo de lancement de Fable a été entièrement montée avec Claude Code, alors que c’était un nouveau domaine et pas une expertise de départ
• En partant de ce qui était connu, je savais que Claude pouvait éditer et transcrire de la vidéo avec du code, mais je n’étais pas sûr de la précision ; j’ai donc demandé une explication du principe de transcription à la manière de Whisper et de la capacité de ffmpeg à couper précisément les « ums » et les longs silences
• Je voulais une UI où les mots prononcés et le timing correspondent, mais je n’étais pas sûr que ce soit possible ; j’ai donc créé une vidéo prototype avec Remotion et la transcription pour valider
• Je savais que l’aspect un peu muted de la vidéo venait du color grading, mais je ne savais pas ce que c’était ; au lieu de choisir parmi des variantes, j’ai demandé qu’on m’apprenne le color grading afin de découvrir les inconnues

Faire correspondre la carte et le territoire (Matching the Map and Territory)

• Plus les modèles s’améliorent, plus on peut accomplir de choses avec la bonne approche ; lorsqu’une tâche longue revient mal, c’est généralement qu’il fallait passer plus de temps à définir les inconnues ou à élaborer un plan d’implémentation permettant à Claude d’improviser
• Toutes les explications, brainstormings, entretiens, prototypes et références sont des moyens de découvrir les inconnues à faible coût avant que le problème ne devienne coûteux
• L’essentiel est de commencer le prochain projet en demandant à Claude de chercher les inconnues