Field Guide to Fable — Thariq Shihipar, Anthropic

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

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

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

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

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