Field Guide to Fable — Thariq Shihipar, Anthropic

At-a-Glance

• Verdict: Watch fully
• Core thesis: Fable (Anthropic's new agentic coding model) represents a capability jump requiring operators to 'unhobble' both the model and themselves by finding unknowns, embracing spiky capability overhang, and rejecting traditional tradeoffs to do unreasonably ambitious work.
• Why it matters: First practitioner-level field guide from Anthropic insiders on how to actually work with frontier agentic models; reveals specific prompting evolutions, capability discovery patterns, and operational mindset shifts required for 2025 AI-native workflows.
• Best use: Watch for concrete Fable/Claude Code prompting techniques (blind spot passes, interview loops, reference-based maps), system prompt evolution patterns, and the philosophical frame on 'being unreasonable' about productivity tradeoffs—then apply these patterns to your own agent workflows immediately.

Executive Summary

Thariq Shihipar, a member of Anthropic's Claude Code team, delivered a practitioner's guide to working with Fable—Anthropic's new agentic coding model being rolled out at the conference. His central metaphor: Fable is like an RPG tutorial ending and the open world beginning—enormous possibility but also confusion about how to navigate it. He structures the talk around four concepts: unhobbling Claude (understanding how models get spiky-smart through capability overhang, not linear improvements), finding your unknowns (using structured techniques to map the territory vs. your mental map), dealing with the grief (acknowledging what's lost when hand-coding becomes obsolete while embracing what's gained), and being unreasonable (rejecting implicit tradeoffs and forcing reality to show you constraints rather than pre-compromising).

On unhobbling: Shihipar explains that models are 'grown not designed'—they don't linearly improve but gain capabilities in spiky ways (e.g., Claude Code couldn't list Pokémon ending in 'AW' via reasoning but could via code execution). He documents three major capability jumps: chat models gained context → Claude Code gained 'arms' (bash/tools to build its own context) → Claude Tag gained proactive/multiplayer capabilities. Critically, he reveals Anthropic removed 80% of Claude Code's system prompt recently because newer models are more imaginative than constraining examples, now preferring 'context not constraints.' The ask_user_question tool evolved from barely callable in Opus 4 to interviewing users with 40 questions in 4.5 to embedding questions in full HTML reports in Fable. Markdown/HTML output similarly evolved from simple formatting → planning visualization → rich interactive reports.

On finding unknowns: Shihipar introduces a 2x2 matrix (known knowns, known unknowns, unknown knowns, unknown unknowns) and argues Fable is 'bottlenecked by your ability to match map and territory.' He provides six concrete techniques: (1) blind spot passes—ask Claude to audit your prompt for gotchas in unfamiliar domains, pointing it to git diffs/Slack for context; (2) brainstorms/prototypes—'I have no visual taste, make 4 wildly different design versions so I can react'; (3) interviews—let Claude question you, prioritizing architecture-changing questions; (4) references—give Claude existing code/mockups as a 'map' rather than writing specs from scratch; (5) implementation notes—log deviations when Claude hits unknowns; (6) quizzes—have Claude test your understanding before merging. These techniques help operators stay 'in the loop' despite Fable's expanded autonomy.

On grief and being unreasonable: Shihipar shares personal reflection from revisiting his YC startup codebase—tasks that took weeks now take hours, inducing both joy and mourning for the craft of hand-coding. His resolution: 'the only way out is through.' He advocates Anthropic's internal culture of rejecting tradeoffs ('tradeoffs are not real')—rather than reasonably prioritizing, attempt everything and force reality to reveal actual constraints. The new math is 'good, fast, cheap—pick three.' He frames AI Engineer attendees as needing to prove agents work by 'doing the best work of our lives faster than ever before' while actually working less. He created his entire conference deck in 4 hours with Fable. Final caveat: building is easier but generating value is still hard—requires many swings to find what matters.

Key Takeaways

