This is an excellent article written by a core developer of Claude Code.
Key takeaway: As models get stronger, the bottleneck shifts from the model's capability to your ability to articulate your "blind spots" to the AI.
The author translates the "Four Quadrants" theory of cognitive psychology into a workflow for collaborating with Claude: Blindspot Scanning → Brainstorming → Deep Interview → Implementation Plan → Implementation Notes → Deliverable Packaging → Post-mortem Quiz.
Original: A Field Guide to Fable: Finding Your Unknowns
Author @trq212
Using Claude Fable 5 has constantly reminded me of an old lesson: the map is not the territory.
The map—the representation of the work to be done—is my prompt, skills, and context; it's what I give to Claude. The territory is where the work actually happens: the codebase, the real world, and its actual constraints.
The gap between the map and the territory is what I call the unknown. When Claude encounters an unknown, it must make decisions based on its best guess of "what I want." The larger the workload, the more unknowns Claude is likely to encounter.
Fable is the first model that makes me feel that the upper limit of work quality depends on my ability to clarify unknowns.
Importantly, planning ahead isn't always enough. Unknowns can emerge deep in implementation, or your unknowns might point to the fact that you should have solved the problem in a completely different way.
I've found that collaborating with Fable is an iterative process of discovering unknowns before, during, and after implementation.
What Are Your Unknowns?
When I take a problem to Claude, I tend to break it down into four scenarios:
- Known Knowns: Basically what's written in the prompt. I tell the agent what I want.
- Known Unknowns: Things I haven't figured out yet, but I know I haven't figured them out.
- Unknown Knowns: Things that are so obvious I'd never write them down, but I'd recognize them when I see them.
- Unknown Unknowns: Things I haven't considered at all. What knowledge am I missing? Do I know how well something can be done?
The best agentic programmers have relatively few unknowns. Watching Boris or Jarred write prompts, it's clear they know exactly what they want. They are deeply in sync with the codebase and model behavior.
But they are also anticipating unknowns. In many ways, reducing and planning for unknowns is the core skill of agentic programming. The good news is that this is a skill you can improve by collaborating with Claude.
Guiding Claude is a delicate balance. If you're too specific, Claude will follow your instructions even if a pivot is better; if you're too vague, Claude tends to make choices based on industry best practices that might not fit your task.
When you don't account for unknowns, both directions fail: you don't know when the road is full of obstacles, and you don't know when it's clear—but you still expect Claude to pivot flexibly.
Claude can help you discover unknowns faster. It can search your codebase and the internet extremely quickly and knows more about most topics than you do. It can also iterate faster from failures.
The most critical part of this process is providing Claude with your starting context. For example, tell it what stage of the thinking process you're in; be honest about your experience level with the problem and codebase; let it collaborate with you like a thinking partner.
https://x.com/trq212/status/2052809885763747935
In this article, I'll detail some patterns I use to discover unknowns. I don't necessarily use every technique every time, but having a toolbox of available techniques is valuable.
1. Blindspot Scanning: Finding What You Don't Know You Don't Know
When starting work, one of the most valuable things is understanding your blind spots. For example, if you're writing a feature in a new area of the codebase or asking Claude to help with unfamiliar work (like design iteration), you likely have many unknown unknowns.
You might not know what questions to ask, what "good" looks like, what historical work has been done, or what pitfalls to avoid.
In these cases, you can ask Claude to help identify your unknown unknowns and explain them to you. I tend to use the literal terms "blindspot scan" and "unknown unknowns." Providing context on who you are and what you know is usually important.
Example Prompts:
- "I'm adding a new authentication method, but I don't understand the auth module in this codebase. Can you do a blindspot scan to find my relevant unknown unknowns and help me write better prompts for you?"
- "I don't know what color grading is, but I need to color grade this video. Can you teach me to understand my unknown unknowns in the field of color grading so I can give better prompts?"
2. Brainstorming and Prototyping: Discovering Your Unknown Knowns
When I'm working in an area with many unknown knowns—standards that can only be defined once seen—I like to brainstorm and prototype with Claude.
Identifying and articulating unknown knowns early in the prototyping phase is extremely valuable because discovering them during implementation is relatively expensive. Small changes in features or specs can lead to vastly different implementations at the code level, and it's harder for an agent to roll back previous changes.
For example, you might just want to see if a button looks good in a certain frame without actually connecting backend routes or maintaining frontend state.
Visual design is like this for me: hard to put into words, but I know what I want when I see it. In this case, I'll have Claude provide several different design options for an artifact.
Additionally, I start almost every coding session with an exploration or brainstorming phase. This helps me start with the intent of "defining project scope." Claude often finds high-value solutions I would have missed, and sometimes it misses the forest for the trees. Brainstorming prevents me from setting the scope too narrow or too wide.
Example Prompts:
- "I want to make a dashboard for this data, but I have no visual taste and don't know what's possible. Help me make an HTML page with four distinct design directions for me to react to."
- "Before connecting anything, make a standalone HTML file to mock the new editor toolbar with dummy data. I want to react to the layout before you touch the real app."
- "Here's my rough problem: users are churning after onboarding. Search the codebase and brainstorm 10 places we could intervene, ranked from cheapest to boldest. I'll tell you which ones resonate."
3. Interview Mode: Let Claude Ask You Questions
After enough brainstorming, I might still have unknowns.
At this point, I'll have Claude interview me regarding any unknowns or ambiguities. When letting Claude interview you, try to give it some context about your problem to guide its questions.
Example Prompt:
- "Interview me one by one, asking about any ambiguities, prioritizing questions where my answers would change the architecture."
4. Reference-Driven: When You Can't Describe It, Point to It
Sometimes you can't describe exactly what you want in detail. You might lack the language, or it might be too complex to explain quickly.
In these cases, the best answer is to provide a reference. You can use diagrams, documentation, or images, but the absolute best reference is source code.
If you have a library that implements something in a certain way, or a design component you really like, just point Fable to that folder and tell it what to focus on, even if it's in a different programming language.
This is also how Claude Design works. You don't need to give it a file (though you can). You can point to a module on a website you like, and it will read the underlying code, not just a screenshot. This provides richer detail about markup, structure, and how components are actually built.
Example Prompt:
- "This Rust crate in vendor/rate-limiter implements the backoff behavior I want. Read it, then re-implement it in our TypeScript API client with the same semantics."
5. Implementation Plan: Exposing Potential Changes Before Starting
When I feel ready to implement, I tend to have Claude organize an implementation plan for me to review, focusing on the parts most likely to change—like reviewing data models, type interfaces, or UX flows. This allows Claude to surface things I might actually need to adjust.
Example Prompt:
- "Write an implementation plan in HTML, but put the decisions I'm most likely to adjust at the front: data model changes, new type interfaces, anything user-facing. Bury the mechanical refactoring at the bottom; I trust you with that part."
6. Implementation Notes: Capturing Unknown Unknowns During the Process
Once I'm satisfied with the plan, I'll start a new session and pass the relevant artifacts into the prompt. For example, I might pass in a spec file and a prototype, then let the agent implement it.
But the truth is, no matter how much planning you do, there will always be unknown unknowns lurking. An agent might discover during the work that a different strategy is needed due to an edge case encountered in the code.
I have Claude Code maintain a temporary implementation-notes.md (or .html) file to record the decisions it makes along the way so we can learn from the next attempt.
Example Prompt:
- "Maintain an implementation-notes.md file. If you encounter an edge case that forces you to deviate from the plan, choose a conservative option, record it under 'Deviations,' and continue."
7. Deliverable Packaging: Accelerating Alignment and Approval
An important part of actually delivering something is getting support and approval. Building presentation and illustrative artifacts into the final documentation helps:
- Accelerate Understanding: Reviewers start from the same place as you and have the same unknowns.
- Accelerate Approval: Experts want to see that you've considered the unknowns and common failure points they would anticipate.
Example Prompt:
- "Package the prototype, spec, and implementation notes into a single document I can drop into Slack for approval. Start with a demo GIF."
8. Post-Mortem Quiz: Ensuring You Truly Understand the Changes
After a long collaboration session, Claude might have accomplished much more than I realized. Just reading code diffs only gives me a shallow understanding of what happened because many behaviors depend on existing code paths.
Have Claude quiz you after giving you plenty of context to help you truly understand what happened. I only merge code after completely passing the quiz.
Example Prompt:
- "I want to make sure I understand everything that happened in this change. Give me an HTML report to read and understand, including context, intuition, what was done, etc. Include a quiz about the changes at the bottom that I must pass."
Real Case: The Story of the Fable Launch Video
So I started with what I knew. I knew Claude could edit video and transcriptions with code, but I wasn't sure if it was precise enough. Then I had Claude explain how transcriptions like Whisper work and if I could use ffmpeg to precisely cut out "ums" and long pauses.
I wanted Claude to create a UI synced with the words I spoke, but wasn't sure it could be done, so I had Claude make a prototype video with Remotion and the transcription results to see if it was feasible.
Finally, the video itself looked a bit washed out. I knew it had to do with color grading, but I didn't actually know what color grading was. My first instinct was to have Claude make several variants for me to choose from, but I realized I didn't know what "good" color grading looked like. So, I instead had Claude teach me color grading to discover my unknowns.
Conclusion
The better the model, the more the right approach can help you achieve. When a long-cycle task turns out wrong, it's likely you need to spend more time defining your unknowns or creating an implementation plan that allows Claude to adapt on the fly.
Every explanation, every brainstorm, every interview, every prototype, every reference—is a low-cost way to find out what you don't know before correcting it.
So, for your next project, try starting by letting Claude help you discover your unknowns.
