Unknowns as the Agentic Bottleneck

Sources#

• A Field Guide to Fable: Finding Your Unknowns

Summary#

Thariq Shihipar's July 2026 field guide names a bottleneck that is neither model capability nor verification: the human's ability to articulate what they never wrote down. The frame is Korzybski's — the map is not the territory. The map is your prompts, skills, and context: what you hand Claude. The territory is where the work actually happens: the codebase, the real world, its actual constraints. The difference between them is what Thariq calls unknowns, and every unknown the agent hits is a place it must guess at what you wanted.

The load-bearing claim, and the reason the page exists (practitioner-opinion — one expert's experience, not measurement):

"Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns."

That is a bottleneck relocation. Earlier models were limited by what they could do; Fable-class models are limited by what you managed to tell them. The corollary Thariq draws: reducing and planning for your unknowns is the skill of agentic coding — and, crucially, "this is a skill you can improve at, by working with Claude."

The four quadrants#

Thariq breaks a problem down the Rumsfeld way, and the interesting cells are the bottom two:

Quadrant	What it is	Where it bites
Known knowns	"Essentially what is in my prompt." What you told the agent you want.	Nowhere — this is the map you already drew.
Known unknowns	What you haven't figured out but know you haven't.	Cheap to fix: ask, research, decide.
Unknown knowns	"What's so obvious I'd never write it down, but would recognize it if I saw it."	The expensive one. You can't prompt what you don't know you believe.
Unknown unknowns	What you haven't considered at all. "Do I know how good something can be?"	You don't know what questions to ask, what good looks like, or which potholes exist.

Unknown knowns are the same object Andrew Ng calls the human's "context advantage" — knowledge the human holds and the model doesn't, invisible precisely because it's obvious to its holder. Ng names the asymmetry; Thariq supplies the extraction protocol. The two sources are a week apart and don't cite each other.

You fail both ways#

The reason unknowns can't be solved by "just prompt harder" is that specificity has failure modes in both directions:

• Too specific → "Claude will follow your instructions even when a pivot may be more appropriate."
• Too vague → "Claude will often make choices and assumptions based on industry best practices that may not be a fit for your task."

"When you don't account for your unknowns you fail both ways. You don't know when the path will be filled with obstacles and you don't know when the path will be clear, but you still want Claude to veer."

This sharpens the constraint-plus-latitude prompting move from the same author ("provide enough constraint to get what you want, but leave room for the model to surprise you"). The reason you can't pick a fixed point on the constraint dial is that the right amount of constraint is a function of where your unknowns are, which is exactly the thing you don't know yet.

Why planning is not enough#

The wiki's existing planning discipline — grill first, then plan — assumes unknowns can be drained before implementation begins. Thariq says they can't:

"Just planning ahead isn't always enough. You can find unknowns deep in implementation, or your unknowns may point you to the fact that you should actually be solving the problem in a different way altogether."

So discovery is not a phase; it's a property of the whole run. He splits the techniques into before, during, and after — and the during/after halves are what most planning-centric workflows lack. This is a real refinement of Planning / Execution Division of Labor: the human's ~70% ownership of planning decisions doesn't help if a third of the decisions only become visible mid-execution.

The elicitation catalog#

Thariq: "I don't use every technique each time." Each is "a cheap way to find out what you didn't know before it gets expensive to fix." Notably, almost all of them produce an HTML artifact rather than a chat reply — see HTML as the New Markdown.

Pre-implementation#

• Blind spot pass — targets unknown unknowns. Ask Claude, using the literal words "blindspot pass" and "unknown unknowns," to find and explain what you don't know you don't know. Give it your starting point: who you are, what you already know, how much experience you have with this codebase. "I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blindspot pass to help me figure out my relevant unknown unknowns and help me prompt you better."
• Brainstorms and prototypes — targets unknown knowns, the I-know-it-when-I-see-it criteria. Verbalize them early: "finding them out during implementation can be (relatively) expensive… small changes in a feature or spec can cause drastically different implementations in code." He starts almost every session here, to set scope with intent — "brainstorming prevents me from setting too narrow or too wide a scope." Ask for several wildly different directions and react to them. (This is Prototype Over PRD deployed as an elicitation instrument rather than as a spec.)
• Interviews — the residual after brainstorming. "Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture." The prioritization clause is the whole trick: rank questions by decision-flipping power, not by order of appearance. This is Design Concept Grilling compressed to one sentence.
• References — for what you can't describe, point rather than describe. "While you can include diagrams, documentation or pictures, the absolute best reference is source code" — even in a different language. "This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client." Thariq notes this is how Claude Design works: you point it at a module on a website you like and it reads the underlying code, "not just the screenshot," giving it markup, structure, and construction rather than appearance.
• Implementation plans, ordered by likelihood of change — the plan's job is to surface what you'll want to alter, so lead with it. "Write an implementation plan in HTML, but lead with the decisions I'm most likely to tweak: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom, I trust you on that part." Sorting a plan by revisability rather than by execution order is a small idea with a large payoff: the human's scarce attention lands on the reversible-only-now decisions.

During implementation#

• implementation-notes.md — a temporary file the agent maintains, logging the decisions it made and, specifically, a Deviations section for edge cases that forced it off the plan. "If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going." Two things at once: the agent doesn't block on you, and the deviations become the input to the next attempt. This is the context-file pattern pointed backwards — not intent written down for the agent, but the agent's discoveries written down for you, so the next run doesn't re-derive them (intent debt paid down in-flight).

Post-implementation#

• Pitches and explainers — package prototype + spec + implementation notes into one artifact for buy-in. It works because "reviewers start with the same unknowns you did", and because experts approve faster when they can see you already accounted for the failure points they'd have raised.
• The quiz gate — see below.

The quiz gate#

The sharpest practice in the piece, and the wiki's first concrete mechanism for a failure the corpus keeps naming without an answer:

"Asking Claude to quiz me about the change after giving me a bunch of context helps me understand what happens. I only merge after I pass the quiz perfectly."

The stated reason is that reading diffs under-informs: "much of the behavior will depend on existing code paths," so the diff shows what changed and hides what it means. The quiz inverts the direction of review. Ordinary review verifies the agent's work; the quiz verifies the human — and it makes the merge gate contingent on human comprehension rather than on human approval.

That is a direct, testable answer to a problem stated three ways across the wiki and solved in none of them: "you can outsource your thinking but not your understanding" gives the principle but no check; Osmani's comprehension debt names the accumulating deficit; oversight fatigue names the rubber-stamping it produces. A quiz you can fail is an instrument that detects all three. It is also, notably, self-administered — nothing stops you from merging anyway, so it measures comprehension only for someone who wanted it measured.

Worked example: the Fable launch video#

The launch video for Fable was edited entirely by Claude Code, in a domain Thariq says he is "by no means an expert" in. The sequence is the catalog run end to end:

1. Start from the known known — Claude can edit and transcribe video via code.
2. Convert a known unknown into a known known — "was it accurate enough?" → ask Claude to explain how Whisper-style transcription works and whether ums and pauses can be cut with ffmpeg.
3. Prototype past an unknown unknown — unsure whether word-timed UI was possible at all → build a throwaway Remotion prototype from a transcription to find out.
4. Recognize an unknown unknown as one — the video looked muted; he knew this was "color grading" and tried asking for variations to pick from, then realized he didn't know what good looked like, so no amount of variation would help. He stopped generating and asked Claude to teach him color grading first.

Step 4 is the guide's thesis in miniature: generating more options cannot resolve an unknown unknown, because you can't grade the options. The move is to leave the loop and acquire the missing criterion.

Who has few unknowns#

"The best agentic coders have relatively few unknowns. Watching someone like Boris or Jarred [Sumner] prompt, it is obvious to me that they know what they want in-detail. They are deeply in-sync with both the codebase and the model behaviors. But they also assume unknowns."

Two claims worth separating. The first — expertise is fewer unknowns — is a mechanism for Anthropic's measured finding that domain understanding, not coding skill, predicts who succeeds with an agent: the expert's map already matches the territory. The second is subtler: experts don't merely have fewer unknowns, they assume unknowns and plan for them. Fluency is knowing where your map is blank, not believing it's complete.

Connections#

• Context Advantage, Not Taste — the same object named from the other end: Thariq's unknown knowns are Ng's context advantage; this page is the elicitation protocol for it
• HTML as the New Markdown — same author; the medium nearly every technique here outputs to ("in almost all of these cases, a HTML artifact is the best way to visualize and represent it")
• Outsource Your Thinking, Not Your Understanding — the quiz gate is a runnable check for the thesis; understanding made a merge precondition rather than an aspiration
• Design Concept Grilling — "interview me one question at a time, prioritize questions where my answer would change the architecture" is grill-me in one sentence; this page's contribution is that grilling alone is insufficient, since unknowns surface during and after implementation too
• Prototype Over PRD — prototypes as elicitation instruments (surface unknown knowns) rather than as the spec itself; a third use for the same artifact
• Agent Context Files — implementation-notes.md is the pattern inverted: the agent's in-flight discoveries written down for the human, with a Deviations log
• Planning / Execution Division of Labor — the refinement: front-loaded planning can't drain unknowns that only appear deep in implementation
• Returns to Expertise in Agentic Coding — "the best agentic coders have relatively few unknowns" is a mechanism for the measured expertise premium
• Agentic Technical Debt — deviations logged in-flight are intent debt paid down before it compounds into the next session's re-derivation
• AI Brain Fry — the quiz gate as a countermeasure to approval-without-comprehension
• Loop Engineering — comprehension debt is what the quiz gate measures; a loop that ships code you can't be quizzed on is the cognitive-surrender failure
• Compute Allocator — Thariq's other framing: if 99% of generated tokens are scaffolding, most of that scaffolding is unknown-elicitation
• Verification as the New Bottleneck — the bottleneck one step upstream: verification asks "is this right?", unknowns ask "did I ever say what right was?"
• Research Taste as the Human Bottleneck — if the human residue is context rather than taste, elicitation (not cultivation) is the response; this page is the protocol that framing implies
• The Three Loops of AI-Native Building — vision→spec lossiness is this problem stated as a loop: Andrew Ng's developer-feedback loop is where unknowns surface after implementation, exactly as Thariq claims planning cannot prevent
• Task-Specification Effects in Prompt Injection (AutoDojo) — under-specification cuts both ways: the "action-open / defer to whatever the content says" task shape Thariq treats as a quality liability (Claude guesses at unknowns) is a measured security liability too — AutoDojo shows action-open tasks are markedly more injectable, because the injection can pose as the very content the under-specified request told the agent to act on
• Thariq Shihipar — author
• Claude Fable 5 — the model whose capability makes the human the binding constraint
• Claude Design — the reference technique productized: point it at a component and it reads the code, not the screenshot

Open questions#

• Is "the first model bottlenecked by my unknowns" a property of Fable or of Thariq? A frontier-lab engineer with deep model fluency hits the human-side ceiling before an average user does — which would make this a leading indicator rather than a current universal.
• The quiz gate is self-administered and self-graded (by the model, on the model's own work). What stops a comfortable equilibrium where the quiz gets easier as the reviewer gets lazier? Cf. the maker/checker problem in Verification as the New Bottleneck.
• Elicitation has a cost. Every technique here spends a session's worth of tokens and attention on not building. Nothing in the source bounds when the blindspot pass costs more than the bug it prevents.
• If unknown knowns are extractable, are they extractable once? Does a codified blindspot pass become a skill file that permanently narrows the gap, or does each new territory reopen it?

Sources#

• A Field Guide to Fable: Finding Your Unknowns — Thariq Shihipar (@trq212), published 2026-07-04 (practitioner-opinion). Example artifacts at thariqs.github.io/html-effectiveness/unknowns/; the 2×2 and phase diagrams are images hosted on X and not transcribed.