The fate of Fable 5 has been as mystifying as its model's name since its release.
From the highly anticipated "AI's Defining Moment" to being forced offline by a U.S. government ban, and then restricting access to non-Americans, it has captivated global attention.
Now, the storm has gradually subsided. Ultimately, models must return to productivity.
To this end, Claude Code engineer Thariq Shihipar published a detailed blog post on social media, outlining techniques for using Fable 5.
This article addresses a long-standing question. With models having evolved to such powerful capabilities, why do I still feel they perform tasks incorrectly when I use them?
Thariq's blog post is an eye-opener. In short: there is an information gap between humans and models, a disparity between the prompts, Skills, and context provided by the user and the actual task execution.
Thus, the entire blog post teaches you how to bridge this information gap. Below, Machine Heart provides the full blog post for our readers.
Blog Title: A Field Guide to Fable: Finding Your Unknowns
Blog Link: https://x.com/trq212/status/2073100352921215386
Working with Claude Fable 5 constantly reminds me of an old adage: the map is not the territory.
The "map" is the representation of the work to be done—my prompts, skills, and context—what I give to Claude. The "territory" is where the work actually needs to happen: the codebase, the real world, and the real constraints within.
I call the gap between the map and the territory "unknowns." When Claude encounters an unknown, it must make a decision based on its best guess of my intent. The more complex the work, the more unknowns Claude might encounter.
Fable is the first model where I've strongly felt that the bottleneck of work quality depends on my ability to clarify its unknowns.
Importantly, mere upfront planning isn't always enough. You might discover unknowns deep in implementation; you might also find these unknowns point to the fact that you should be solving the problem in a completely different way.
I find that collaborating with Fable is essentially an iterative process of discovering unknowns before, during, and after implementation.
The author provides some examples of discovering "unknowns." Readers are encouraged to review them alongside the full article.
Example Link: https://thariqs.github.io/html-effectiveness/unknowns/
Know Your Unknowns
What are unknowns? When I approach Claude with a problem, I typically break it down from four perspectives:
Known knowns: This is basically what I write in the prompt. I tell the agent what I want.
Known unknowns: What things haven't I figured out yet, but I know I haven't figured them out?
Unknown knowns: What things are so obvious to me that I wouldn't even write them down, but I'd recognize them if I saw them?
Unknown unknowns: What things haven't I considered at all? What knowledge do I not yet know I don't know? Do I know how well something can be done?
The most skilled agent-style programmers tend to have relatively fewer unknowns. They know exactly what they want, in great detail. They are highly synchronized with both the codebase and model behavior.
But they also presuppose the existence of unknowns. In many ways, reducing and planning for your unknowns ahead of time is the core skill of agent-style programming. Fortunately, this is a skill that can be honed by collaborating with Claude.
Help Claude Help You
Giving instructions to Claude is a delicate balance. If you're too specific, Claude will follow your instructions strictly, even if pivoting to a different approach might be better. If you're too vague, Claude will often make choices and assumptions based on industry best practices, which may not be right for your task.
Both can fail when you haven't adequately considered your unknowns. You don't know when the road ahead is fraught with obstacles, nor do you know when it's actually smooth, but you still want Claude to make adjustments if necessary.
Claude can help you discover unknowns faster. It can search your codebase and the internet incredibly quickly, and it possesses more general knowledge on most topics than you do. It can also iterate faster from failures.
The most important part of this process is giving Claude enough starting context. For example, tell it what step you're currently thinking about; explain your level of familiarity with the problem and codebase; let it collaborate with you as a thinking partner.
I've previously written about generating HTML with Claude. In almost all those scenarios, the HTML artifact is the best way to visualize and express ideas.
In this article, I'll detail some patterns I use to discover these unknowns. I don't use all these tricks every time, but having them as a toolkit to call upon is incredibly useful.
Before Implementation
Blindspot Scan
One of the most useful things when starting work is understanding your blind spots. For example, if you're writing a feature in a new module of the codebase, or having Claude handle a type of work you're unfamiliar with, like iterating on a design, you're likely to have many "unknown unknowns."
You might not know what questions to ask, what constitutes "good," what historical work has been done before, or what pitfalls to avoid.
To do this, you can ask Claude to help find your "unknown unknowns" and explain them. I like to use the terms "blindspot pass" and "unknown unknowns" directly. Usually, it's also important to tell it who you are and what you know.
Example prompts:
"I'm adding a new identity authentication provider, but I know nothing about the auth module in this codebase. Can you do a blindspot pass, help me find relevant unknown unknowns, and assist me in writing better prompts for you?"
"I don't understand color grading, but I need to grade this video. Can you teach me to understand my unknown unknowns about color grading so I can write better prompts?"
Brainstorming & Prototyping
When I'm working in a domain with many "unknown knowns"—things I only know how to define standards for once I see them—I have Claude brainstorm and prototype with me.
Identifying and expressing these "unknown knowns" early in the prototyping stage is valuable because discovering them during implementation often carries a higher relative cost. Small changes in features or specifications can lead to vastly different code implementations, and it's harder to get the agent to backtrack on previous changes.
For example, you might just want to see what adding a button looks like in a certain framework, without actually hooking up the backend routes or maintaining extra frontend state.
Visual design is something I find hard to articulate clearly, but I know what I want when I see it. In such cases, I ask Claude to provide several different design directions for an artifact.
I also start almost every coding session with exploration or brainstorming. This helps me define the project scope with clear intent. Claude often discovers high-value approaches I would have missed, but it can also miss the forest for the trees. Brainstorming prevents me from setting the scope too narrowly or too broadly from the start.
Example prompts:
"I want to make a dashboard for this dataset, but I have no visual taste and don't know what's possible. Help me create an HTML page with 4 vastly different design styles so I can provide feedback based on the results."
"Before wiring anything up, create a standalone HTML file with fake data to simulate the new editor toolbar. I want to give feedback on the layout first before you touch the real app."
"Here's my rough problem: user churn after completing onboarding. Search the codebase and brainstorm 10 places we could intervene, from lowest cost to most ambitious. I'll tell you which directions feel better."
Reverse Interview
After enough brainstorming, I usually still have unknowns.
In such cases, I have Claude interview me around anything unclear or ambiguous. When having Claude interview you, try to provide context about the problem so it can ask more targeted questions. Here are some examples.
Example prompts:
"Please ask me one question at a time, interviewing me around any points of ambiguity. Prioritize questions where my answer would change the architectural design."
Reference Materials
Sometimes, you can't describe in detail what you want. Maybe you lack the language to express it, or it's too complex to describe fully within a reasonable time.
In such cases, the best answer is reference materials. You can provide diagrams, documentation, or images, but the best reference is often source code.
If you have a library that implements a feature in a specific way, or a design component you really like, just point Fable to the corresponding folder and tell it what to look at. Even if the reference code is in another language, that's okay.
This is also how Claude Design works. You don't necessarily have to give it a file, though you can. You can point it to a module on a website you like, and it will read the underlying code, not just a screenshot. This provides richer detail—markup structure, component organization, and how the component is actually built.
Example prompts:
"This Rust crate in vendor/rate-limiter implements exactly the exponential backoff retry behavior I want. Please read it and reimplement the same semantics in our TypeScript API client."
Implementation Plan
When I feel ready to start implementation, I usually have Claude first compile an implementation plan for my review, focusing on parts most likely to change, such as data models, type interfaces, or UX flows. This lets Claude surface areas I might indeed need to adjust ahead of time.
Example prompts:
"Write an implementation plan in HTML, but start by presenting the decision points I'm most likely to change: data model changes, new type interfaces, and any user-facing content. Put mechanical refactoring at the bottom; I trust you can handle that part."
During Implementation
Implementation Notes
When satisfied with the plan, I start a new session and pass the relevant artifacts into the prompt. For example, I might pass a specification file and a prototype, then ask the agent to implement it.
But the truth is, no matter how much you plan, unknown unknowns will always lurk. The agent might discover mid-work that it must take a different approach due to an edge case in the code.
I ask Claude Code to maintain a temporary implementation-notes.md file, or an .html file, to record the decisions it makes, so we can learn from them for the next attempt.
Example prompts:
"Please maintain an implementation-notes.md file. If you encounter an edge case forcing you to deviate from the original plan, choose the conservative option, record the reason under 'Deviations,' and continue."
After Implementation
Pitch & Explanation Documentation
One of the most important things when shipping something is getting others' understanding, support, and approval. Building pitch and explanation artifacts into the final documentation helps:
Accelerate reviewers' understanding when they start with the same unknowns you had.
Accelerate approval from experts when they want to confirm you've considered the unknowns and common failure points they would have foreseen.
Example prompts:
"Package the prototype, spec, and implementation notes into a single document I can directly post on Slack to seek support. Start with a demo GIF."
Quizzes
After a long work session, Claude might have accomplished more than I realize. Just looking at the code diff often gives me only a shallow understanding of what happened, as much behavior depends on existing code paths.
Having Claude test me on the changes after providing substantial context helps me truly understand what occurred. I only merge the code after perfectly passing the quiz.
Example prompts:
"I want to ensure I understand everything that happened in this change. Please give me an HTML report to help me read and understand these changes, including context, intuitive explanations, what was done concretely, etc., and attach a quiz at the bottom that I must pass."
Putting It All Together: The Fable Launch Example
The launch video for Fable was entirely edited by Claude Code. This was a completely new field for me, and I am by no means an expert.
So I started with what I knew. I knew Claude could use code to edit videos and transcribe, but I wasn't sure if its accuracy was sufficient. So I had Claude explain how transcription technologies like Whisper work and whether I could use ffmpeg to accurately cut filler words like "um" or long pauses.
I wanted Claude to create a UI synchronized with my spoken words in time, but I wasn't sure if it could. So I had Claude create a video prototype using Remotion and transcript text to see if the idea was feasible.
Finally, the video itself looked somewhat dark. I knew this was a color grading issue, but I didn't truly understand what color grading was. My first attempt was to have Claude make a few versions for me to choose from, but I realized that when it comes to color grading, I didn't know what "good" was. So, instead of having it generate versions blindly, I had Claude teach me color grading to discover my unknowns.
Matching the Map to the Territory
The more powerful the model, the more you can accomplish with the right approach. When a long-cycle task returns an incorrect result, it likely means you need to spend more time defining your unknowns or creating an implementation plan that allows Claude to navigate these unknowns flexibly.
Every explanation document, brainstorming session, interview, prototype, and reference material is a low-cost way to discover things you didn't know before the cost of fixing them becomes high.
So, when starting your next project, first let Claude help you find your unknowns.
This article is from the WeChat public account "Machine Heart," edited by the Machine Heart Editorial Department.