• Claim: Anthropic removed 80% of Claude Code's system prompt between Sonnet 3.5 and recent models because newer models are more imaginative than the constraining examples they were given. | Evidence: Original best practice was small system prompt + few tools + many examples. Then larger prompts + many tools + many examples. Now smaller prompts with context (not constraints), fewer examples, because 'examples tend to constrain it' and models surpass the example quality. | Caveat: This evolution is model-specific and empirical—'closer to biology than physics'—so what works for Fable may not apply to other model families or earlier Claude versions. | Implication: Ken should audit his agent system prompts: if using extensive few-shot examples or 'do not' constraints with frontier models, he's likely limiting performance. Shift to contextual framing and let the model be more creative than your examples. | Timestamp: 04:45
• Claim: Claude Code can now answer 'which Pokémon end in AW' (Croconaw, Dreadnaw) via code execution despite base models failing pure reasoning, illustrating 'capability overhang'—models get smarter in spiky ways when given tools. | Evidence: Viral tweet showed chat models couldn't list the two Pokémon ending in AW out of 1000 despite 'knowing' all names. Claude Code fetches the list and filters programmatically, succeeding immediately. | Caveat: This only works when the tool (code execution) is available and the model is prompted to use it; capability overhang requires discovering which tools unlock which latent abilities. | Implication: Ken should instrument his agents with diverse tools (bash, search, API calls) and test for surprising capability unlocks rather than assuming linear intelligence increases from model upgrades alone. The harness matters as much as the weights. | Timestamp: 03:20
• Claim: Fable is 'bottlenecked by your ability to match the map (your mental spec/prompt) and the territory (actual codebase constraints)' when it hits unknowns not specified in your prompt. | Evidence: Shihipar introduces a 2x2 matrix: known knowns (what you prompt), known unknowns (acknowledged gaps), unknown knowns (unspoken 'I know it when I see it' design taste), unknown unknowns (unconsidered factors). Fable traverses more territory, hitting more unknowns. | Caveat: No explicit failure mode described—unclear what happens when Fable hits an unknown without guidance (does it guess poorly, stop and ask, hallucinate a solution?). | Implication: Ken should front-load discovery work using Fable itself via blind spot passes, interviews, and brainstorming before full execution. Treat prompting as iterative territory mapping, not one-shot instruction. Budget time for unknown discovery in agent workflows. | Timestamp: 09:15
• Claim: The ask_user_question tool in Claude Code evolved from barely callable in Opus 4 → interviewing users with 40 questions in 4.5 → embedding questions in full HTML reports in Fable, showing spiky capability progression. | Evidence: Shihipar worked on the feature and had to 'tweak the tool' heavily for Opus 4 to call it at all. By 4.5, prompting 'ask me 40 questions about the spec' worked reliably. In Fable, it generates structured HTML with embedded questions. | Caveat: This is a single feature's evolution; not all capabilities follow this trajectory. Shihipar doesn't specify whether this required tool schema changes or just model improvements. | Implication: Ken should revisit tools/features that were marginal in earlier models—they may now be core capabilities. Don't assume a tool that 'didn't work well' six months ago is still limited. Re-test systematically with each model generation. | Timestamp: 06:30
• Claim: Six concrete techniques for finding unknowns with Fable: blind spot passes, brainstorms/prototypes, interviews, references, implementation notes, and quizzes. | Evidence: Blind spot pass example: 'I know nothing about this auth provider, do a blind spot pass to find my relevant unknowns and search my git diff/Slack for gotchas.' Brainstorm: 'I have no visual taste, make 4 wildly different dashboard designs so I can react.' Interview: 'Ask me questions prioritizing ones that would change the architecture.' References: 'Here's HTML mockup code, use it as a map for the React component.' Implementation notes: 'Log deviations when you hit unknowns.' Quiz: 'Test my understanding before I merge this.' | Caveat: These are templates, not rigid scripts; effectiveness depends on giving Claude 'context about you, the work, and the stage you're at.' No quantitative data on time savings or error reduction provided. | Implication: Ken should codify these six patterns as reusable agent prompts/workflows for discovery phases. Especially valuable when entering unfamiliar domains or when delegation scope is large. Treat these as 'pre-flight checks' before agentic execution. | Timestamp: 11:00
• Claim: Anthropic's internal culture is 'tradeoffs are not real'—rather than reasonably prioritizing among competing goals, attempt everything and force reality to show you actual constraints. | Evidence: Shihipar contrasts his YC startup habit of 'writing down priorities and reasonably choosing this quarter's focus' with Anthropic's approach: 'what if you just did all of it?' He created his entire conference deck in 4 hours with Fable and frames the new math as 'good, fast, cheap—pick three' instead of two. | Caveat: Shihipar acknowledges 'building is easier but generating value is still hard'—this isn't about making everything easy, just removing false constraints so you can take more swings at value generation. | Implication: Ken should audit his own implicit tradeoffs: what have you pre-ruled-out because 'it would take too long' or 'we can't do both'? Use agents to attempt the theoretically impossible and let reality (not reasonable planning) show you the real limits. This is a strategic posture shift, not just tactical prompting. | Timestamp: 18:45
• Claim: First-time use of Mythos-class models (Fable) induces both gain and grief: tasks that took weeks now take hours, but the craft of hand-coding and 'rotating the codebase in your mind' is lost. | Evidence: Shihipar revisited his YC startup codebase and realized weeks-long tasks are now hours-long. He loved 'seeing the code base in my mind and rotating it' but also 'remembers swimming in failure' and that 'most projects I've worked on have failed.' Concludes: 'I cannot go back.' | Caveat: This is personal reflection, not empirical data. Some engineers may not experience grief or may find new forms of craft in agent orchestration. No discussion of when hand-coding is still preferable. | Implication: Ken should expect psychological adjustment among himself and teams when adopting agentic coding—it's not just learning new tools but mourning old skills. Frame the transition as 'the only way out is through' (Shihipar's words) to acknowledge discomfort while committing to the shift. | Timestamp: 16:00

Detailed Brief

Unhobbling Claude: Understanding Capability Overhang and Model Evolution

• Claims: Models are 'grown not designed'—capabilities emerge organically from data/feedback/compute, not intentional feature design.; What constrains models is often the harness (prompts, tools, system design) imposed by human understanding, not the model itself.; Claude gets smarter in 'spiky ways' (capability overhang), not linearly—e.g., code execution tool suddenly enables complex reasoning tasks pure chat couldn't do.; Three major capability jumps: chat (context pasting) → Claude Code (bash/tools to build own context) → Claude Tag (proactive/multiplayer agents).; System prompt evolution: small prompt + few tools + many examples → large prompt + many tools + many examples → small prompt + few tools + minimal examples (because newer models are more imaginative than examples).; Ask_user_question tool evolved dramatically: barely callable in Opus 4 → 40-question interviews in 4.5 → full HTML report embedding in Fable.; Markdown/HTML output evolved: basic rich text → planning visualization for users → interactive HTML reports.
• Evidence: Pokémon AW example: 1000 Pokémon, only Croconaw and Dreadnaw end in AW. Chat models fail; Claude Code writes filter script and succeeds.; Anthropic removed 80% of Claude Code's system prompt recently because examples were constraining the model's native creativity.; Shihipar had to heavily tweak ask_user_question for Opus 4; by 4.5 it could handle 40-question interviews without changes; Fable embeds them in HTML.; Reference to Anthropic's 'Biology of a Large Language Model' paper as framework for understanding organic capability emergence.
• Caveats: Model behavior is empirical and closer to biology than physics—rules are discovered, not predetermined.; What works for Fable may not work for other models or even earlier Claude versions.; Capability overhang requires discovering which tools unlock which abilities—it's not automatic.; System prompt best practices are moving targets; no guarantee current patterns persist.
• Implications: Ken should treat model updates as opportunities to remove constraints (examples, system prompt bulk) rather than add them.; Instrument agents with diverse tools and test for non-obvious capability unlocks.; Build intuition empirically—spend time testing what the model can/can't do rather than relying on documented capabilities.; Revisit 'failed' features from earlier models; they may now work well.; Don't assume linear progress; expect discontinuous jumps in specific capability domains.

Finding Your Unknowns: Techniques for Mapping Territory vs. Map

• Claims: Map (your mental spec/prompt) vs. territory (actual constraints in codebase/world) mismatch creates unknowns—decision points you haven't specified.; Fable traverses much larger territory autonomously, so unspecified unknowns become bottleneck.; 2x2 matrix: known knowns (what you prompt), known unknowns (acknowledged gaps), unknown knowns (implicit 'know it when I see it' taste), unknown unknowns (unconsidered factors).; Blind spot passes: Ask Claude to audit unfamiliar domains for gotchas, pointing it to git diffs/Slack/docs for context.; Brainstorms/prototypes: Generate wildly different design options to surface unknown knowns (design preferences you can't articulate).; Interviews: Let Claude question you, prioritizing questions that would change architecture or key decisions.; References: Provide existing code/mockups as maps rather than writing specs from scratch—'give Claude another map.'; Implementation notes: Log deviations when Claude hits unknowns during execution so you can review and understand them.; Quizzes: Have Claude test your understanding of what happened before merging/shipping.
• Evidence: Blind spot pass example: 'I know nothing about this auth provider, help me figure out my relevant unknowns' + search git diff/Slack.; Brainstorm example: 'I have no visual taste, make me an HTML page with 4 wildly different design decisions so I can react.'; Interview prompt: 'Prioritize questions that would change the architecture.'; Reference example: 'If I'm making a React component, I might have an HTML mockup that is my map.'; Implementation notes: 'While running Fable, if it runs into an unknown, ask it to log it.'; Quiz: 'Get Fable to quiz me about what happened just to make sure I understand what I'm doing and can represent this work when creating a PR.'
• Caveats: These are templates requiring contextualization—'giving it context about you, the work, and the stage you're at' is critical.; No quantitative data on time savings, error rates, or success metrics provided.; Unclear what happens when Fable hits an unknown without guidance (does it stop, guess, hallucinate?).; These techniques assume Claude is good at meta-cognition (knowing what it doesn't know)—may not always surface true unknowns.
• Implications: Ken should codify these six patterns as reusable prompts/workflows for agent discovery phases.; Treat large delegations as multi-stage: discovery (blind spots, interviews, brainstorms) → execution → review (notes, quizzes).; Build a library of domain-specific 'blind spot' prompts for common areas (auth, payments, data pipelines, etc.).; Use references aggressively—show don't tell—to reduce specification burden and ambiguity.; Instrument agents to log deviations automatically for post-hoc review rather than relying on memory.

