Source: https://www.youtube.com/watch?v=4sX_He5c4sI Segment: 00:16:31–00:35:41 Speaker: Tariq Shihipar, Anthropic / Claude Code Topic: A field guide to working with Anthropic's Fable / newer Claude-class coding models
Fable is presented as a step-change model: not merely a little better, but a model that opens up a wider “map” of what is possible. The main challenge is no longer only model capability; it is learning how to stop constraining the model with old habits, old prompts, overly rigid harnesses, and low-ambition tradeoff assumptions.
The speaker’s framing is: to get value from Fable, you need to:
- Unhobble Claude.
- Find your unknowns.
- Deal with the grief of losing the old way of coding.
- Be less reasonable / more ambitious.
Tariq is introduced as Anthropic technical staff working on Claude Code. He opens with a Claude Code team tradition: taking a selfie with the audience before a talk.
He says “Fable is back” and that Anthropic is rolling it out later that day, with more updates possibly coming in a 12:30 fireside chat with Cat Woo and Simon Wilson.
He describes Fable as one of those Anthropic models people will remember, alongside memorable prior models like Sonnet 3.5 new, Opus 4, and Opus 4.5. The metaphor he uses is an RPG where the tutorial is over and the open-world map suddenly opens. There is much more to explore, but that also makes it intimidating and confusing.
His goal for the talk is to give a “field guide” for working with this new class of models.
The first section is about “unhobbling Claude”: understanding what currently limits the model and how to unlock more of its latent capability.
He argues that models are “grown, not designed.” Anthropic does not simply decide a target behavior like “99% on SWE-bench” and engineer that directly. Instead, models are shaped through data, feedback, and compute, then researchers and users empirically discover how they behave.
Because of that, what contains or limits the model is often the harness around it: the tools, product environment, system prompt, interaction design, and the user’s own understanding of how to work with it. If you understand Claude better, you can unleash more of it.
He says we are still early in understanding Fable, and there is more to unlock.
He gives an example of “capability overhang.” A viral prompt asked why an LLM could not name which Pokémon names end in “aw.” A normal chat model may fail despite “knowing” Pokémon names. But Claude Code can solve it by fetching a full Pokémon list and writing a script to filter names.
The point: the model did not become smarter by memorizing the answer. It became effectively smarter because the environment gave it arms: code execution, fetching, filtering, and a way to construct its own reliable context.
This is the kind of spiky improvement he means by capability overhang. The same base intelligence can look much more capable when placed in the right loop with the right tools.
For Fable, the open question is: what new capability overhangs are now possible?
He describes a progression in coding workflows.
At first, chat models needed users to provide context manually. A naive assumption was that the path to better coding would be bigger and bigger context windows, until you could paste an entire codebase.
Claude Code’s key insight was different: instead of stuffing all context into the prompt, give the model tools — bash, file search, environment access — so it can build, inspect, and refresh its own context.
Then Anthropic rolled out Claude Tag, which adds a further step: proactive and multiplayer work. Claude Code is something you prompt directly; Claude Tag suggests a model that can wake itself up and work in the background or alongside people. Tariq sees that as part of the next wave of agents.
He says Anthropic recently removed about 80% of Claude Code’s system prompt.
Older models benefited from small prompts, few tools, and many examples. Then as models got smarter, they could absorb larger system prompts, more tools, and more instructions. But with the newest class of models, Anthropic found that large prompts and examples can constrain the model, because the model may be more imaginative than the examples.
The shift is toward giving context rather than piling on constraints. Instead of many “do not do X” rules, the system should help the model understand the situation and goal. System prompting will keep changing as models change.
He discusses an “ask user question” tool he worked on in Claude Code. The tool lets Claude show a multiple-choice question/dialogue when it is planning or needs information.
With Opus 4, the model could barely call the tool reliably, so the tool had to be heavily adjusted. By Opus 4.5, Claude could interview him with dozens of spec questions. By Opus 4.8 and Fable, it could build an HTML report with questions embedded inside it.
The broader lesson: the model’s ability to gather information from the user has itself evolved into a richer interaction pattern. It is not just answering; it can interview, structure uncertainty, and build interfaces for clarification.
He makes a similar point about output formats.
Markdown started as a useful richer-than-plain-text format. Then, with planning modes, markdown became a way for the user to see what Claude intended to do. Now, newer models can create detailed HTML reports, turning output into a more interactive, inspectable artifact.
He emphasizes that model behavior is closer to biology than physics: empirical, organic, not fully rule-bound. There is still a science to it and intuition to build, but you discover behavior by working with the model.
He recommends Anthropic’s “biology of a large language model” paper as a good way to build that intuition.
After unhobbling Claude, he says you also need to “unhobble yourself.” His key idea is “the map is not the territory.”
When working on a coding task, your prompt, plan, or spec is the map. The actual codebase, real-world constraints, dependencies, product realities, and edge cases are the territory. Whenever Claude reaches something in the territory that was not represented in your map, that is an unknown: a decision point you did not specify.
Fable can traverse much more of the territory than older models, so it hits more unknowns. That means the user becomes bottlenecked by their ability to identify and resolve unknowns.
He frames unknowns in a matrix:
- Known knowns: things you know and usually put in the prompt.
- Known unknowns: things you know you still need to figure out.
- Unknown knowns: tacit assumptions or taste you know when you see but would not naturally write down.
- Unknown unknowns: things you have not considered at all, but that could change how you prompt or solve the problem.
The good news: you can use Fable itself to find these unknowns.
His first tactic is asking Fable for a “blind spot pass.”
Example prompt pattern: “I’m working on a new OAuth provider in this codebase and know nothing about it. Can you do a blind spot pass to help me find relevant unknown unknowns and help me prompt better?”
The model can inspect the relevant module, identify hairy dead ends, search git diffs or Slack if those are available, and surface gotchas before the user writes a detailed implementation prompt.
He says this is broadly useful, not only for code. He used it for color grading in video editing: ask the model to teach you what you do not know about a new field.
The second tactic is using brainstorms/prototypes to discover “unknown knowns,” especially taste.
For design work, he may ask Fable to build an HTML page with four wildly different design directions so he can react to them. The point is to externalize options. Some preferences cannot be described upfront, but become obvious when you see alternatives.
This is a way to turn tacit taste into explicit guidance.
Once he has a rough idea of what he wants, he asks Claude to interview him. He recommends giving context about the work and current stage, and telling the model what kinds of questions matter.
Example: prioritize questions that would change the architecture.
This helps surface unspecified decisions before they become wrong implementation choices.
Another way to give Claude a map is to provide another map: reference code, a mockup, or an implementation in another language/system.
Instead of fully writing a spec, you can say: here is code that represents the behavior I want; read it, understand it, and use it to guide the new implementation.
For UI work, an HTML mockup can serve as the map for a React component. Fable is especially strong at using such references.
While Fable is working, ask it to log implementation notes when it runs into unknowns or makes deviations. That gives you a record of where reality diverged from the original map.
Afterward, ask Fable to quiz you on what happened. This helps ensure you understand the result well enough to review it, merge it, or explain it in a PR.
His broader principle: stay in the loop. Fable can do much more, but the user still needs to understand and steer.
He says the first time he used a mythos-class model / Fable, he felt a huge sense of gain and also a sense of loss.
Pre-LLM coding feels to him like a foreign country. He used to run a YC startup of about 30 people, and the team was constantly forced into painful tradeoffs because code was hard. Making the app fast, prototyping features, or building product improvements could take weeks or months.
When he recently returned to that old codebase, things that would have taken weeks could now be done in hours.
That creates both joy and grief. He loved programming by hand: the feeling of holding the codebase in his mind and rotating it. But he also remembers late nights debugging, projects failing, startups going bankrupt, and swimming in failure.
His conclusion: you cannot go back. The only way out is through. There is still much to learn, and staying in the loop with Fable is how to come out the other side with more.
The final section is about ambition.
He says one of his favorite parts of Anthropic culture is the belief that tradeoffs are not real, or at least that you should not accept them too early. In a previous company, he was used to being reasonable: listing priorities and choosing what to defer. Anthropic’s posture is more like: what if you did all of it? Force reality to show you the tradeoff instead of assuming it upfront.
He says Fable changes the math of tradeoffs. Many good/fast/cheap assumptions are implicit in your head, but with better agents, you should re-check them. His updated slogan is effectively: good, fast, cheap — pick three.
To prove agents work, AI engineers need to do the best work of their lives faster than before.
He gives the example that he made the talk deck the previous night in about four hours with Fable, liked the result, and enjoyed the process.
He argues that people at AI Engineer are being watched to prove AI is not a fad: to show that it can make people more productive and also save time.
His personal resolution is to be more productive, work less, and spend more time with people he cares about.
He adds an important caveat: building is easier, but generating value is still hard. AI engineers can obsess over process, tools, and setups, but the point is value. Finding valuable work still takes many swings and many attempts.
He closes with: go explore, make it real, and be less reasonable.
- Do not evaluate a model only as a chat box. Its capability depends on its tools, harness, product loop, and context-building ability.
- Newer models may need less prescriptive prompting, fewer examples, and more situational context.
- Use the model before the task to find blind spots, not just during implementation.
- Ask for prototypes when you cannot articulate taste or direction.
- Ask the model to interview you when architectural or product unknowns matter.
- Give references: code, mockups, artifacts, examples in other languages.
- Ask the model to log deviations/unknowns while working.
- Ask it to quiz you afterward so you can actually own the result.
- Expect emotional friction: the old craft changes, but the old pain also goes away.
- Revisit assumed tradeoffs; with stronger agents, some “reasonable” limits are just stale habits.
- Building faster is not the same as creating value; use the speedup to take more shots at valuable outcomes.
Fable makes Claude feel less like a better autocomplete and more like an open-world collaborator; the winning move is to stop constraining it with old maps, use it to discover unknowns, stay in the loop, and raise ambition until reality — not habit — proves the tradeoff.