Claude's Fable 5 can follow complex work, but Anthropic developer Thariq Shihipar argues that the limiting factor is often not the model. It is the user's ability to surface gaps in their own thinking before and during the work.
His prompting advice is especially relevant for coding with AI agents, where a prompt can look clear at the start and still produce results that miss the real problem. The core lesson is simple: better prompting begins by finding the assumptions, ambiguities, and missing context that the user has not yet named.
Why unknowns matter in Fable 5 prompts
Shihipar describes Fable 5 as the first model where output quality is constrained by how well users clarify their “unknowns.” In his framing, the prompt is only one part of the work. The larger task is to understand what has been included, what has been left unstated, and what has not been considered at all.
He separates knowledge gaps into several categories. “Known Knowns” are the facts already placed in the prompt. “Known Unknowns” are open questions the user recognizes. “Unknown Knowns” are things the user understands so naturally that they may never think to write them down, even though they would notice if the model got them wrong.
The most important category, according to Shihipar, is “Unknown Unknowns.” These are the issues the user has not thought about yet. In an AI coding workflow, those can be the details that appear late in implementation, the architectural choices that were never discussed, or the signs that the original approach should be changed.
That is why planning alone is not enough. Shihipar says unknowns can emerge deep into implementation, and skilled agentic coders still expect them even when they begin with relatively few.
The problem with prompts that are too tight or too loose
Shihipar's advice also challenges a common assumption about prompt engineering: more detail is not always better. A highly specific prompt can cause Fable 5 to follow a weak path too rigidly, even when the better answer would be to change direction.
The opposite problem is just as real. A vague prompt leaves too many decisions to broad defaults. In that case, the model may produce something that looks reasonable in general but does not fit the specific task, codebase, or user intent.
Shihipar summarizes the tension directly: “When you don't account for your unknowns you fail both ways,” he writes. The practical answer is not simply to write longer prompts. It is to give Claude enough context about the user's starting point, including what the user knows, what they are unsure about, and how much experience they have with the problem.
Claude can help with this because it can search codebases and the internet quickly and because it knows more about many topics than the average user. But Shihipar's point is that the user must first make the uncertainty visible enough for the model to work with it.
Before building, ask Claude to expose the gaps
One of Shihipar's suggested techniques is a “blindspot pass.” Before implementation begins, the user asks Claude to identify the relevant “unknown unknowns.” He says this is especially useful when working in an unfamiliar part of a codebase.
One example prompt he gives is: “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.”
For domains where users may have many “unknown knowns,” such as visual design, Shihipar recommends brainstorming and prototyping instead of immediate implementation. He has Claude generate several radically different design directions as HTML artifacts, then reacts to those options. He says he starts almost every coding session with an exploration or brainstorming phase so the project scope becomes more deliberate.
He also recommends structured interviews. In this workflow, Claude asks questions one at a time about ambiguous parts of the task. The most valuable questions are the ones where the answer could change the architecture.
References are another important part of the process. Shihipar says source code is the best reference, even when it is written in a different programming language. He also notes that Claude Design reads a website's underlying code, not only a screenshot.
Before the actual work starts, Shihipar has Claude create an implementation plan. That plan focuses first on the pieces most likely to change, including data models, type interfaces, and user-facing parts. Mechanical refactoring comes last.
During implementation, keep track of decisions
Unknowns do not disappear once the coding starts. Shihipar warns that they can show up during implementation, so he asks Claude Code to maintain a temporary “implementation-notes.md” file. That file records decisions made during the work, which makes it easier to learn from the next attempt.
When unexpected edge cases appear, his guidance is for Claude to choose the conservative option, log the deviation, and continue. This keeps the work moving while preserving the context behind decisions that may need review later.
After implementation, Shihipar recommends two follow-up techniques. The first is “pitches and explainers,” meaning summary documents for stakeholders that bring together the prototype, specifications, and implementation notes.
The second is “quizzes.” In that approach, Claude generates an HTML report that explains the changes, adds context and insights, and then includes a quiz. Shihipar says he does not merge until he passes the quiz without any errors.
A Fable launch video as a working example
Shihipar demonstrates the method through the launch video for Fable, which he edited entirely with Claude Code. He says video editing was new territory for him, so the process began by separating what he knew from what he did not.
He knew Claude could edit and transcribe videos using code. What was uncertain was whether the accuracy would be strong enough. To reduce that uncertainty, he had someone explain how transcription works with Whisper and whether filler words and pauses could be precisely cut using ffmpeg.
For time-controlled fade-ins of UI elements, he built a prototype with Remotion. Later, when the result looked flat in color, he first tried having Claude generate multiple color-grading variations. Then he realized he did not know what “good” looked like in color grading, so he had Claude teach him the subject instead of guessing from variations.
The broader lesson is that stronger models raise the value of a disciplined process. Shihipar says that if a long-running task goes sideways, the answer may be to spend more time defining unknowns or to create an implementation plan that gives Claude room to improvise through them.
“Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn't know before it gets expensive to fix,”
For Fable 5 prompting, the practical takeaway is not a magic phrase. It is a workflow: expose blind spots early, give Claude context about your starting point, use references, preserve implementation decisions, and verify understanding before merging.