A Field Guide to Fable

Most launch-day talks are a demo with a heartbeat. This one is a manual. Thariq Shihipar works on Claude Code at Anthropic, and his brief at the AI Engineer World's Fair is unusually narrow: not what Fable is, but how you are supposed to hold it. He structures it in four parts — unhobbling Claude, finding your unknowns, dealing with the grief, and being unreasonable — and the middle two are the reason to watch.

The frameThe map is opening up

Shihipar's opening image is the one the whole talk hangs from. Fable, he says, is the moment an RPG stops being a tutorial: the open world unlocks, and the problem changes from can I do this to what do I even do now. It is a good metaphor precisely because it names the discomfort — a bigger map is not automatically a better afternoon.

"The best way to describe Fable to me is like the map is opening up. You were playing an RPG and you've been on the tutorial, and now you get to the point where the open world starts. And there's so much that you can do and explore. But there's also — it's also a little bit intimidating and confusing, right? Because there's so much you can do."Thariq Shihipar — 1:31

Part oneUnhobbling Claude

The premise: models are grown, not designed. Nobody at Anthropic wakes up and decides to build a 99%-on-SWE-bench model; they feed it data, compute and feedback and then find out what they made. Which means the ceiling you experience is not the model's ceiling — it's yours.

"What contains them is us. The harness we put them in and the way we prompt them is basically a function of our understanding of Claude. And by unhobbling it, I mean: how can we understand Claude better to unleash it?"Thariq Shihipar — 3:08

His demonstration is a viral tweet: why can't LLMs tell you which Pokémon end in "aw"? There are roughly a thousand Pokémon and exactly two — Croconaw and Drednaw. A chat model, which plainly knows every Pokémon name, reliably fails. Claude Code succeeds, because it doesn't try to remember. It fetches the list and writes a script to filter it.

He calls the gap capability overhang: ability the model already has, locked behind a harness that never gave it a way to use it. Claude, in his phrase, gets smarter in spiky ways — not uniformly better, but suddenly and enormously better at one specific shape of problem the moment you hand it the right tool.

Part one, continuedThe system prompt is getting shorter

This is the most concrete, checkable, immediately useful claim in the talk, and it inverts two years of accumulated folk wisdom. Prompt engineering went from small prompt, few tools, many examples (the Sonnet 3.5 era), to large prompt, many examples, many tools as instruction-following improved. Fable-class models, he says, want the opposite of where that trend was heading.

"We found this new class of models want a smaller system prompt. The examples tend to constrain it, because it's actually more imaginative than the examples we give it. And we tried to give it context and not just constraints — we're really trying to avoid being like, 'do not do this.' Which was really necessary for the previous models."Thariq Shihipar — 6:35

Read that twice if you maintain a prompt. The examples you added to help are now a ceiling, and the prohibitions you added to protect are now a cage. The instruction is to supply context and withhold constraint — which is a much harder discipline than it sounds, because every "do not" in your prompt is there as a scar from a real incident.

He runs the same arc through two other features. The AskUserQuestion tool, which he built, went from a model that could barely be made to call it under Opus 4, to one that would conduct a forty-question interview about a spec under Opus 4.5, to one that now builds an entire HTML report with the questions embedded inside it. Markdown made the same journey: output for the model, then output for you, then full HTML reports you make decisions from.

"I really like to emphasize that this is closer to a biology than a physics. It's still very empirical, very organic. We don't know all the rules, but there is some sort of science behind it. There is an intuition to build."Thariq Shihipar — 8:17

Part twoFinding your unknowns

This is the best section of the talk and the one to actually take notes on. The frame is Korzybski by way of a coding agent: the map is not the territory. Your prompt, your spec, your plan — that's the map. The codebase, the real constraints, the thing Claude actually has to walk through — that's the territory. Every place they fail to line up is what he calls an unknown: a decision point you didn't specify, which the model will now resolve on your behalf, silently.

And here is why that suddenly matters more than it used to: a more capable model covers more ground, so it encounters proportionally more of your unspecified decisions. Capability converts your vagueness into consequences faster.