Dealing with Grief and Being Unreasonable: Mindset Shifts for Agentic Era

• Claims: First-time use of Mythos-class models induces grief: what took weeks now takes hours, but the craft of hand-coding is lost.; Pre-LLM coding 'feels like a foreign country'—constant forced tradeoffs because coding was hard.; Shihipar loved 'rotating the codebase in my mind' but also 'remembers swimming in failure'—most projects/startups fail.; Conclusion: 'I cannot go back' despite affection for the craft; 'the only way out is through.'; Anthropic's internal culture: 'tradeoffs are not real'—reject reasonable prioritization and attempt everything, forcing reality to show actual constraints.; The new math: 'good, fast, cheap—pick three' (instead of pick two).; Goal is to 'do the best work of our lives faster than ever before' while actually working less and spending more time with people.; Building is easier, but generating value is still hard—takes many swings to find what matters.; AI Engineer attendees are expected to prove agents work, not just talk about them.
• Evidence: Shihipar revisited his YC startup codebase (30 people, constant forced tradeoffs) and realized week-long tasks are now hour-long.; Made his entire conference deck in 4 hours with Fable the night before the talk.; At his previous company, he'd 'write down priorities and reasonably choose this quarter's focus'—now asks 'what if you just did all of it?'; Personal resolution: 'Be more productive but work less and spend more time with people I really care about.'
• Caveats: This is personal reflection and cultural observation, not empirical productivity data.; Some engineers may not experience grief or may find new forms of craft in agent orchestration.; No discussion of when hand-coding is still preferable or what skills remain valuable.; Generating value is explicitly called out as still hard—agents don't automatically solve product-market fit or strategic prioritization.; The 'prove it to the world' framing creates pressure but doesn't provide a roadmap for what proof looks like.
• Implications: Ken should expect and normalize psychological adjustment when adopting agentic workflows—it's not just tool learning but identity/craft mourning.; Frame the transition internally as 'the only way out is through' to acknowledge discomfort while committing forward.; Audit implicit tradeoffs: what have you pre-ruled-out as 'impossible' or 'would take too long'? Test those assumptions with agents.; Use agents to increase swing volume (more experiments, more prototypes, more bets) rather than just doing the same work faster.; Balance building ease with value discipline—just because you can build it doesn't mean you should; focus on value generation.; Set personal/team boundaries to avoid agent-enabled overwork—the goal is to work less, not just do more.

