For most of the agentic coding era, the model was the bottleneck: you knew what you wanted, the agent could not reliably deliver it, and prompting was the art of coaxing capability out of a system that kept dropping the ball. Thariq Shihipar, an engineer on Anthropic's Claude Code team, argues that with Fable, Anthropic's model for long-horizon agentic work, used through Claude Code, the constraint has moved. The model can execute. What caps the quality of the work is your ability to say what you want, and, more precisely, your ability to notice what you have failed to say.
Shihipar frames it as map versus territory. The map is everything you hand the agent: prompts, skills, context. The territory is where the work happens: the codebase, its history, its real constraints. The gap between them is made of unknowns, and every time the agent hits one it makes a guess on your behalf. The longer the task, the more guesses accumulate, and the more the finished work drifts from the thing you had in mind but never wrote down.
He borrows the old four-quadrant taxonomy to sort those gaps. Known knowns are what is in the prompt. Known unknowns are the questions you have not answered yet but at least know exist. Unknown knowns are the things so obvious to you that you would never write them down, though you would recognise them instantly on sight. Unknown unknowns are the things you have not considered at all, including the possibility that you do not know what good looks like in this domain.
The most useful part is that Shihipar turns it into a collection of working prompts, and every one performs the same move: it pulls information out of your head, or exposes its absence, before the mistake gets made rather than after. What follows is my packaging, not his: ten prompts pulled from the guide, lightly adapted, ordered by project phase, and ending with the one that applies at every phase. The names are mine; the moves are his.
1. The blindspot pass. Before starting anything unfamiliar, ask directly: "Do a blindspot pass. What are my unknown unknowns here? Teach me enough to prompt you better." The essential ingredient is admitting where you stand. The model cannot route around gaps you pretend not to have, so Shihipar's own example opens with "I know nothing about the auth modules in this codebase."
2. The options ladder. Before deciding what to build, ask for the solution space: "Here is my rough problem. Brainstorm ten ways to solve it, from cheapest to most ambitious. I'll tell you which resonate." This sets scope with intent. Skipping it is how projects end up too narrow to matter or too wide to finish.
3. Throwaway prototypes. When you would know it when you see it but cannot describe it, ask for three or four disposable versions: "Make me an HTML page with four wildly different design directions so I can react to them." Reacting to drafts beats describing from scratch, and surfacing an unknown known at prototype stage is cheap. Surfacing it mid-implementation, when small spec changes cascade into large code changes, is not.
4. The reverse interview. Once brainstorming is done, flip the direction of questioning: "Interview me one question at a time about anything ambiguous. Prioritise questions where my answer would change the architecture." The value is the forcing function. Answering makes you verbalise assumptions that would otherwise stay unstated until they broke something.
5. References over description. If something close to what you want already exists, point at it rather than describing it. Shihipar's example: "This Rust crate implements the exact backoff behaviour I want. Read it and reimplement the same semantics in our TypeScript client." Source code is the densest reference format there is, and it works across languages.
6. The plan with volatile decisions on top. Before implementation, ask for a plan sorted by likelihood of change: "Lead with the decisions I'm most likely to tweak: data models, type interfaces, anything user-facing. Bury the mechanical refactoring at the bottom." Your review attention is finite. Spend it where your answer would alter the outcome.
7. The implementation notes file. No amount of planning eliminates unknowns discovered mid-flight. So instruct the agent: "Keep an implementation-notes.md file. If you hit an edge case that forces a deviation from the plan, pick the conservative option, log it under Deviations, and keep going." Every autonomous decision gets recorded instead of silently absorbed, and the log becomes a decision record for your next attempt.
8. The buy-in artifact. Shipping means approvals, and your reviewers start with the same unknowns you started with. "Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack." Experts approve faster when they can see you accounted for the failure points they would have raised.
9. The quiz gate. After a long session the agent has often done more than you registered, and reading diffs only tells you so much when behaviour depends on existing code paths. So: "Give me a report on the changes, with context and intuition, and a quiz at the bottom that I must pass." If you cannot pass the quiz, you do not understand what you are shipping, and Shihipar does not merge until he does.
10. Teach me first. When you cannot tell good output from bad, generating options is pointless. Fix the judgement gap upstream: "I don't know what colour grading is. Teach me enough to evaluate this."
That last prompt is worth special attention, since it's Shihipar's own worked example. The Fable launch video was edited entirely by Claude Code, in a domain where he was a novice. His first instinct on the flat-looking footage was the standard move: generate several colour grading variations and pick one. Then he noticed the flaw in the plan. He had no idea what good colour grading looked like, so any selection would be a coin flip dressed up as a decision. The fix was not a better generation prompt. It was asking Claude to teach him the domain until he could judge, then choosing.
That is the pattern underneath all ten. None of these prompts asks the model to be smarter. Each one relocates a failure from after the work, where it is expensive, to before it, where it costs a question. The prompts are cheap. What is getting expensive is not asking them.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.