AI Engineer World's Fair 2026
Field Guide to Fable
Read the talk
A Field Guide to Fable: Uncover Capability, Surface Unknowns, and Rethink Engineering Tradeoffs
Thariq Shihipar explains how Fable changes agentic coding: better tools and lighter constraints expose latent capabilities, deliberate discovery keeps humans informed, and faster implementation makes ambitious work possible without making value creation automatic.
From a talk by Thariq Shihipar
At a glance
Ideas worth remembering
Capability overhang emerges when a model can accomplish more with the right harness, environmental access, and code execution than it can through unsupported conversation alone. 3:06
Reevaluate prompts and tools as models change: newer systems may benefit from fewer examples, fewer restrictive instructions, and more useful context. 5:14
Use the map-versus-territory framework to distinguish explicit requirements, recognized uncertainties, unstated assumptions, and issues nobody has considered. 8:33
Surface missing information through blind spot passes, contrasting prototypes, targeted interviews, and concrete reference implementations. 10:38
Maintain human accountability with implementation notes that document unexpected decisions and follow-up quizzes that verify understanding before a PR is created or merged. 13:31
Challenge assumed engineering tradeoffs, but do not confuse faster building with value creation, which still requires experimentation and judgment. 15:39
Model capability depends on the environment around it
Thariq Shihipar, who works on Claude Code at Anthropic, frames Fable as an opening of possibilities that can feel exciting and disorienting. His field guide organizes that challenge around four ideas: unhobbling Claude, identifying unknowns, confronting the emotional consequences of changing how we code, and becoming less willing to accept inherited assumptions about tradeoffs. 0:33
His starting point is that models are developed through data, feedback, and compute, while their practical behavior is also shaped by the harness and prompts surrounding them. Those surrounding choices encode our current understanding of the model, which means they can limit what it can accomplish. Improving the harness is therefore not merely a usability exercise: it can expose abilities that existing interaction patterns leave inaccessible. 1:46
Shihipar calls the mismatch between latent and accessible ability capability overhang. In his example, a chat model struggles with a constrained question about Pokémon names, while Claude Code can fetch the relevant names, write a script, and filter them. The important mechanism is not perfect recall inside a conversation; it is the combination of a model with tools that let it gather evidence and execute a reliable procedure. 3:06
The same distinction applies to coding. Instead of assuming progress requires a context window large enough to contain an entire codebase, Claude Code can use bash and environmental access to search for and assemble its own working context. Shihipar also points to proactive, multiplayer work in Claude Tag as another change in the interaction model, distinguishing agents that can initiate work from systems that act only after a user prompt. 4:13
Find Pokémon names ending in AW
Tool access converts a constrained naming question into an executable retrieval-and-filtering workflow.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Update the harness as the model changes
A harness that helped one generation can become restrictive for the next. Shihipar says the Claude Code team recently removed 80 percent of its system prompt, describing a progression from small prompts with few tools, to larger prompts with extensive instructions and examples, and then back toward smaller prompts for newer models. The practical lesson is to reevaluate scaffolding against observed behavior rather than preserve it simply because it previously worked. 5:14
For this newer class of models, examples can narrow the space of possible solutions because the model may be more imaginative than the examples supplied to it. Shihipar recommends providing context rather than excessive constraints and avoiding blanket prohibitions that earlier models needed. This is not a claim that all structure is unnecessary; it is an argument that the useful balance between instructions, examples, and freedom changes as capabilities change. 6:22
The evolution of the ask user question tool illustrates how interaction patterns can expand unevenly. Shihipar says Opus 4 struggled to call the tool reliably, Opus 4.5 could interview a user about a specification, and Opus 4.8 and Fable could generate an HTML report with embedded questions. Outputs likewise progressed from Markdown, to plans intended for human understanding, to more detailed HTML reports. 6:22
Shihipar describes this process as closer to biology than physics: empirical and organic, with useful intuitions but without a complete set of established rules. That characterization places a limit on prescriptive guidance. Engineers should expect to discover effective interfaces through experimentation with actual model behavior rather than assume a single permanent prompting formula. 7:26
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Find the gaps between the specification and reality
Shihipar distinguishes the map from the territory. The map is the prompt, plan, or specification in the developer’s mind; the territory is the real codebase and its constraints. An unknown appears whenever the agent encounters a decision point in the territory that the map did not describe, and a more capable agent can encounter more such decisions precisely because it can traverse a larger problem space. 8:33
He groups these gaps into known knowns, known unknowns, unknown knowns, and unknown unknowns. Known knowns generally appear in the prompt; known unknowns are recognized but unresolved questions; unknown knowns are assumptions or preferences that feel too obvious to write down; and unknown unknowns are considerations that have not entered the developer’s thinking at all. This framework shifts the bottleneck from merely producing code to identifying which decisions the agent cannot safely infer from an incomplete specification. 9:34
One practical technique is a blind spot pass. Before working with an unfamiliar authentication provider, for example, Shihipar suggests having the model inspect relevant modules and available contextual sources, such as a Git diff or Slack, to uncover recurring pitfalls and missing knowledge. He presents the same approach as useful beyond software, including learning about color grading for video editing. 10:38
For preferences that are easier to recognize than articulate, Shihipar recommends brainstorms and prototypes. A model can create an HTML page presenting four substantially different dashboard design directions, giving the developer concrete alternatives to react to. The mechanism is not that the model magically knows the desired design; it helps transform tacit preferences into explicit guidance through comparison. 11:36
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the human informed before, during, and after implementation
Once an initial direction exists, Shihipar recommends having the model conduct an interview to uncover decisions that remain unspecified. Supplying context about the person, the work, and the project’s current stage improves the usefulness of the questions, and directing the interview toward decisions that could change the architecture makes the exchange more consequential than a generic requirements checklist. 11:36
A second technique is to provide references rather than rely exclusively on a written specification. Existing code can communicate the intended behavior even when it comes from another system or programming language, while an HTML mockup can serve as a reference for a React component. These artifacts give the model another representation of the intended destination and can reduce ambiguity that prose leaves unresolved. 12:39
During implementation, Shihipar suggests asking Fable to record implementation notes whenever it encounters an unknown. Those notes reveal where the work diverged from the original map and provide context for understanding why the deviation occurred. Logging decisions does not eliminate uncertainty, but it makes consequential judgment calls more visible to the human responsible for the result. 13:31
Afterward, he recommends having the model quiz the developer about what happened. This helps the human understand and represent the work when creating or merging a PR, rather than treating a completed implementation as sufficient evidence of comprehension. Across interviews, references, implementation notes, and quizzes, the consistent principle is to remain in the loop as the agent becomes capable of doing more independently. 13:31
Surface architecture-changing decisions
Clarify architectural decisions, ground the work in references, document unknowns, and verify understanding afterward.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Acknowledge the loss, challenge assumptions, and measure value
Shihipar does not present the shift to agentic coding as an uncomplicated gain. Looking back at a startup he previously ran, he recalls being forced to choose between improvements such as application speed and new features because implementation could take months. Revisiting the codebase with newer tools, he found that work he believed would previously have taken weeks could be completed in hours, while also feeling grief over the changing role of writing code by hand and mentally holding an entire codebase together. 14:40
That grief sits alongside memories of late-night debugging, prolonged failed efforts, and the difficulty of building software and startups. His response is neither to deny the attachment to traditional programming nor to claim that agentic coding has already solved every problem. Instead, he argues that there is still much to learn and that progress depends on understanding the model’s capabilities while maintaining human involvement. 15:39
His final recommendation is to be less reasonable about inherited assumptions. Rather than immediately accepting a familiar prioritization tradeoff, teams can test whether better tools allow more objectives to be pursued together and force the actual constraint to reveal itself. As one personal example, Shihipar says he created the presentation deck in approximately four hours with Fable and was pleased with both the result and the speed. 15:39
However, faster implementation is not the same as a successful product or meaningful impact. Shihipar explicitly distinguishes building more easily from generating value, which he says remains difficult and often requires many attempts. His broader ambition combines more productive work with less time spent working and more time with people he cares about, making the ultimate test of agentic tools their contribution to valuable outcomes rather than the novelty of the workflow itself. 16:56
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the complete timestamped transcript
- 0:00
[upbeat music] Please welcome to the stage member of technical staff at Anthropic, Thariq Shihipar. [upbeat music]
- 0:33
Hey, everyone. I'm Thariq. Uh, I work at Anthropic on Claude Code. Uh, before we get started, we l- have a tradition on Claude Code where, uh, we take a selfie before a talk.
- 0:42
So if you don't mind, if you strike a pose with me, I'll, uh, take a quick selfie at AI Engineer. [audience cheering]
- 0:50
Okay, incredible. Well, uh, yeah, to kick things off, like we said, Fable is back. Um. [chuckles] [audience cheering]
- 1:00
We're rolling it out later today. Uh, ke- stay tuned for exact timeline. Me and Cat Wu and Simon Willison will be doing a fireside chat at twelve thirty. We might have some updates for you then.
- 1:13
Um, but Fable is a model I'm just so, so excited about. It's one of those Anthropic models where you just like, you're just gonna remember it. Like, Sonnet 3.5 new, Opus 4, Opus 4.5.
- 1:27
It's a model that I just have a lot of, like, affection and excitement for. And the best way to describe Fable to me is, like, the, the map is opening up, you know?
- 1:37
Like, you are playing, like, an RPG, and you've been on the tutorial, and now you get to the point where the, like, you know, the open world starts, right?
- 1:46
And there's so much that you can do and explore, uh, but there's also-- it's also a little bit intimidating and confusing, right, 'cause there's so much you can do.
- 1:56
And so what I wanted to do in this talk is give you guys a field guide to Fable, right? How do you work with this new class of models?
- 2:07
So I've got four parts to it. I've been working on this as a series of articles and blog posts, uh, but, you know, when we announced Fable was coming out, I was like, "Okay, let me do, uh, all of this at once at the talk," uh, you know, uh, speed run.
- 2:24
So there are four parts: unhobbling Claude, finding your unknowns, dealing with the grief, and being unreasonable. So first, unhobbling Claude. Um, I think something we say really often is that the models are grown, not designed, right?
- 2:44
We don't wake up and be like, "We need ninety-nine percent on SWE-bench," right? Like, the models are, you know, something we, we grow carefully. We give it data and feedback and compute.
- 2:55
Um, but ultimately, it's, you know, something that we-- it's a little bit organic, and we sort of figure out and learn with the model as we use it. And so, um, that, what that also means is that what contains them is us, right?
- 3:11
The harness we put them in and the way we prompt them is basically, like, a function of our understanding of Claude, right? And by unhobbling it, I mean, how can we understand Claude better to unleash it?
- 3:25
And we need to understand Fable more. So I think one of my points is that, you know, uh, we're still so early, and I think there's a lot more understanding in Fable, uh, to unlock.
- 3:39
And, uh, [laughs] I think I'll give you a quick example about how models get smarter 'cause it's a little bit unintuitive, right? Like, there-- I saw this viral tweet a couple weeks ago being like, you know, "Why can't LLMs say which Pokémon end in A-W?"
- 3:54
There are a thousand Pokémon, right, and turns out there are two who, whose names end in A-W: Croconaw and Drednaw, right? And it turns out if you ask, like, a normal chat model, it can't answer it, which is kind of confusing because, like, you know, it definitely knows all the names of the Pokémon, right?
- 4:10
But if you, uh, ask Claude Code, it can, right? 'Cause what it does is that it fetches every Pokémon and writes a script to filter for A-W, right? And so this is what I mean by, like, unhobbling Claude.
- 4:26
We call this capability overhang, right? Claude gets smarter in spiky ways. So it doesn't just remember every Pokémon and reason through it. But if you give it the code execution tool, it can find the two Pokémon that end with A-W, right?
- 4:41
And so this is, I think, part of the challenge with Fable is figuring out this capability overhang. What is now possible? And I think this is, like, a discovery that I'm excited to go on with you.
- 4:50
Uh, to make this a little bit clearer, I'm gonna talk about a few different examples of how models have progressed in the past. Um, one of the big examples obviously is, like, chat.
- 5:01
You know, the chat models were f- had to be given context, right? Like, maybe you paste in your code base and maybe naively you might have thought, like, you know, the way we solve coding is by the context just gets really large, and I can just paste in my entire code base.
- 5:14
You know, it'll be a hundred million context window. But it turns out that instead, if you give it arms, like you give it the Bash tool and ways to work with the environment, it can build and search its own context, and that's sort of like the insight that led to Claude Code, right?
- 5:29
And so again, spiky, like a new, like, innovation kind of, right, in how we w- think about and work with the model. And then recently we, we rolled out Claude Tag, uh, and what sort of unlocked Claude Tag is its ability to work proactively and multiplayer.
- 5:45
Uh, Claude Code, you know, is something that you have to prompt for it to do work, right? And, uh, this ability for Claude to wake itself up and do work is something that we think is unlocking the new wave of agents.
- 5:58
But there's, there's more here. So
- 6:00
For example, uh, we recently removed 80% of the system prompt for Claude Code, right? And this is one of the ways in which models, you know, and what they need, uh, changes over time.
- 6:12
So originally, like, you know, maybe back in Th- Sonnet 3.5 new, the best practices for a system prompt was a small system prompt, few tools, and lots of examples, right?
- 6:22
And then as the models get smarter, you can give them more information and more instructions, and they start following them. And so it's a larger system prompt with lots of examples and many tools, right?
- 6:32
But most recently, we found this new class of models want fewer-- wa-want a smaller system prompt. The examples tend to constrain it, 'cause it's actually more imaginative than the examples we give it.
- 6:45
And so, uh, and we try to give it cons- context and not just constraints. We really try and avoid being like, "Do not do this," um, which was really necessary for the previous models.
- 6:56
Um, and so this is like, uh, a way that the system prompt is changing and, and probably will continue to change. Uh, another feature I really like is the AskUserQuestion tool.
- 7:06
This was something I worked on when I first got to Claude Code. And, and it's, uh, when Claude, you know, a- is, is planning or wants to ask you a question, it can show you a multiple choice dialogue.
- 7:17
Uh, for Opus 4, it could barely call it. I had to like, really tweak the tool to make sure that it was, uh, [laughs] that it would work, right? And then sometime at Opus 4.5, I was like, "Well, what if I asked it to like, you know, ask me 40 questions about this spec?"
- 7:33
It could start interviewing me, right? And so its ability to ask questions jumped, right? And then most recently with Opus 4.8 and Fable, I can now build a whole HTML report with the questions embedded inside of them.
- 7:47
And, uh, it's just like a whole new way of interacting with, uh, with Claude, right? And, and so this progression of like how Claude can a- get information from you has also changed.
- 7:58
Um, speaking of which, uh, Markdown and HTML is something I've also talked a lot about. Um, you know, it turned-- initially, Markdown was a, uh, a good output for the model.
- 8:07
Um, you know, it could show a little bit of rich information and then, you know, with Plan Mode, it started to be for you. Like, you could understand what Claude was about to do.
- 8:17
Um, and now, you know, Claude can build you these in-depth HTML reports, right? And so again, a way of this, the model's getting smarter in a spiky way.
- 8:28
I really like to emphasize that this is closer to a biology than a physics, right? It's still very empirical and very organic. Um, we don't know all the rules, but there is some sort of science behind it, right?
- 8:40
Like, there is an intuition to build as well. And so I really, you know, encourage you to treat Fable like that. Uh, one of my favorite papers, uh, that at Anthropic that we've written is on the biology of a large language model.
- 8:52
Um, all of our research papers are meant to be read by, you know, people of various degrees of technical expertise, but this is one of my favorites. So, uh, if you're looking to learn a little bit more, suggest you check it out.
- 9:04
But so, uh, yeah, we talked about unhobbling Claude, but it turns out when you're working with Fable, you also need to unhobble yourself, right? And so one of the things that I think a lot about is that the map is not the territory, right?
- 9:19
When I'm working on a coding problem, the plan and prompt and spec that I have in my mind is the map, right? But the territory is the actual code base, the real world, the constraints that Claude needs to navigate, right?
- 9:34
And whenever Claude runs into something in the territory that's not in the map, I call that an unknown, right? Claude has to figure out what to do about it.
- 9:41
It's a decision point that I haven't specified. And Fable is one of the first models where I felt that like, I really have to figure out my unknowns, because if not, it's gonna traverse such a large area that like it's going to run into a lot of them.
- 9:57
So how do you figure out your unknowns? Um, [laughs]
- 10:02
it-- I-- Fable is bottlenecked my abil- by my ability to match the map and the territory to find my unknowns. So a few, um, few ways to think about this.
- 10:14
I like to think of it in a, um, a matrix. So like for any problem, I have a bunch of known knowns. This is usually like what I write in my prompt.
- 10:21
What do I want, right? Then I have known unknowns, things that like I know I haven't-- don't really know yet, but I just haven't figured out yet. I can, um, uh...
- 10:31
Yeah. Then I've got unknown knowns, like what's so obvious that I just wouldn't write it down, you know? But I, I'd know it when I see it, right? And then finally, unknowns unno- unknowns.
- 10:40
What haven't I considered at all? What do I not know, right? Like, what is something that if I knew, could change how I prompt Claude?
- 10:48
And, and luckily, you can use Claude, you can use Fable to find your unknowns. So I'm gonna go over a few examples of how I do that with Fable.
- 10:57
Um, the first is I like to do what I call a blind spot pass. So I like to say something like, "Hey, I'm working on a new auth provider that I know nothing about.
- 11:07
Uh, like in this code base, can you do a blind spot pass to help me figure out my relevant unknown unknowns and help me prompt better?" Right? And so this like might have Claude go through the, the auth module and figure out like, oh, you know, this is kind of like a hairy little, uh, dead end that
- 11:23
comes up a lot. Maybe it searches my Git diff or Slack. I might tell it where there's context, right? So that I can learn about, you know, all the gotchas.
- 11:31
And, and you can use this very broadly, right? You can use it to teach you about new fields. I, I recently did this for color grading when doing video editing.
- 11:39
Um, 'cause I think this is really powerful and, and Fable is incredible at it. Um, in many ways the model knows more about, you know, almost everything than I do.
- 11:49
I just need to get it out of it. Um, then I like to use brainstorms and prototypes. Uh, this helps me figure out my unknown knowns, right? Things like, especially for design, it-- for me it's like know it when you see it, right?
- 12:02
So I might ask it to, uh, create a dashboard, um, and I tell it [laughs] I have no visual taste. Uh, make me an HTML page with four wildly different design decisions so I can react to them, right?
- 12:13
And then, you know, you tweak this as you want, but like the idea is to sort of get an idea of like- What are the things that you, uh, you know, you can't describe in words, right?
- 12:24
And, uh, like, work with the model to help figure that out.
- 12:28
Uh, then fi- then interviews. So once I have an idea of like, you know, this is what I want to do, uh, there's probably still a lot of like, uh, unknowns here, right?
- 12:39
Where I might not have considered something, I might not have specified it, and so I'll ask Claude to interview me, right? And it, uh, I'll give it a little bit more context.
- 12:48
In any of these questions, like giving it a little bit more context about you and the work and the stage you're at, like, hey, yeah, prioritize questions that would change the architecture, is extremely helpful.
- 12:58
Uh, then references. One of the best ways to give Claude a map is to give it another map, right? So instead of me writing out the spec, uh, I can just say, "Hey, here is some code that represents what I want to be done," right?
- 13:13
It could be in a different, uh, system or language, uh, but just read this code, understand it, and then use that to start your work, right? And, uh, again, this can be in a lot of different ways.
- 13:25
If I'm making a, a React component, I might have an HTML mockup that is my map, right, that I pass in as a reference. I think this is really, really powerful, and Fable is really incredible at it.
- 13:35
Uh, something else I've, like, really appreciated is implementation notes. So if, uh, while you're running Fable, uh, and it runs into an unknown, ask it to log it, right?
- 13:46
So that, um, you, uh, you can see where the deviations happened, and then you can sort of figure out why as well. You know, it'll usually give you some context about what happened.
- 13:58
And then finally, I like to get Cl- uh, Fable to quiz me about what happened, uh, just to make sure I understand what I'm doing and I can represent this work, you know, when I'm creating a PR or merging it.
- 14:08
Um, this is a really great way of, like, making sure that you're, like, really in the loop with Fable, and I think that's, like, one of the most important parts of Fable is, like, staying in the loop and making sure that you, uh, you get what you want.
- 14:23
So, um, those are so- some of my tips for working with Fable. Uh, I also want to say that the first time I used a middle class model, uh, used Fable, I felt both a huge sense of, like, gain, but also a sense of loss, and I, I wanted to talk a little bit about that, you know?
- 14:44
Um, uh, when I think about coding before LLMs, it feels like a foreign country. You know, like, I used to run a YC startup, about 30 people, and we're, we were just constantly forced into trade-offs because of how hard code was, right?
- 14:58
Like, we could make the, the app fast, or we could try prototyping a new feature and, and this might take a month, or this would take two months, and so we had to choose, and it was just really, really hard.
- 15:07
Um, and now I went back to that code base a couple weeks ago, and I thought about some of the things that I wanted to do, and, uh, it was just way easier.
- 15:17
It was like the things that would have taken me weeks I could do in hours, you know? And, uh, at some point it's like, yeah, like, how can you not laugh?
- 15:25
But also, how can you not cry hon- honestly? Like, it's like one of these things where, um, I really, really loved programming and writing code by hand. I love the feeling of, like, seeing the code base in my mind and, like, rotating it.
- 15:39
But [laughs] I also remember just, you know, like, staying up late nights trying to debug, working on things for weeks without working, right? I just remember swimming in failure. I just remember that, like, the most of the projects I've ever worked on have failed.
- 15:54
Most startups go bankrupt, you know? I think just overall programming and coding is extremely hard and [laughs] like, as much as I enjoy those highs, I, I can- cannot go back, right?
- 16:07
And, uh, the way, my reflection here is like the only way out is through, right? There's still a lot to learn with agentic coding. There's a lot to learn with Fable.
- 16:16
Uh, but I think if we try really hard and if we, like, stay in the loop, we unhobble it, uh, we can get there, you know? And we can come out on the other side, uh, with just, um, so much more.
- 16:28
And so the last bit I wanted to talk about is, is the so much more part, right? I call this being unreasonable. Um, one of my favorite parts of Anthropic is that we believe that trade-offs are not real.
- 16:44
Um, like, I think that very often I, like, in my previous company, I was very used to being reasonable. So I'd, like, write down this list of priorities, and I'd be like, "Well, I guess we can prioritize this against this," right?
- 16:56
Um, and, uh, like, you know, that makes sense, so we'll, we'll, this will be our priority this quarter. But what if you, uh, just did all of it? [laughs] You know?
- 17:04
What if you forced reality to show you the trade-off, right? Um, this is something I've really valued at our culture in Anthropic, and, uh, my reflection going forward is that I'm gonna be a lot less reasonable. [laughs]
- 17:16
Um, I think one of, this, like, the math of Claude and Fable really changes how you think about trade-offs, and there are so many trade-offs that you make implicitly in your head, right?
- 17:26
Like good, fast, cheap. Now it's pick three, right? Um, I think that, like, the s- best way to, like, do more ambitious work is to, uh, like, reframe and make big, make ourselves more ambitious.
- 17:41
Because I think the only way to prove that agents work is to do the best work of our lives faster than ever before. Um, [laughs] you know, for example, I made this deck last night in about four hours with Fable.
- 17:55
I feel like it's a, it's a deck I really like, and I, I really enjoyed it, but I also, um, you know, did it really fast. Uh, and I think that if you're here, you know, at AI Engineer, the world is kind of looking at you to prove that AI works, right?
- 18:08
That it's not just, like, a fad or something, but that it can make us more productive and also save us time. And, and that's my resolution for this year is to work m- uh, be more productive, but work less and spend more time with people I really care about.
- 18:22
Uh, I think it's also worth calling out that building is easier, but generating value is still hard. And I think this is something that we run into, you know, as AI engineers sometimes where we think so much about the process of building and our, our setups, um, but the, the point is to generate value, right?
- 18:42
And, uh, there, it takes a lot of swings. It takes a lot of tries to find the valuable stuff, uh, but that really is the goal, and that's like, you know, again, what the world is looking to us to prove that AI can really transform it.
- 18:58
So to, to end, I just wanted to say, like, go explore, make it real, and, uh, yeah, be less reasonable. [laughs] Thank you. [audience applauding] [upbeat music]