# thariq-field-guide-fable-finding-unknowns-2026-07-03

## Veille

X thread (illustrated thread) by **Thariq Shihipar** (Claude Code team / Anthropic): a *field guide* to getting the most out of **Claude Fable 5**. Central thesis borrowed from Korzybski — *"the map is not the territory"*: the **map** = what you give Claude (prompts, skills, context); the **territory** = where the work happens (codebase, real-world constraints); the gap between the two = the **unknowns**. Fable is *"the first model where the quality of the work is bottlenecked by my ability to clarify its unknowns"*. The article provides a **4-quadrant framework** (known knowns / known unknowns / unknown knowns / unknown unknowns) and a **toolkit of techniques** ordered in time (before / during / after implementation) — blindspot pass, brainstorms & prototypes, interviews, references, implementation plan, implementation-notes, pitches & explainers, quizzes — each with example prompts. Domain: prompt engineering, coding agents, methodology for working with AI, HTML artifacts.

## Titre Article

A Field Guide to Fable: Finding Your Unknowns

## Date

2026-07-03

## URL

https://x.com/trq212/status/2073100352921215386

## Keywords

Unknowns, map vs territory, known/unknown knowns, unknown unknowns, blindspot pass, brainstorm, prototype, interview, references, implementation plan, implementation-notes.md, pitches and explainers, quizzes, HTML artifacts, Claude Fable 5, Claude Design, thought partner, prompt engineering, long-horizon tasks, iterative discovery of unknowns

## Authors

Thariq Shihipar (@trq212)

## Ton

**Profile**: field guide in the first person, reflective and pedagogical practitioner register, published as a long-form illustrated X thread with 4 diagrams. Medium-to-high technical level, addressed to daily users of coding agents.

**Style**: an essay built around a **cartographic extended metaphor** borrowed from general semantics ("the map is not the territory") and carried through to the punchline ("Matching the Map and Territory"). Explicit temporal structure (before / during / after implementation) paired with a conceptual framework borrowed from Rumsfeld/Johari (the 2×2 known/unknown matrix). Authority through **embodied self-demonstration**: Thariq recounts how he edited the **Fable launch video** entirely with Claude Code despite knowing nothing about the domain (Whisper transcription, ffmpeg editing, word-timed UI via Remotion, *color grading* he had Claude *teach* him). Each technique comes with copy-pasteable **example prompts** — this is an operational guide, not a theory. Doctrine one-liners: *"reducing and planning for your unknowns is THE skill of agentic coding"*, *"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"*, *"I only merge after I pass the quiz perfectly"*, *"what you learn becomes the map for next time"*. **Target audience**: engineers and makers working with Claude, including outside their area of expertise.

## Pense-betes

