Unknown unknown. That's exactly what landed on Thariq Shihipar, an engineer on Anthropic's Claude Code team, the week he sat down to edit the Fable 5 launch video with... Claude Code.
He picked the tool he knew better than almost anyone else on the planet, on a project he understood from the inside. Maximum context, if there ever was one.
He still got blindsided. The transcription drifted. The timing of the cuts didn't match the rhythm of the footage. The color grading was something he couldn't even judge by eye (he had to stop and ask Claude to teach him what good grading looked like before he could evaluate the options it handed him).
Random tangent: I still haven't fully forgiven the 18 days Fable 5 spent offline this year over an export control dispute, back online July 1st. Had 3 client deadlines that week and ended up routing everything through Opus instead. Nothing to do with blind spots, I just find it funny that a frontier model can vanish over a trade dispute the same way a graphics card shortage takes out your GPU order.
If the guy with the most context possible on this exact project still walks into his own blind spots, "I know my stack" was never going to save you either.
The Belief That Doesn't Survive The Data
The smarter the model gets, the less you should need to spell out. That's the assumption baked into a lot of agentic coding advice right now. It'll figure out what you meant.
It's the opposite. And the numbers back it up without needing an opinion attached.
A weak model fails loud and local. You see the problem on the first try, it breaks in an obvious way, you patch it and move on. A model like Fable 5 takes your instruction at face value and runs with it all the way to the end, confidently, even when that instruction was hiding a gap you didn't know was there. The better the model gets, the more an unstated assumption costs you. Not less.
Shihipar's own breakdown borrows Donald Rumsfeld's 4 boxes. Known knowns are what's already spelled out in your prompt, and known unknowns are the gaps you're aware of but haven't answered yet. The dangerous pair is the other 2: unknown knowns, the assumptions so obvious to you that you'd never think to write them down (house style, taste, the "obviously we don't touch that table"), and unknown unknowns, the stuff you never considered in the first place. Fable 5's quality ceiling sits almost entirely in those last 2 boxes, the ones you can't see from the inside because you're the one standing in them.
Anthropic's own research makes the point without editorializing. An internal analysis of roughly 400,000 Claude Code sessions found that in a typical session, humans keep about 70% of planning decisions while Claude handles about 80% of execution decisions. Humans still own the thinking. The model just runs with it further and faster than it used to.
Shihipar isn't the only data point here. 2 of his colleagues sit at the other end of the spectrum: Boris Cherny, who heads Claude Code at Anthropic, and Jarred Sumner, who built the Bun JavaScript runtime. Neither of them carries many unknowns into a session, not because they're smarter, but because they know their codebases cold, know the model's tendencies, and write specifications precise enough that Fable 5 has nowhere left to guess. If they're the min-maxed builds, most of us are still figuring out our skill tree. Planning ahead alone doesn't get you there either. Unknowns show up mid-implementation just as often as they show up in the brief, sometimes signaling that the whole approach needs to change, not just the wording.
None of this means write a longer prompt. Shihipar warns against the opposite mistake too: over-specify and you lock the model into a bad approach it has no room to reroute from. A separate piece on the AI coding productivity panic makes almost the same point from a different angle, blaming the tools for a slowdown while diagnosing the wrong disease instead of the actual bottleneck. The lever isn't word count. It's the number of blind spots you're carrying into the session before you hit enter.
1 Million Tokens Hides A Bad Assumption
In a short interactive session, a bad assumption breaks fast. You prompt, Claude answers, you notice it went sideways within a couple of exchanges, you correct it. The loop is tight enough that unstated gaps get caught early, almost by accident.
Fable 5 changes the shape of that loop. It runs with a 1 million token context window, which is exactly what makes long autonomous sessions possible in the first place (dozens of steps without you checking in on any of them).
An unstated assumption planted at the start of one of those sessions doesn't break immediately. It propagates: 10 steps in, everything still looks fine, and 20 steps in it's still fine too, because the model keeps building faithfully on the wrong premise, and faithful execution looks exactly like progress until it doesn't. By the time the gap between your mental map and the actual codebase becomes visible, you're not looking at a small fix anymore. You're looking at unwinding a chain of decisions that each made sense locally and none of which made sense once you stepped back and looked at the whole thing.
Longer sessions don't shrink the blind spot, they just lengthen the fuse.
What A Blind Spot Looks Like In Practice
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.
That's close to the exact line Shihipar uses before touching a part of a codebase he doesn't know well. He calls it a blindspot pass: ask the model to scan your own prompt and flag what's ambiguous or undefined before it writes a single line. It's the move that shifts a question from the unknown unknowns box straight into the known unknowns box, where you can actually do something about it.
This is what "more direction" means in practice. Not a longer prompt written by a human trying to anticipate everything in advance. An extra pass where the model tells you what it doesn't know yet, before implementation starts. Skip it on unfamiliar ground and you get the coding equivalent of "YOU DIED" with no boss name attached: something failed, and you're not sure which of your assumptions is the one that killed you.
The blindspot pass isn't the only move in the kit. For the areas thick with unknown knowns (taste calls, visual design, the stuff you'd recognize as wrong but can't specify in advance), Shihipar leans on brainstorming instead. He has Fable 5 generate a handful of radically different directions as throwaway prototypes before he writes the real prompt, then reacts to what's in front of him rather than trying to describe a preference he hasn't actually formed yet.
It's the same sequence he used on the launch video itself, without realizing he was naming a pattern: spot the unknown unknown (I can't judge this color grade), turn it into a known unknown (what does good grading even look like), get it to a known known (ask Claude to teach him first), then proceed.
It doesn't close the gap completely. Spotting a blind spot is still a judgment call a human has to make in the moment, not a button that solves the problem once and for all.
My Own Framework Has The Same Gap
I built the full prompt contracts framework after enough of these disasters to stop trusting my own vibes on a spec. It works. It catches known unknowns, the stuff you're aware you haven't decided yet, and it forces known knowns into writing instead of leaving them in your head where Claude can't reach them.
I didn't see the gap until Shihipar's thread sent me back to look at my own work. A prompt contract covers what's known and stated, and what's known to be missing. It doesn't natively reach the 2 boxes that actually break a model as capable as Fable 5: what you know but never wrote down because it felt too obvious to mention, and what you never considered in the first place. Those are exactly the 2 zones where a capable model fails quietly instead of loudly, which is the whole problem this article has been circling.
Maybe I'm being generous to my own work here, but I don't think this breaks the framework. It's a blind spot on a tool that still earns its keep everywhere else. If you're far enough into agentic coding to be running prompt contracts already, this is the layer to bolt on top: a pass that hunts specifically for the things you didn't think to write down. The whole framework, quadrants and all, is laid out in more depth in Prompt Contracts, my second book on the subject.
The natural instinct is to assume the next model finally fixes this. Smarter, fewer gaps to catch after the fact, the problem quietly shrinks with every release.
It's the opposite at every step up in capability. Fable 5 doesn't shrink the list of things you didn't say, it just executes that list more faithfully, all the way to the end, without stopping to ask if you were sure. The next model will do the same, HAL 9000 style: still calm, still polite, still not stopping to check, just with a longer runway before anyone notices.
The bottleneck already left the model. It's sitting on your side of the keyboard, before you've typed the first line of the prompt.
Sources
Thariq Shihipar's original field guide ran as a thread on X in early July 2026. The Decoder covered the blindspot pass technique and the launch video story in detail, and TechTimes covered the 400,000 session data and where the bottleneck sits now.
This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).
Top comments (0)