Notable Concepts & Terms

• Fable: Anthropic's new agentic coding model (Mythos-class) being rolled out at AI Engineer conference; represents a major capability jump requiring new operational patterns. Described as 'the map opening up' after the tutorial—enormous possibility but also confusion.
• Capability Overhang: Anthropic's term for latent model abilities that emerge when the right tools/harness are provided, not from model improvements alone. Models get smarter in spiky, non-linear ways (e.g., code execution suddenly unlocking complex reasoning).
• Unhobbling: Removing constraints (system prompt bulk, limiting examples, missing tools) that prevent models from using their full capabilities. Both the model and the operator (you) must be unhobbled to work effectively with Fable.
• Map vs. Territory: Distinction between your mental spec/prompt (the map) and the actual codebase/world constraints (the territory). Unknowns occur when Claude navigates territory not covered by your map.
• Unknowns Matrix: 2x2 framework: known knowns (what you prompt), known unknowns (acknowledged gaps), unknown knowns (implicit taste/judgment), unknown unknowns (unconsidered factors). Fable is bottlenecked by your ability to find and specify these.
• Blind Spot Pass: Technique where you ask Claude to audit an unfamiliar domain for gotchas/unknowns before execution, pointing it to git diffs, Slack, or docs for context. Used to surface known unknowns and unknown unknowns.
• Tradeoffs Are Not Real: Anthropic internal culture of rejecting reasonable prioritization and attempting everything simultaneously, forcing reality (not planning assumptions) to reveal actual constraints. Enables 'unreasonable' ambition.
• Context Not Constraints: Evolved system prompt philosophy for newer models: provide contextual framing rather than restrictive 'do not' rules or limiting examples. Models are more imaginative than constraining examples suggest.
• Claude Code: Anthropic's agentic coding product; gained 'arms' (bash tool, environment manipulation) to build its own context rather than relying on pasted code. Evolved from chat → proactive (Claude Tag) capabilities.
• Ask User Question Tool: Claude Code feature allowing the model to show multiple-choice dialogues or interview users. Evolved dramatically across model generations: barely usable in Opus 4 → 40-question interviews in 4.5 → HTML-embedded questions in Fable.

