Claude Fable and the Real Skill of Agentic Coding: Finding Your Unknowns
Anthropic's latest Claude Code post, "A field guide to Claude Fable 5: Finding your unknowns," is not really about a new prompt trick.
It is about a shift that every serious Claude Code user is going to feel: as models get better at carrying long tasks, the limiting factor moves from raw model capability to how well the human can expose the real shape of the work.
That is the point of the "map and territory" framing in the official post. The map is what we give Claude: prompts, skills, files, specs, screenshots, references, and context. The territory is the actual system: production constraints, old decisions, implicit taste, hidden business rules, edge cases, and the parts of the codebase nobody writes down.
The gap between those two is where agentic coding succeeds or fails.
Why This Matters More With Fable
With weaker models, many failures are easy to blame on the model.
It forgot a requirement. It wrote shallow code. It misunderstood a file. It stopped early. It did not use the right tool.
With stronger models like Claude Fable, that excuse gets less useful. The model can hold more context, run longer, inspect more files, prototype faster, and recover from more mistakes. That means failures increasingly come from a different source: the task was underspecified in ways the human did not notice.
That is a harder problem.
It means the useful question is not only:
How do I make Claude implement this?
It is:
What does Claude need to discover before implementation starts,
and what should it keep discovering while implementation is underway?
For Claude Code teams, that is the skill to build.
The Four Kinds Of Unknowns
The official post uses a useful four-part breakdown:
- Known knowns: what you already put in the prompt.
- Known unknowns: the things you know are unresolved.
- Unknown knowns: implicit taste, experience, assumptions, and standards you would recognize if you saw them, but did not write down.
- Unknown unknowns: missing context you have not even thought to ask about.
Most Claude Code failures happen in the last two categories.
The team says "make it match the existing settings page," but never says what "match" means. The agent sees three old patterns and picks the wrong one. The ticket says "add SSO," but nobody mentions the legacy enterprise account model. The prompt says "clean up the API client," but the retry behavior exists because of a vendor bug from two years ago.
None of that is stupidity. It is missing territory.
Good agentic coding is the practice of making that missing territory visible early enough that the agent can use it.
Pre-Implementation: Spend Cheap Tokens Before Expensive Changes
The most practical lesson from Anthropic's post is that planning is not just "ask for a plan."
Planning is a sequence of cheap discovery passes before the agent starts changing the real system.
1. Run a blind spot pass
Use this when you are entering an unfamiliar part of the codebase or an unfamiliar domain.
I am about to work on [task], but I do not know this part of the codebase well.
Do a blind spot pass before planning.
Find the unknown unknowns that are most likely to change the implementation.
Group them by codebase risk, product risk, test risk, and rollout risk.
Do not edit files yet.
The important part is the constraint: do not edit files yet.
Before implementation, Claude should be a scout. It should search, inspect, compare, and explain where the risky assumptions are.
2. Ask for alternatives before asking for a solution
When your requirements are still fuzzy, do not ask Claude for "the implementation."
Ask for options.
Before choosing an implementation, propose three approaches:
1. the smallest safe change,
2. the architecture-clean change,
3. the fastest prototype.
For each, list what we would learn, what we might regret,
and which files would be touched.
This forces implicit preferences into the open. You may discover that you care more about rollout safety than code elegance, or that a prototype is enough because the product direction is still uncertain.
3. Prototype what you cannot describe
Some unknowns are not verbal. UI density, editor feel, animation timing, report layout, review ergonomics, and artifact structure are easier to judge when you can react to something.
For Claude Code, that often means a disposable HTML artifact.
Create a single-file HTML prototype with fake data.
Show three different interaction patterns for this workflow.
Do not wire it to the production app.
Optimize for helping me decide what feels right.
This is cheaper than implementing the wrong thing in React, Swift, Kotlin, or a backend workflow and then asking the agent to unwind it.
4. Use source code as the best reference
Screenshots help. Docs help. But source code is often the best reference because it carries exact structure, naming, behavior, and edge cases.
Read the implementation in `packages/legacy-sync`.
I want the new TypeScript client to preserve the same retry semantics,
but use our current logging and metrics conventions.
Summarize the behavior before writing code.
This is one of the biggest advantages of Claude Code over a normal chat interface: it can inspect the reference directly inside the workspace.
During Implementation: Keep A Decision Log
Even a good plan will be wrong in places.
The question is whether the agent silently improvises or leaves a trail.
For serious Claude Code work, ask for an implementation note file:
Keep `implementation-notes.md` while you work.
When you find an edge case that changes the plan, log it under:
- Discovery
- Decision
- Files affected
- Risk
- Follow-up needed
Pick the conservative option unless the plan clearly says otherwise.
This does two useful things.
First, it makes the agent's deviations visible. You can review why the implementation changed instead of reverse-engineering the diff.
Second, it improves the next session. The note file becomes durable project context. A future Claude session can read it and understand which unknowns were discovered.
That matters because long-running agent work is rarely one clean pass. It is usually a sequence of discoveries, decisions, and corrections.
Post-Implementation: Review Understanding, Not Just Diffs
The official post recommends pitches, explainers, and quizzes after implementation. That sounds lightweight, but it solves a real problem.
When Claude changes a lot of code, reading the diff may not tell you what actually happened. The behavior depends on existing code paths, conventions, tests, and runtime assumptions.
Ask Claude to produce an explainer that makes the change reviewable:
Create a review packet for this change.
Include:
- what changed,
- why it changed,
- important files,
- behavior before and after,
- risks,
- tests run,
- what was intentionally not changed.
Then make it quiz you:
Quiz me on the change.
Ask one question at a time.
Focus on behavior, edge cases, and rollback.
Do not say I understand it until I answer every question correctly.
That may sound excessive for small work. It is not excessive for changes where the agent touched parts of the system you do not deeply know.
For teams, this becomes a useful merge gate: do not approve a large agent-generated change until a human can explain it.
The Practical Workflow
For our Claude Code community, the official article can be reduced to a simple workflow:
- Discover before planning. Ask for blind spots and unknown unknowns.
- Compare before committing. Ask for multiple approaches, not one solution.
- Prototype before wiring. Make the implicit visible.
- Reference real code. Give Claude examples from the repo, not only prose.
- Log deviations. Keep implementation notes during the run.
- Package the review. Ask for an explainer, risks, and tests.
- Verify human understanding. Use a quiz for large or unfamiliar changes.
This is not ceremony. It is how you keep stronger agents from turning vague intent into expensive rework.
A Starter Prompt For Fable Sessions
Here is a practical starting prompt for a large Claude Code task:
We are going to work on [task].
Before implementation, do a blind spot pass:
- what is known,
- what is ambiguous,
- what codebase context you need,
- what decisions could change the architecture,
- what should be prototyped before real implementation.
Do not edit files yet.
After the blind spot pass, propose 2-3 implementation approaches.
For each approach, include files likely touched, risks, test strategy,
and what would make you change your mind.
Then, after you choose an approach:
Implement the chosen approach.
Keep `implementation-notes.md`.
Log any deviation from the plan before continuing.
Run the relevant tests.
At the end, produce a review packet and quiz me on the change.
This prompt is not magic. It just makes unknown discovery part of the workflow instead of a lucky accident.
Bottom Line
Claude Fable makes agentic coding feel different because it can carry more of the work. That is powerful, but it changes the bottleneck.
The better the model gets, the more important it becomes to surface what the human has not specified: domain expectations, old code paths, taste, risk tolerance, rollout constraints, and the shape of "good."
So the next time a long Claude Code task goes wrong, do not only ask whether the model failed.
Ask which unknown you failed to uncover before the work became expensive.