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.