Models get smarter in "spikes" — prompts, meanwhile, need to do less

To understand why this generation of models needs "fewer examples, more context," look at two pieces of background first. This section is setup — the main point comes later.

The first piece of background is capability overhang: models don't get stronger evenly across the board — they suddenly leap ahead on certain specific tasks. There's a viral post online asking "why can't large models say which Pokémon names end in AW" — a regular chat model can't answer, even though it clearly knows all the Pokémon names. But Claude Code can answer, because it will fetch every Pokémon and write a script to filter for names ending in AW. Same "knowledge," but whether or not you give it a code-execution tool makes a world of difference in the result.

The second piece of background is more counterintuitive: system prompts are getting smaller. Thariq splits prompt-engineering best practice into three stages, and you can see the trend.

Tools are also evolving alongside model capability. Take the ask-user-question tool (which lets the model pop multiple-choice questions back at you during planning) as an example: with Opus 4 it could barely call it; with Opus 4.5 you could tell it to "ask me 40 questions about the requirements" and it started being able to interview you; by Opus 4.8 and Fable, it can generate an entire HTML report with the questions embedded directly in it. Understanding a model is more like biology — very empirical, very organic — you need to build intuition for it.

The core framework: sort your unknowns into four boxes

The plan in your head, the prompt, the spec — that's the "map." The real codebase and real-world constraints — that's the "territory." Every time Claude runs into something in the territory that isn't marked on the map, it has to guess what you actually want and make a call — that point is called an "unknown." The more work it does, the more unknowns it runs into.

Facing a problem, break down "what you know" into four boxes.

Top agentic coders (he named Boris and Jarred) share one thing in common: they have very few unknowns — watching them write prompts, you can tell they're completely on top of both the codebase and model behavior. At the same time, they assume unknowns will always exist. So reducing and pre-planning for your unknowns is the core skill of agentic coding as a craft — and it's a skill you can improve by practicing it with Claude.

Why is handling unknowns the key? Because instructing Claude is a delicate balance — being too specific and too vague both lose.

If you don't prepare for unknowns, you lose both ways: you don't know which stretch of road has pitfalls (not detailed enough where it needed to be), and you don't know which stretch is actually clear and could be left to run on its own (not let go where it could have been). The good news is Claude can help you find unknowns faster — it searches the codebase and the whole web extremely fast, and it iterates from failure faster than you do. The most critical step is giving it your "starting point": tell it what stage you're thinking at, how much experience you have with this problem and codebase, and let it be your thinking partner.

Below are 8 actionable patterns, organized into three stages: before, during, and after you start work. Each method card has a small four-quadrant icon in the top-right corner — the highlighted box is the type of unknown that pattern is primarily built to handle. Every example prompt is given in full: a paraphrase to help you understand it, plus the verbatim original text ready to copy and paste.

Two moves before you start: Blind Spot Pass + Brainstorms & Prototypes

Before you start, the two types of unknowns most worth resolving are: things you never even thought of (unknown unknowns), and things you can't put into words but recognize the moment you see them (unknown knowns).

"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?"

"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."

Three more moves before you start: let it interview you, give it references, ask for an implementation plan

Once you've brainstormed enough, there's usually still some unknowns left. The remaining three moves: force out the ambiguity, give it a better map, and have the plan put the "decisions most likely to change" up front.

"Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture."

"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."

"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 and after: implementation notes, pitch docs, and letting it quiz you

Once you're happy with the plan, open a new session and feed in the artifacts — the spec, the prototypes — giving it a clean context window that still carries all the information from the planning stage. The next three moves cover the work in progress and after delivery.

"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."

"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."

"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."

A living example: how he ran through this method himself

Fable's launch video was cut from start to finish by Thariq using Claude Code, and video editing was a completely new domain for him — he wasn't an expert. His approach happens to chain together all the methods above.

Every explainer, brainstorm, interview, prototype, and reference is a cheap way to figure out what you didn't know before, before it gets expensive.Thariq Shihipar, A Field Guide to Fable

A practical checklist: how to use this starting with your next project

The 8 patterns, grouped into a checklist by when to use them in your workflow — just match your situation to the list.

The method in one sentence: first break down "what you know" into four cases, then use a set of prompt (the instructions you send an AI) patterns to move scattered unknowns step by step into "known" — only then does the model get it right. There's also a counterintuitive first-hand shift alongside this: the prompts fed to the model are shrinking.

So how do you actually find your unknowns? See the diagram below.

Running example: XiaoHu wants to add a login authentication feature to his own codebase, but knows nothing about the auth module. The plan in his head is the "map," the real codebase is the "territory" — every time the AI hits something in the territory that isn't marked on the map, that's one more "unknown." Sort unknowns into four boxes by "whether you're aware of it × whether you actually understand it," and what the method does is move them into the top-left "known known" box.

The author uses himself as a living example: Fable's launch video was cut from start to finish by him using Claude Code, and video editing was a completely unfamiliar domain for him. His approach happened to chain this method together — first asking the AI whether transcription accuracy was good enough (finding unknowns), prototyping a word-by-word synced subtitle feature with code to test it, and having Claude teach him about color grading (setting the tone of the footage) before touching it, since he didn't understand it. A total outsider pulled off professional-grade work by "finding blind spots first, then acting."

Where the numbers come from: all figures above, plus the "weeks → hours" claim, come from the talk and the official blog post themselves (Anthropic talking about its own product — vendor content); none of it has been independently reproduced by a third party.