Anthropic Dev Says Fable 5's Real Bottleneck Is Your Blind Spots

I've read a lot of prompting advice this year. Most of it fits into two buckets:

1. "Be more specific" — which works until the model rigidly follows your bad instructions into a dead end.
2. "Let the model think" — which works until it confidently generates plausible-sounding decisions based on assumptions you didn't realize you were making.

Thariq Shihipar, an Anthropic developer who worked on Claude Fable 5, has a third take that cuts through both. The bottleneck is no longer the model. It's your unknown unknowns.

I talked through his recent post on The Decoder, and it's the first prompting framework I've seen that acknowledges something uncomfortable: with models this capable, you're the weak link, and the fix isn't better instructions — it's better self-awareness.

The Four Unknowns Framework

Shihipar organizes what you don't know into a tidy quadrant:

Most prompting advice targets the first two rows. "Be specific" collapses known unknowns. "Add context" surfaces unknown knowns. But the real leverage — and the place where Fable 5 breaks traditional patterns — is in the fourth quadrant.

Unknown unknowns are where projects die. You ask for an auth provider, and the model picks one. It's competent, it compiles, it passes tests. But it doesn't account for the rate limit patterns of your concurrent user base, or the integration quirks of your existing session store, because you didn't know those mattered and so you didn't ask.

Shihipar's insight is that with Fable 5, this failure mode isn't the model's fault. The model is fast enough, capable enough, and literal enough that it will drive your blind assumptions all the way to production before you notice.

The Practical Techniques

What I appreciate about Shihipar's approach is that he doesn't stop at diagnosis. He's got concrete moves for each phase of a coding session.

Phase 1: Before You Build

The Blindspot Pass. Open a session and literally ask the model to find what you're missing:

"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?"

This is deceptively simple. It flips the dynamic from "I tell the model what to do" to "the model helps me figure out what to ask." The model becomes a collaborator on your prompt, not just a consumer of it.

Structured Interviews. Have Claude ask you one question at a time about ambiguities — prioritizing questions whose answers would actually change the architecture. This is the prompt engineering equivalent of pair programming with someone who has infinite patience and no ego.

Radical Prototyping. For visual or design work (unknown knowns), have Claude generate several radically different directions as HTML artifacts so you can react to them rather than specify them. You can't describe what good looks like until you see what bad looks like.

Phase 2: During Implementation

Implementation Notes. Ask Claude Code to keep a running implementation-notes.md that logs every decision it makes. Later, you can read this file to discover what you would have gotten wrong. This turns every session into a retrospective whether you planned one or not.

Conservative Edge Cases. When unexpected edge cases arise, Claude should pick the conservative option, log the deviation, and keep moving. Speed matters less than not silently optimizing into a corner.

Phase 3: After Implementation

The Quiz. This is my favorite technique in the whole article. Shihipar doesn't merge until the model generates an HTML report detailing the changes — and he passes a quiz on it without errors. He literally tests himself on what the model did before approving it.

This flips the review process on its head. Instead of the model being the thing that needs review, you're the thing that needs to understand. The artifact is complete; your mental model is what lags. The quiz closes that gap.

The Real-World Validation

Shihipar's case study seals it for me. He used Claude Code to edit the Fable 5 launch video — a domain (video editing) he knew nothing about. Here's the sequence:

1. He knew his known unknowns (transcription accuracy, ffmpeg capabilities) and consulted an expert.
2. He prototyped with Remotion to discover what he didn't know about time-controlled UI fades.
3. He hit his real blindspot: the color grading looked flat, and he didn't know what good looked like.

His fix? Instead of making Claude iterate on color grading variations (which he couldn't evaluate), he had the model teach him the subject first. He uncovered his own unknowns before asking for output.

"If a long-running task goes sideways, you likely need to invest more time defining your own unknowns or create an implementation plan that lets Claude improvise through them."

This is the kind of hard-won wisdom that doesn't make it into model release notes.

What This Means for How We Prompt

The takeaway here is bigger than a single technique. Shihipar is describing a new meta-skill that Fable 5 demands: the ability to audit your own ignorance before committing to a direction.

With weaker models, you didn't need this. The model was the bottleneck — it would miss context, misunderstand intent, or fail to synthesize. You could iterate your way to a good outcome through sheer prompt volume.

With Fable 5 (and whatever comes next), the model will execute faithfully on whatever you give it. That's a superpower, but it means your prompt quality becomes the ceiling on output quality. And your prompt quality is bounded by how well you understand what you don't know.

This changes how I'm going to structure my sessions going forward:

• First 5 minutes: Blindspot pass. Always. Before any code is written.
• During: Implementation notes. Every decision logged.
• Before merge: The quiz. No merge until I can explain what changed and why.

The Frameworks don't change. The models don't wait. Your blind spots are the only remaining bottleneck.

---

Source: Anthropic developer shares prompting tips for Fable 5 that focus on finding your own blind spots first — The Decoder