- **Framing metaphor: the map is not the territory.** The **map** = what you give Claude (prompts, skills, context). The **territory** = where the work happens (codebase, real world, constraints). The gap between the two = the **unknowns**. Faced with an unknown, Claude *decides based on its best guess of what you want* → the larger the work, the more unknowns it encounters.
- **The Fable plateau.** *"Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns"* — the bottleneck has shifted from the model to **human clarity**. Planning ahead isn't enough: unknowns surface mid-implementation, or reveal that the problem needed to be solved **differently**. → an **iterative** process: discovering your unknowns **before, during, and after**.
- **The 4 quadrants (unknowns matrix)**: **Known knowns** = what's in the prompt (what you say you want); **Known unknowns** = what you haven't resolved yet but are aware of; **Unknown knowns** = *"too obvious to write down, but I'd recognize it"* (the "I'll know it when I see it"); **Unknown unknowns** = *"the pothole you didn't know the road could have"*.
- **The real skill**: *"reducing and planning for your unknowns is THE skill of agentic coding"*. The best (cites **Boris**, **Jarred**) have **few unknowns** (in sync with both the codebase AND the model's behaviors) but **assume** some remain. Good news: it's a skill that **improves by working with Claude**.
- **Instructing Claude is a delicate balance.** Too precise → Claude follows the instructions even when a **pivot** would be better. Too vague → Claude fills in with *industry best practices*, not necessarily suited to the case. Without managing your unknowns, **you fail on both sides**. Remedy: give Claude **context on your starting point** (where you are in your thinking, your experience with the problem) and treat it as a **thought partner**. Claude searches the codebase and the web very fast and iterates from failure faster than we do.
- **BEFORE — Blindspot pass**: when working in unfamiliar territory (unknown unknowns), ask Claude to **find and explain its blind spots**. Use the literal words *"blindspot pass"* and *"unknown unknowns"* plus context on who you are. E.g. *"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"*.
- **BEFORE — Brainstorms & prototypes**: for **unknown knowns** (criteria you can only define by seeing them, e.g. visual design). Verbalize them **early**, since discovering them during implementation is costly (a small spec change can mean radically different code, hard to revert). Start **almost every session** with an exploration/brainstorm phase to frame the scope (neither too narrow nor too broad). E.g. *"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"*.
- **BEFORE — Interviews**: after brainstorming, ask Claude to **interview us** on the remaining ambiguities, **one question at a time**, prioritizing *"questions where my answer would change the architecture"*.
- **BEFORE — References**: when you can't describe what you want, **the best reference is source code**. Point Fable to a folder/library (even in another language) and say what to look for there. **Claude Design** works this way: pointed at a site's module, it **reads the underlying code** (markup, structure, actual construction), not just the screenshot. E.g. *"this Rust crate implements the exact backoff I want — reimplement the same semantics in our TypeScript client"*.
- **BEFORE — Implementation plan**: ask for a plan **led by the decisions most likely to change** (data models, type interfaces, UX flows) and **relegating mechanical refactoring to the bottom** (*"I trust you on that part"*). The plan **surfaces** what you'll actually need to alter.
- **DURING — Implementation notes**: however much planning is done, **unknown unknowns remain** (the agent finds an edge case while coding). Have Claude Code keep a temporary **`implementation-notes.md`** logging decisions *"so we can learn from our next attempt"*. E.g. *"if you hit an edge case that forces a deviation, pick the conservative option, log it under 'Deviations', and keep going"*.
- **AFTER — Pitches & explainers**: *shipping* means getting **buy-in and approvals**. Package prototype + spec + notes into **a single doc** that *"lead[s] with the demo GIF"* → speeds up understanding (reviewers **start from the same unknowns as you**) and approvals (experts want to see their failure points were covered).
- **AFTER — Quizzes**: after a long session, reading the diffs only gives a **superficial** understanding (behavior depends on existing code paths). Ask Claude for an **HTML report + a quiz** on the changes — *"I only merge after I pass the quiz perfectly"*.
- **Proof by example: the Fable launch video**, edited **entirely with Claude Code** in a domain Thariq didn't master — he starts from what he knows (Claude can edit/transcribe video through code), has Whisper/ffmpeg **explained**, **prototypes** a word-timed UI via Remotion, then has Claude **teach him color grading** (having no idea what "good" means) instead of blindly generating variants.
- **Punchline**: *"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"*. The residue of learning becomes the map for next time ("what you learn becomes the map for next time").
- **Links**: converges with the *Compounding Knowledge Lifecycle* (capitalizing on what's learned), *loop engineering*, and the note **[[willison-fable-judgement-delegation-subagents-2026-07-03]]** (same author cited, Thariq, same moment on Fable) — two complementary facets: Willison on **letting Fable judge**, Thariq on **reducing your own unknowns to better guide it**.

## RésuméDe400mots

In this *field guide* published on July 3, 2026, **Thariq Shihipar** (Claude Code team) formalizes a practice for getting the most out of **Claude Fable 5**. Starting point, borrowed from Korzybski: *"the map is not the territory"*. The **map** is what you give Claude — prompts, skills, context. The **territory** is where the work happens — the codebase, the real world, its constraints. The gap between the two, he calls the **unknowns**: when Claude hits one, it decides based on its best guess of what you want. The larger the scope of the work, the more unknowns it encounters. Fable is *"the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns"* — the bottleneck has shifted from the model to human clarity.

Thariq proposes a **2×2 matrix**: *known knowns* (what's in the prompt), *known unknowns* (what you know you don't know), *unknown knowns* (the obvious thing you don't write down but would recognize) and *unknown unknowns* (what you never considered). Reducing and anticipating your unknowns is, in his view, **THE skill** of agentic coding — and it's learned by working with Claude. Instructing remains a balancing act: too precise, and Claude follows along even when a pivot would be better; too vague, and it fills the gaps with ill-fitting *best practices*.

What follows is a **toolkit** ordered in time, each technique delivered with prompts. **Before**: the *blindspot pass* (getting your blind spots made explicit), *brainstorms & prototypes* (verbalizing *unknown knowns* early, e.g. 4 design directions in HTML), *interviews* (Claude questions you one question at a time, prioritizing what changes the architecture), *references* (the best one being source code — that's how **Claude Design** works), and the *implementation plan* led by what's likely to change. **During**: an `implementation-notes.md` where the agent logs its deviations. **After**: *pitches & explainers* (a single doc led by the demo, since reviewers start from the same unknowns) and *quizzes* ("I only merge after I pass the quiz perfectly").

Supporting evidence: the **Fable launch video**, edited entirely with Claude Code in a domain unfamiliar to the author, going as far as having the model *teach* him color grading. Moral: every artifact is a cheap way to find out what you didn't know **before it becomes expensive to fix**. *"Start your next project by asking Claude to help you find your unknowns."*

## GrapheDeConnaissance

- Thariq Shihipar —travaille_chez→ équipe Claude Code (Anthropic) (ORGANISATION, 0.95)
- Thariq Shihipar —affirme_que→ "Fable est le premier modèle où la qualité du travail est plafonnée par ma capacité à clarifier ses inconnues" (AFFIRMATION, 0.95)
- Finding Your Unknowns —s_applique_à→ Claude Fable 5 (TECHNOLOGIE, 0.95)
- Finding Your Unknowns —est_basé_sur→ "la carte n'est pas le territoire" (AFFIRMATION, 0.93)
- Matrice des inconnues —fait_partie_de→ Finding Your Unknowns (METHODOLOGIE, 0.9)
- Thariq Shihipar —affirme_que→ "reducing and planning for your unknowns is THE skill of agentic coding" (CITATION, 0.94)
- Blindspot pass —permet→ Unknowns (CONCEPT, 0.9)
- Brainstorms & prototypes —permet→ verbaliser tôt les unknown knowns (moins cher qu'en implémentation) (CONCEPT, 0.9)
- References —résout→ l'incapacité à décrire ce qu'on veut en détail (CONCEPT, 0.9)
- Claude Design —utilise→ lecture du code sous-jacent d'un module (pas seulement la capture) (CONCEPT, 0.88)
- implementation-notes.md —permet→ journaliser les déviations pendant l'implémentation (CONCEPT, 0.9)
- Quizzes —améliore→ la compréhension réelle d'un changement avant le merge (CONCEPT, 0.9)
- Pitches & explainers —permet→ obtenir buy-in et approbations (reviewers partant des mêmes inconnues) (CONCEPT, 0.88)
- Claude Code —a_créé→ vidéo de lancement de Fable (DOCUMENT, 0.9)
- Instruction de Claude —affirme_que→ trop spécifique empêche le pivot, trop vague invoque des best practices inadaptées (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/en/fiches/thariq-field-guide-fable-finding-unknowns-2026-07-03/