Finding Your Unknowns
When you work with Claude Code, the map is what you hand it — your prompts, skills and context; the territory is where the work needs to happen — the codebase and its real constraints. The gap between them is your unknowns. Thariq Shihipar calls Fable the first model where the quality of the work is bottlenecked by his ability to clarify its unknowns, not by the model.
The gap has a name: unknowns
Thariq frames working with Claude Code as the difference between the map and the territory. The map — a representation of the work to be done — is his prompts, skills and context, what he gives Claude. The territory is where the work needs to happen: the codebase, the real world, its actual constraints. The difference between the two is what he calls unknowns.
When Claude runs into an unknown, it has to make a decision based on its best guess of what you want. The more work being done, the more unknowns Claude might run into. He sets the tone for the whole method with one judgment:
"Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns."
Importantly, planning ahead isn't always enough. You can find unknowns deep in implementation, or an unknown may point you to the fact that you should solve the problem a different way altogether. So working with Fable is, in his telling, an iterative process of discovering your unknowns before, during, and after implementation.
Break unknowns into four kinds
When Thariq comes to a problem, he tends to break it down four ways. The bottom-right cell — unknown unknowns — is usually the expensive one, because you don't even know what to ask.
In his observation, the best agentic coders have relatively few unknowns. Watch someone like Boris or Jarred prompt and it's obvious they know what they want in detail, deeply in sync with both the codebase and model behaviors. But they also assume unknowns. From this he draws the definition of the craft:
"In many ways, reducing and planning for your unknowns is the skill of agentic coding."
And luckily, this is a skill you can improve at, by working with Claude.
The balance in instructing Claude
Instructing Claude is a delicate balance. Too specific, and Claude follows your instructions even when a pivot would be more appropriate; too vague, and it makes choices and assumptions based on industry best practices that may not fit your task. Don't account for your unknowns and you fail both ways. The flip side: Claude can help you discover your unknowns faster — it searches your codebase and the internet extremely quickly, it knows more about the average topic than you do, and it iterates from failure faster. The most important part of the process is to give Claude context about your starting point: tell it where you are in your thought process, disclose your experience with the problem and codebase, and let it work with you like a thought partner.
Before you start: surface the unknowns
He splits the patterns into three phases: pre-implementation, during, and post. Pre-implementation is the thickest — five patterns, each with a prompt you can copy.
Blind Spot Pass
Writing in an unfamiliar part of the codebase, or doing unfamiliar work like design iteration, you likely have a lot of unknown unknowns: you don't know what to ask, what good looks like, or what potholes to avoid. Ask Claude to find those unknown unknowns and explain them to you. Thariq likes to use the literal words "blind spot pass" and "unknown unknowns," and to give Claude context on who you are and what you know.
"I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blind spot pass to help me figure out my relevant unknown unknowns and help me prompt you better."
"I don't know what color grading is but I need to grade this video. Can you teach me to understand my unknown unknowns about color grading, so that I can prompt better?"
Brainstorms and prototypes
In an area full of unknown knowns — criteria you only know to define when you see them — ask Claude to brainstorm and prototype with you. Verbalizing unknown knowns early is valuable, because finding them during implementation is relatively expensive: a small change in spec can cause a drastically different implementation. He starts almost every coding session with an exploration or brainstorming phase to set scope, so it's neither too narrow nor too wide.
"I want a dashboard for this data but I have no visual taste and don't know what's possible. Make me an HTML page with 4 wildly different design directions so I can react to them."
"Before wiring anything up, make a single HTML file mocking the new editor toolbar with fake data. I want to react to the layout before you touch the real app."
"Here's my rough problem: users churn after onboarding. Search the codebase and brainstorm 10 places we could intervene, from cheapest to most ambitious. I'll tell you which ones resonate."
Interviews
After enough brainstorming there are usually unknowns left. Ask Claude to interview you about any unknowns or ambiguities, giving it context about your problem to guide its questions.
"Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture."
References
Sometimes you can't describe what you want in detail — you may not have the language, or it's complicated enough that it would take a while. The best approach is a reference, and the absolute best reference is source code. If a library implements something the way you want, point Fable at the folder and tell it what to look for, even in a different language. Source gives Claude much richer detail on markup and structure than a screenshot.
"This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client."
Implementation Plans
When he thinks he's ready to implement, he asks Claude for an implementation plan to review. The plan focuses on the parts most likely to change — data models, type interfaces, UX flows — so Claude surfaces the things he might actually need to alter.
"Write an implementation plan in HTML, but lead with the decisions I'm most likely to tweak with: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom, I trust you on that part."
During: have the agent log where it deviates
Once satisfied with the plan, Thariq starts a new session and passes the artifacts into the prompt. This gives Claude a fresh context window but with all the information compiled during planning — for example, a spec file and a prototype.
But no matter how much planning you do, there are always unknown unknowns lurking. The agent may find during its work that it needs to take a different tack because of an edge case in the code. So he asks Claude Code to keep a temporary implementation-notes.md (or .html) file where it tracks the decisions it makes, so he can learn from them on the next attempt.
"Keep an implementation-notes.md file. If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going."
After: use unknowns to verify
Shipping and reviewing also turn on unknowns: help others skip the potholes you hit, and confirm you actually understand what the agent did.
Pitches and explainers
In his view, getting buy-in and approvals is one of the most important parts of shipping. Building pitch and explainer artifacts in the final document helps in two ways: it accelerates understanding when reviewers start with the same unknowns you did, and accelerates approvals when experts want to see that you accounted for the unknowns and common failure points they would have anticipated.
"Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack to get buy-in. Lead with the demo GIF."
Quizzes
After a long working session, Claude may have accomplished more than he realized. Reading code diffs only gives a light understanding, since much of the behavior depends on existing code paths. Asking Claude to quiz him about the change — after he feeds Claude plenty of context — helps him understand what happened. He only merges after he passes the quiz perfectly.
"I want to make sure I understand everything that's happened in this change. Give me a HTML report on the changes for me to read and understand with context, intuition, what was done, etc. and a quiz at the bottom on the changes that I must pass."
Editing the Fable launch video ran the whole method
The launch video for Fable was edited end-to-end with Claude Code. This was a new domain for him, and by his own account he is by no means an expert. The whole process was one of starting from what he knew and filling in the unknowns one by one.
Start from what you know
He knew Claude could edit and transcribe video with code, but wasn't sure it was accurate enough. So he asked Claude to explain how transcription like Whisper works, and whether he could accurately cut out ums and large pauses using ffmpeg.
Prototype the uncertain parts
He wanted a UI timed with the words he was saying, but wasn't sure it was possible — so he asked Claude to build a prototype video with Remotion and a transcription to see if it would work.
When you don't know "good," have Claude teach you
The video looked muted, which he knew was color grading, but he didn't really know what color grading was. His first attempt was to have Claude produce variations to pick from, but he realized he didn't know what "good" looked like — so instead he asked Claude to teach him about color grading, to discover his unknowns.
Matching the map and territory
The article closes on a methodological judgment: the better models get, the more you can achieve with the right approach. When a long-horizon task comes back wrong, it's likely you need to spend more time defining your unknowns, or build an implementation plan that lets you and Claude adapt 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."
So, as he puts it, start your next project by asking Claude to help you find your unknowns.
→ github.com/aws-samples/sample-aws-ops-skills-for-agents ·
finding-your-unknowns