"Fable is one of the first models where I felt like I really have to figure out my unknowns — because if not, it's going to traverse such a large area that it's going to run into a lot of them."Thariq Shihipar — 9:44

The payoff is six concrete moves, each one a prompt he actually uses. These are reproduced verbatim from his slides.

He notes he's used this outside code entirely — most recently to learn colour grading for video editing. The underlying observation is blunt: the model knows more about nearly everything than he does, and the job is getting it out.

This is the fix for know-it-when-I-see-it taste. You cannot write down the thing you can't articulate, so you generate a spread and let your reaction do the specifying.

The second clause is the whole trick. Without it you get twenty questions of even weight; with it you get the four that matter.

His framing: the best way to give Claude a map is to hand it a different map. Existing code in another language, an HTML mockup standing in for a React component — anything that pins down intent more precisely than your prose was going to.

The elegant part is that it doesn't stop the run. The model resolves the unknown, records that it did, and continues — and you get an audit trail of exactly where your map failed, which is precisely the list you needed.

Note the inversion: every other move interrogates the model. This one interrogates you, before you put your name on a pull request you did not write.

Part threeThe grief

Then the talk does something vendor talks do not do. Shihipar says that the first time he used Fable he felt a huge sense of gain and a sense of loss, and he spends three minutes on the loss.

He ran a roughly thirty-person YC startup between 2019 and 2024. He went back to that codebase a few weeks ago and found the things that would have taken weeks now took hours. He is not smug about it.

"I really, really loved programming and writing code by hand. I love the feeling of seeing the code base in my mind and rotating it. But I also remember staying up late nights trying to debug, working on things for weeks without working. I just remember swimming in failure — most of the projects I've ever worked on have failed. Most startups go bankrupt."Thariq Shihipar — 15:31

The resolution he offers is not get over it. It's that the nostalgia and the exhaustion are both true, and that having felt both, he can't go back.

Whatever you make of the rest of the talk, this passage is worth the nineteen minutes on its own. It is the only moment on a 2026 keynote stage where someone selling you an agent concedes that something is being lost — and declines to pretend the trade is free.

Part fourBeing unreasonable

The close is a culture pitch, and it's where the talk is most exposed. Anthropic, he says, believes tradeoffs are not real. At his previous company he'd rank priorities and cut down the list, like a reasonable person. The new posture is to refuse the ranking and force reality to prove the tradeoff exists.

"What if you just did all of it? What if you forced reality to show you the tradeoff? […] There are so many tradeoffs that you make implicitly in your head — like good, fast, cheap. Now it's pick three."Thariq Shihipar — 17:00

To his credit, he backs the ambition with an artifact: the deck he's presenting was, he says, made the night before in about four hours with Fable. And his stated resolution is not ship more — it's to be more productive, work less, and spend the time with people he cares about. That's a more interesting thing to say from that stage than "10x your output."

"I think the only way to prove that agents work is to do the best work of our lives — faster than ever before."Thariq Shihipar — 17:42

He ends in three imperatives: go explore, make it real, be less reasonable.

Reading it straightWhat to keep, what to discount

Keep: the six prompts, verbatim. The "remove 80% of your system prompt" instruction, which is testable on your own harness this week and costs nothing to try. The unknown matrix as a pre-flight checklist. And the implementation-notes pattern, which is the cheapest way to find out where your specs are actually thin.

Discount: the economics. This is an Anthropic engineer presenting Anthropic's model on the morning it ships — he says so in the first minute, and there's a fireside chat about it at 12:30. Nineteen minutes pass without a benchmark, a cost, a latency figure, a regression, or a single example of Fable doing something wrong. Every anecdote is a success. That's not a lie; it's a genre, and the genre has a known bias. The craft in part two is good enough that it doesn't need the triumphalism in part four — and would be more persuasive without it.

The talk's own best idea is the one that survives the sales pitch: if what contains the model is us, then the interesting engineering work is no longer prompting harder. It's noticing what you failed to say.