A field guide to Claude Fable 5: Finding your unknowns | Claude | Claude by Anthropic
Thariq Shihipar from Anthropic's Claude Code team argues that with Fable 5, the bottleneck has shifted from model capability to the human's ability to clarify unknowns before, during, and after implementation. He frames this as the difference between the map (your prompt, skills, context) and the territory (the actual codebase and constraints). The core insight: working with a more capable model requires systematic discovery of what you don't know — known unknowns, unknown knowns, and unknown unknowns — using concrete techniques like blind spot passes, brainstorming, interviews, implementation notes, and post-ship quizzes.
Transcript
Talon Okay, so this Anthropic post by Thariq Shihipar landed this week and it's everywhere — two million views in three days. The claim is straightforward but I think it's the most important thing anyone's written about Fable 5.
Wildflower Which is?
Talon <cite index="1-16">Claude Fable is the first model where the quality of the work is bottlenecked by your ability to clarify its unknowns.</cite> Not the model. You.
Wildflower Yeah, okay.
Talon <cite index="1-13,1-14">He calls the difference between the map and the territory 'unknowns' — your prompts and context are the map, the actual codebase is the territory, and when Claude runs into an unknown it has to guess what you want.</cite> The bigger the task, the more guesses it makes.
Wildflower So the model got too good and now the human is the bottleneck.
Talon Exactly. And here's the thing — <cite index="1-17,1-18,1-19">planning ahead isn't always enough. You can find unknowns deep in implementation, or your unknowns may point you to solving the problem a completely different way. Working with Fable is iterative discovery before, during, and after implementation.</cite>
Wildflower That tracks. So how does he say you actually find them?
Talon He breaks unknowns into four boxes. <cite index="1-22,1-23,1-24">Known knowns — what's in your prompt. Known unknowns — what you haven't figured out but you know you haven't.</cite> Then unknown knowns and unknown unknowns.
Wildflower Mm-hm.
Talon Unknown knowns are the things so obvious you'd never write them down. Unknown unknowns are the blind spots — constraints, edge cases, decisions you haven't even considered. And his argument is: the bigger the project, the more you're living in the last two.
Wildflower Right. So the technique is naming them before they blow up.
Talon Exactly. And he's got eight concrete moves. Pre-implementation, there's a 'blind spot pass' — <cite index="3-25,3-26">you ask Claude to identify your unknown unknowns, which works especially well when you're working in an unfamiliar part of the codebase.</cite>
Wildflower Okay, that's practical.
Talon Then brainstorming and prototypes — <cite index="10-21,10-22">when your requirements are still fuzzy, don't ask for 'the implementation,' ask for options.</cite> Visual design, different layout approaches, cheap ways to find what you actually care about before you commit code.
Wildflower That's the move that saves money.
Talon Yeah. Then he's got interviews — <cite index="1-27">Claude asks you one question at a time about anything ambiguous, prioritizing questions where your answer would change the architecture.</cite> And references. <cite index="1-31,1-32,1-33">The best reference is source code — just point Fable at a folder and tell it what to look for, even in a different language, because source code provides much richer detail than a screenshot.</cite>
Wildflower Mm, that's honest. Code doesn't lie about structure.
Talon Right. And during implementation — <cite index="3-2,3-3">he asks Claude to keep a temporary implementation-notes file tracking decisions, and when unexpected edge cases come up, Claude picks the conservative option, logs the deviation, and keeps working.</cite>
Wildflower So you're not starting over, you're building a record.
Talon Exactly. And post-ship there's quizzes and pitches. <cite index="3-5,3-6,3-7">Pitches bundle the prototype, specs, and implementation notes for stakeholders. Quizzes are HTML reports detailing changes with context and insights, followed by a quiz — he doesn't merge until he passes it without errors.</cite>
Talon I know, it sounds like overkill until you realize it's a cheap way to catch the last unknowns.
Wildflower Wildflower perspective: this is just good harness discipline. He's naming the routine that actually closes the map-territory gap. The techniques aren't magic — they're the infrastructure moves that work when the model's strong enough to run unsupervised. You're not watching it code line-by-line anymore, so you need to front-load clarity and back-load verification.
Talon And that's the product insight I think people are missing. <cite index="10-1,10-3">As models get better at carrying long tasks, the limiting factor moves from raw model capability to how well the human can expose the real shape of the work.</cite> The human becomes the interface.
Wildflower Yeah. That's the inflection.
Talon So this is episode six-eleven, and Shihipar basically wrote the manual for what that inflection looks like in practice.