Update — August 5, 2026: The paper cited approvingly in the HN thread on this post now has its own deep dive — ICML's "LLMs Can't Jump" position paper argues LLMs can't perform abduction (generating genuinely new axioms), a deeper version of the same map-vs-territory idea: reasoning within a given symbolic space versus generating a new one from raw experience.
Update — July 16, 2026: Thariq's latest framework tweet — thin prompts, thick artifacts, thin skills (good vs bad SKILL.md examples, ice-cream sandwich model, Garry Tan reply).
Update — July 7, 2026: Full AI Engineer stage recap — Field Guide to Fable — Thariq Shihipar (unhobbling, grief, being unreasonable + copy-paste prompts).
Update — July 5, 2026: Refreshed companion — Claude Code HTML vs Markdown with official Anthropic screenshots and copy-paste prompts.
Claude Code engineer Thariq (@trq212) published a new field guide this week titled "A Field Guide to Fable: Finding Your Unknowns," and it's doing the same rounds his earlier essay on HTML over Markdown did. The core claim is deceptively simple: working with Claude Fable 5 keeps re-teaching him an old lesson — the map is not the territory. Your prompt, your skills, your CLAUDE.md, your context — that's all just a representation of the work. It is not the work itself.
That distinction sounds obvious until you watch what happens when the gap between map and territory widens with a more capable, more autonomous model. This post unpacks the metaphor, why it gets sharper rather than softer as models improve, and the concrete practices — the human/agent PR split, disciplined skill invocation, and deliberate unknown-hunting — that close the gap in day-to-day Claude Code work.
The map/territory problem, applied to agentic coding
The map/territory distinction comes from general semantics — a map can be useful, detailed, even beautiful, and still be wrong about the terrain it describes. Applied to coding agents, the "map" is everything you hand Claude before it starts working:
- The prompt itself
- Any SKILL.md invoked for the task
CLAUDE.mdproject conventions and standing rules- Prior conversation context and files read into the session
The "territory" is the actual codebase, its history, its undocumented constraints, and the real intent behind the request — most of which never makes it into the map because writing it all down is either impossible or something the requester didn't think to mention.
An agent doesn't act on the territory. It acts on the map. So any place where the map is silent, wrong, or stale becomes exactly where the agent goes wrong — confidently, because from its vantage point the map is all there is.
Why capability makes this worse, not better
A recurring reply to Thariq's post asked the natural contrarian question: shouldn't this matter more with dumber models, since they need more hand-holding?
It's the opposite, and the reasoning is worth internalizing:
| Model behavior | Weaker model | More capable, more autonomous model (Fable 5) |
|---|---|---|
| Response to ambiguous instructions | Hedges, asks, or produces something visibly wrong that gets caught fast | Resolves ambiguity confidently and consistently |
| Scope of a single bad assumption | Contained to one small output | Propagates across an entire multi-file, multi-step session |
| Human review behavior | Reviewed line-by-line because output is unreliable | Reviewed more loosely because output is usually right |
| Cost of a map/territory gap | Caught early, cheap to fix | Caught late, after the agent has built on top of the wrong assumption |
A weak model's failures are loud and local. A strong model's failures are quiet and compounding — it takes your map at face value and executes it thoroughly, which is exactly what makes an unstated assumption expensive. This tracks with what Anthropic's own guidance on agentic coding and expertise has found: more autonomous agents shift the bottleneck from "can the model do the task" to "did you specify the task correctly." Capability doesn't remove the need for a good map. It raises the price of a bad one.
The human-section, agent-section PR pattern
One of the most concrete practices to come out of this thread is splitting pull request descriptions into two distinct sections, addressed to two different readers:
Human section — images, screenshots, before/after diffs, short GIFs. Some information genuinely doesn't compress into text: a subtle layout shift, an animation timing, a color that's "almost right but not quite." Forcing a reviewer to reconstruct a visual change from a written description wastes their time and yours.
Agent section — plain text covering intent, constraints, edge cases considered, and things intentionally left out of scope. This is the section a follow-up agent session — yours or a teammate's — actually reads when it picks up related work later. Agents currently reason more reliably over structured text than over pixels, so burying that information inside a screenshot makes it invisible to the next agent that needs it.
Example PR description structure:
## For reviewers
 → 
