# Field Guide to Fable

Thariq Shihipar, Anthropic | AI Engineer World's Fair 2026 | 19:28

Source: https://www.youtube.com/watch?v=9fubhllmsBU
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/field-guide-to-fable
Published: 2026-07-06
Tags: agents, coding-agents, human-in-the-loop, prompt-engineering, tool-use

## TL;DR
- Fable's abilities depend on the tools and prompts around it, so teams need to discover what the model can do instead of assuming its limits.
- Engineers can use Fable to find missing requirements through blind-spot passes, prototypes, interviews, reference code, implementation notes, and quizzes.
- Fable changes the economics of coding enough that teams should ask for work that is good, fast, and cheap, while remembering that generating value remains difficult.

## Summary
Thariq Shihipar presents Fable as a model whose capabilities appear in uneven spikes. A chat model may know every Pokemon name yet fail to find the names ending in "aw". Claude Code can solve the task by fetching the list and running a filter. Tools, prompts, and interaction patterns determine which abilities are reachable. Shihipar explains how Anthropic reduced Claude Code's system prompt by 80 percent, how Fable can create HTML questionnaires, and how engineers can use blind-spot reviews, prototypes, interviews, references, and implementation notes to find missing requirements. He also describes the emotional effect of coding becoming much faster. Work that once took weeks can take hours, but the loss of hand-written programming is real. His final argument is to demand good, fast, and cheap work together, while staying focused on value rather than the ease of building.

## Key ideas
### Fable opens a larger space of possible work
[00:45](https://www.youtube.com/watch?v=9fubhllmsBU&t=45s)
Thariq Shihipar describes Fable as the moment in an RPG when the tutorial ends and the open world begins. There is much more to explore, but the wider space is also intimidating because the model can do things users have not learned to ask for yet. He frames the talk as a field guide with four parts: unhobbling Claude, finding unknowns, dealing with the grief that comes with easier coding, and being unreasonable about tradeoffs. The central problem is learning how to work with a new class of model rather than treating it like a slightly improved version of an older one.

### Tools expose abilities that a chat model cannot reach by itself
[02:32](https://www.youtube.com/watch?v=9fubhllmsBU&t=152s)
The Pokemon example illustrates what Shihipar calls capability overhang. A normal chat model can know the Pokemon names but fail to answer which ones end in "aw". Claude Code fetches the full list and writes a script to filter it, finding Croconaw and Drednaw. The difference comes from giving the model code execution and access to an environment. Shihipar says models become smarter in spiky ways. Claude Code similarly became useful when it could build and search its own context with tools such as bash, rather than relying on a huge pasted codebase.

### Smarter models need less instruction and more room to act
[05:32](https://www.youtube.com/watch?v=9fubhllmsBU&t=332s)
Shihipar says Anthropic removed 80 percent of Claude Code's system prompt. Earlier models benefited from many instructions, examples, and tools. With newer models, examples can constrain behavior because the model is more imaginative than the examples supplied. The team therefore tries to give Claude context rather than a long list of prohibitions. He gives the ask-user-question tool as another example of changing behavior. Opus 4 could barely call it, later models could interview a user with many questions, and Fable can generate an HTML report with embedded questions. Markdown, plan mode, and HTML reports show the same progression.

### The main limit is often the engineer's incomplete map
[09:04](https://www.youtube.com/watch?v=9fubhllmsBU&t=544s)
Shihipar separates the map from the territory. The map is the plan, prompt, and specification in the engineer's head. The territory is the real codebase, its constraints, and the environment Claude must change. An unknown appears when Claude reaches something in the territory that the map did not specify. He divides these gaps into known knowns, known unknowns, unknown knowns, and unknown unknowns. Fable makes this problem more visible because it can travel through a larger area and encounter more decisions that the prompt did not cover.

### Fable can help discover requirements before implementation
[10:46](https://www.youtube.com/watch?v=9fubhllmsBU&t=646s)
Shihipar uses several methods to expose missing information. A blind-spot pass asks Fable to inspect an unfamiliar module and identify gotchas, using sources such as a Git diff or Slack for context. Brainstorms and prototypes can create several very different HTML designs when the user cannot describe their visual preferences. Interviews turn vague requirements into questions, especially when the model is told to prioritize decisions that could change the architecture. Reference code gives Claude another map, even when it comes from another system or language. These methods shift work from writing a complete specification alone to learning what the specification is missing.

### Staying in the loop matters when the model does more work
[13:37](https://www.youtube.com/watch?v=9fubhllmsBU&t=817s)
Shihipar recommends asking Fable to log the unknowns it encounters during implementation. The resulting notes show where the work deviated and provide context for why. He also asks Fable to quiz him about the completed work so he can understand and explain it during a pull request or merge. This keeps the engineer connected to the decisions made by the model. His advice assumes that faster implementation can otherwise leave the user with less understanding of the resulting code.

### Much faster coding brings both relief and loss
[14:29](https://www.youtube.com/watch?v=9fubhllmsBU&t=869s)
When Shihipar revisited code from a former 30-person startup, tasks that had once taken weeks could be completed in hours. He remembers the old tradeoffs, late-night debugging, and projects that failed, along with the pleasure of holding a codebase in his mind and writing code by hand. The speed of Fable creates a sense of gain and loss at the same time. He says he cannot go back to the old process, although there is still much to learn about working with these models. His answer is to stay engaged and work through the change rather than resist it.

### Teams should demand good, fast, and cheap work together
[16:30](https://www.youtube.com/watch?v=9fubhllmsBU&t=990s)
Shihipar calls this final principle being unreasonable. At his previous company, he was used to ranking priorities and accepting a tradeoff between them. Anthropic's culture encouraged him to ask what would happen if the team tried to do everything and forced reality to reveal the actual limits. He says the economics of Claude and Fable change the familiar good, fast, cheap choice: teams can ask for all three. He made the talk's deck in about four hours with Fable. He also warns that easier building does not make value automatic. Finding valuable work still takes many attempts.

## Notable quotes
- "Claude gets smarter in spiky ways." (04:16)
- "The map is not the territory." (09:04)
- "I felt both a huge sense of gain, but also a sense of loss." (14:18)
- "Good, fast, cheap. Now it's pick three." (17:27)

## Tools & references mentioned
- Fable
- Claude Code
- Anthropic
- Claude
- Opus 4
- Opus 4.5
- Opus 4.8
- Sonnet 3.5 New
- Claude Tag
- The Biology of a Large Language Model
- Croconaw
- Drednaw
- AI Engineer

## Who should watch
- You are building coding agents and need to work out which tools, prompts, and interaction patterns let a model use its abilities.
- Your requirements are incomplete, or you regularly discover architecture and design decisions only after implementation starts.
- You want to increase development speed without losing track of what the model changed or accepting the usual tradeoffs between quality, speed, and cost.