Operator Notes / Why Ken Should Care

• This is a rare insider view from Anthropic's Claude Code team on how to actually operate frontier agentic models—not just what they can do but how prompting/system design must evolve to unlock them.
• The 'unhobbling' frame is critical: Ken should audit his agent systems for over-constraining prompts (excessive examples, 'do not' rules) that may limit newer models. Consider removing rather than adding to system prompts.
• The six unknown-finding techniques (blind spot passes, interviews, brainstorms, references, implementation notes, quizzes) are immediately actionable workflows Ken can template into agent systems for discovery phases before large delegations.
• The system prompt evolution pattern (many examples → fewer examples because models surpass them) suggests Ken should version-control prompts and systematically A/B test prompt minimization with each model update.
• Fable's longer autonomous traversal means unknowns become bottleneck—Ken should invest in instrumentation (logging deviations, surfacing decision points) and multi-stage workflows (discovery → execution → review) rather than one-shot prompting.
• The 'tradeoffs are not real' culture is a strategic lens: Ken should use agents to test impossible-seeming combinations (speed + quality + breadth) and let reality show constraints, not pre-compromise based on pre-agent assumptions.
• The grief observation is operationally important: expect team adjustment when rolling out agentic coding. Frame it as 'the only way out is through' and focus on working less (not just doing more) to avoid burnout.
• Building ease ≠ value ease: Ken must maintain discipline around product strategy and value generation even as execution becomes trivial. Use agents to increase experiment velocity, not just build backlog faster.
• The talk itself was created in 4 hours with Fable (Shihipar's claim)—strong signal that content/deck generation is a high-value Fable use case Ken should test immediately.
• Watch for the 12:30 fireside chat mentioned (with Cat Woo and Simon Wilson) for additional Fable updates and operational details not covered in this talk.

Watch Map

• 00:00: Introduction, selfie tradition, Fable rollout announcement
• 01:30: Fable as 'the map opening up' metaphor; four-part structure overview
• 02:15: Part 1: Unhobbling Claude - models are grown not designed
• 03:20: Pokémon AW example: capability overhang via code execution tool
• 04:45: System prompt evolution: 80% removal, from examples to context
• 06:30: Ask_user_question tool progression across model generations
• 07:45: Markdown/HTML evolution; biology vs. physics framing
• 08:30: Part 2: Finding Your Unknowns - map vs. territory distinction
• 09:15: 2x2 unknowns matrix introduction (known/unknown knowns/unknowns)
• 10:00: Six techniques: blind spot passes, brainstorms, interviews
• 11:00: References, implementation notes, quizzes - staying in the loop
• 13:00: Part 3: Dealing with the Grief - pre-LLM coding as foreign country
• 16:00: YC startup revisit, weeks→hours, grief and gain, cannot go back
• 17:30: Part 4: Being Unreasonable - tradeoffs are not real culture
• 18:45: Pick three not two; do all of it, force reality to show constraints
• 20:00: Made deck in 4 hours; prove agents work; building vs. value generation
• 21:30: Closing: go explore, make it real, be less reasonable

Source/Metadata

• Title: Field Guide to Fable — Thariq Shihipar, Anthropic
• Transcript words: 4766
• Duration seconds: 1168
• Timestamp note: Timestamps derived from video duration (1168 seconds) and transcript structure; precise chapter markers not present in transcript but sections are clearly delineated by speaker transitions and topic shifts.