The button now animates on click instead of an instant color swap.
## For agents
- Changed: `Button.tsx` click handler now debounces via `requestAnimationFrame`
- Constraint: must stay under 16ms per frame budget (see PERF.md)
- Not in scope: the disabled-state styling, tracked in FOLLOWUP-142
- Assumption: existing snapshot tests didn't cover animation timing, added new ones
This is the same instinct behind Thariq's earlier HTML-over-Markdown argument: pick the format that actually carries the information for the reader consuming it, human or agent, rather than defaulting to whatever's fastest to write. It's also a direct extension of the map/territory idea — a PR description is a map of the change, and a map that only serves one kind of reader leaves the other one working from an incomplete territory.
When to invoke a skill — and when the skill is the wrong map
A related question from the thread: with a model as capable as Fable 5, are heavyweight skills frameworks like "superpowers" still worth maintaining, or do they just get in the way?
The honest answer is that a skill is itself a map — a codified shortcut standing in for territory the model would otherwise have to rediscover every session. That's valuable when the shortcut is accurate and repeatable. It's a liability when it's stale, over-specified for a model that no longer needs the hand-holding, or written for a problem that's subtly different this time.
Use this as a rough decision rule, consistent with the guidance in Skills vs Hooks vs Prompts:
| Situation | Reach for |
|---|---|
| Repeatable task with a known failure mode | A skill — encode the procedure once |
| Standing project convention that applies to every session | CLAUDE.md |
| Enforcing an action automatically on a tool call | A hook |
| One-off, exploratory, or genuinely novel work | Direct prompting, no skill |
| A skill hasn't been revisited since a model upgrade | Audit it — some scaffolding may now be dead weight |
The failure mode to watch for is treating a skill written for a weaker model as permanent scaffolding. If a skill mostly compensates for a model's shortcomings — exhaustive step-by-step instructions, defensive over-explaining — a capability jump like Fable 5 can make parts of that skill unnecessary map, not helpful map. Periodically re-reading skills against what the current model actually needs is part of keeping your map current with a moving territory, echoing the reasoning in Steering Claude Code with CLAUDE.md, skills, hooks, and subagents.
Finding your unknown unknowns before the agent does
The most durable part of the field guide isn't a specific tactic — it's a discipline. A few practices worth adopting directly:
- Have the agent restate the plan before executing. If Claude's paraphrase of your prompt surprises you, that's the map/territory gap surfacing early and cheaply, before any code changes.
- Treat every surprising first-pass output as a signal, not just a bug. When the agent does something reasonable-but-wrong, don't just fix the output — ask what assumption in your map was missing, and update
CLAUDE.mdor the relevant skill so the same gap doesn't reappear next session. - Reserve high reasoning effort for genuinely ambiguous work. Effort level is itself a map decision — spending more of it on a well-specified, repeatable task wastes budget you'd rather spend on the parts of the codebase your map doesn't cover well.
- Don't mistake a complaint about the model for a complaint about the map. A chunk of the public frustration with new model releases traces back to prompts, skills, and context tuned for the previous model's blind spots — not an actual regression. Re-verify your map against the new model before assuming the territory changed.
None of this is unique to Fable 5. It's the same discipline behind good context engineering and behind the emphasis on CLAUDE.md as persistent memory — the map only stays useful if you keep updating it against the territory it's supposed to represent.
Update — July 16, 2026: @anthrupad's Fable/Mythos video game probe — ten runs, two fixed attractors (Outer Wilds, Disco Elysium), and Fable's "map vs territory" frame applied to game aesthetics ("understanding > agency > power").
Update — July 21, 2026: A viral developer case study framed Kimi K3 vs Fable 5 on a 3D stadium as "vibe coding vs vibe engineering" — fast single-file demos versus agents that self-verify with E2E and screenshots. Same map/territory lesson: wall-clock speed is not the territory of ship-ready code.
Related reading on explainx.ai
- "LLMs Can't Jump" — ICML position paper on abduction — the deeper research version of the map/territory argument
- Thariq — Jevons paradox in math (Aug 2026)
- Kimi K3 vs Fable 5 — vibe engineering stadium case study — harness + verification vs one-shot HTML
- Fable/Mythos favorite video games experiment — epistemic tenderness and preference manifolds
- Field Guide to Fable — Thariq Shihipar AI Engineer talk — full four-part recap
- Ethan Mollick — Wharton Prompting Science: specs not tricks — why map/spec beats persona tricks
- Will Fable 5 return to subscription plans? — Thariq's July 7 deadline and restore pledge
- The unreasonable effectiveness of HTML in Claude Code
- Skills vs Hooks vs Prompts: when to use each
- Steering Claude Code with CLAUDE.md, skills, hooks, and subagents
- What are agent skills? Complete guide
- What is CLAUDE.md? Persistent memory for Claude Code
- Anthropic's research on Claude Code expertise and agentic coding
- Claude Code commands: complete reference guide
This post analyzes Thariq's original field guide and public reactions to it on X. Model behavior, skill conventions, and best practices for Claude Code evolve quickly — verify current guidance in your own sessions before treating any specific tactic as permanent.