A Field Guide to Fable: Finding Your Unknowns

À retenir

1. Métaphore-cadre : la carte n'est pas le territoire. La carte = ce qu'on donne à Claude (prompts, skills, contexte). Le territoire = où le travail se fait (codebase, monde réel, contraintes). L'écart entre les deux = les unknowns. Face à une inconnue, Claude décide sur sa meilleure supposition de ce qu'on veut → plus le travail est gros, plus il rencontre d'inconnues.
2. Le plateau Fable. « Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns » — le goulot d'étranglement s'est déplacé du modèle vers la clarté de l'humain. Planifier à l'avance ne suffit pas : les inconnues surgissent en pleine implémentation, ou révèlent qu'il fallait résoudre le problème autrement. → processus itératif : découvrir ses inconnues avant, pendant et après.
3. Les 4 quadrants (matrice des inconnues). Known knowns = ce qui est dans le prompt (ce qu'on dit vouloir) ; Known unknowns = ce qu'on n'a pas encore résolu mais dont on est conscient ; Unknown knowns = « trop évident pour l'écrire, mais je le reconnaîtrais » (le « I'll know it when I see it ») ; Unknown unknowns = « le nid-de-poule dont on ignorait que la route pouvait l'avoir ».
4. La vraie compétence. « reducing and planning for your unknowns is THE skill of agentic coding ». Les meilleurs (cite Boris, Jarred) ont peu d'inconnues (en phase avec le codebase ET les comportements du modèle) mais assument qu'il en reste. Bonne nouvelle : c'est une compétence qui s'améliore en travaillant avec Claude.
5. Instruire Claude = équilibre délicat. Trop précis → Claude suit les instructions même quand un pivot serait meilleur. Trop vague → Claude comble avec les industry best practices, pas forcément adaptées. Sans gérer ses inconnues, on échoue des deux côtés. Remède : donner à Claude le contexte de son point de départ (où on en est dans sa réflexion, son expérience du problème) et le traiter en thought partner. Claude cherche codebase + web très vite et itère depuis l'échec plus vite que nous.
6. AVANT — Blindspot pass. quand on travaille dans une zone inconnue (unknown unknowns), demander à Claude de trouver et expliquer ses angles morts. Utiliser les mots littéraux « blindspot pass » et « unknown unknowns » + contexte sur qui on est. Ex. « I'm adding a new auth provider but I know nothing about the auth modules… do a blindspot pass » ; « teach me to understand my unknown unknowns about color grading so I can prompt better ».
7. AVANT — Brainstorms & prototypes. pour les unknown knowns (critères qu'on ne sait définir qu'en les voyant, ex. design visuel). Les verbaliser tôt car les découvrir en implémentation coûte cher (un petit changement de spec = code radicalement différent, dur à revert). Démarrer presque chaque session par une phase d'exploration/brainstorm pour cadrer le scope (ni trop étroit ni trop large). Ex. « make me an HTML page with 4 wildly different design directions so I can react to them » ; « mock the new toolbar in a single HTML file with fake data before you touch the real app » ; « brainstorm 10 places we could intervene, cheapest to most ambitious ».
8. AVANT — Interviews. après le brainstorm, demander à Claude de nous interviewer sur les ambiguïtés restantes, une question à la fois, en priorisant « questions where my answer would change the architecture ».
9. AVANT — References. quand on ne sait pas décrire ce qu'on veut, la meilleure référence est du code source. Pointer Fable vers un dossier/une lib (même dans un autre langage) et dire quoi y chercher. Claude Design fonctionne ainsi : pointé vers un module d'un site, il lit le code sous-jacent (markup, structure, construction réelle), pas juste la capture. Ex. « this Rust crate implements the exact backoff I want — reimplement the same semantics in our TypeScript client ».
10. AVANT — Implementation plan. demander un plan menant par les décisions les plus susceptibles de changer (modèles de données, interfaces de types, flux UX) et reléguant le refactoring mécanique en bas (« I trust you on that part »). Le plan fait remonter ce qu'on aura vraiment besoin d'altérer.
11. PENDANT — Implementation notes. quelle que soit la planification, des unknown unknowns subsistent (l'agent trouve un edge case en codant). Faire tenir à Claude Code un implementation-notes.md temporaire journalisant les décisions « so we can learn from our next attempt ». Ex. « if you hit an edge case that forces a deviation, pick the conservative option, log it under 'Deviations', and keep going ».
12. APRÈS — Pitches & explainers. shipper = obtenir buy-in et approbations. Empaqueter prototype + spec + notes en un seul doc qui « lead with the demo GIF » → accélère la compréhension (les reviewers partent des mêmes inconnues que soi) et les approbations (les experts veulent voir qu'on a couvert leurs points de défaillance).
13. APRÈS — Quizzes. après une longue session, lire les diffs ne donne qu'une compréhension superficielle (le comportement dépend de chemins de code existants). Demander à Claude un rapport HTML + un quiz sur les changements — « I only merge after I pass the quiz perfectly ».
14. Preuve par l'exemple : la vidéo de lancement de Fable. , montée entièrement avec Claude Code dans un domaine que Thariq ne maîtrisait pas — il part de ce qu'il sait (Claude sait éditer/transcrire de la vidéo par le code), fait expliquer Whisper/ffmpeg, prototype une UI timée aux mots via Remotion, puis fait enseigner le color grading par Claude (n'ayant pas d'idée de ce que « bon » veut dire) au lieu de générer des variantes à l'aveugle.
15. Chute. « every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn't know before it gets expensive to fix » → « start your next project by asking Claude to help you find your unknowns ». Le résidu d'apprentissage devient la carte de la prochaine fois (« what you learn becomes the map for next time »).
16. Liens. converge avec le Compounding Knowledge Lifecycle (capitaliser l'appris), le loop engineering et la note [[willison-fable-judgement-delegation-subagents-2026-07-03]] (même auteur cité, Thariq, même moment sur Fable) — deux facettes complémentaires : Willison sur laisser Fable juger, Thariq sur réduire ses propres inconnues pour mieux le guider.