What Makes Claude Fable Different — It's Not Just Smarter

Models are grown, not designed

The talk opens with this: “Models aren’t designed. They’re grown.”

Most software is the result of someone writing a spec, designing it, and building it. AI models are different. Nobody sets “99% on SWE-bench” as a target and builds toward it. The model is grown first, with data, feedback, and compute, and then even the team that made it learns what it can do.

It’s closer to biology than to physics.

The rules aren’t all written down, so you use it by observing and experimenting, not by memorizing formulas. As further reading, he recommended Anthropic’s Biology of a Large Language Model. The rest of the talk only makes sense once you let go of the idea that this is a tool you can run by the manual.

Capability overhang: the ability is already there

This was the example that stuck with me most. Ask a chatbot to “list every Pokémon whose name ends in aw” and it gets it wrong. Give the same model a bash terminal and it gets it right.

The model didn’t suddenly get smarter. The intelligence was there all along. It just had no tool (harness) to use it. This gap is called capability overhang. Model capability races ahead unevenly (spiky), and the bottleneck is on our side: prompts, tools, and how we use them.

What Anthropic actually changed

Anthropic says it changed its own products in this direction.

• It cut 80% of the system prompt. In the Sonnet 3.5 days, prompts packed with examples worked well. Fable is “more imaginative than the examples we give it,” so examples end up boxing it in.
• It gives context instead of prohibitions. The “Do not …” lists are gone. The model gets the situation and the goal, and makes the call itself.
• It picks effort to fit the task. Fable 5 on medium beats older models on their highest setting. There’s no need to always max it out.

Packing a prompt with rules and examples is a habit built for older models. With Fable, giving the goal and context and leaving the method to the model works better.

The bottleneck is me: four kinds of unknowns

Fable is the first model where the quality of the output is bottlenecked by how clearly I can articulate my own unknowns.

The days of odd results because the model didn’t understand are fading. Now results go wrong because I don’t know what I don’t know. Thariq splits the gaps in knowledge into four quadrants.

If you don’t manage your unknowns, you fail in both directions. Too specific, and the model sticks to your instructions even when changing course would be better. Too vague, and it makes an “industry average” call that has nothing to do with your situation.

When Anthropic analyzed about 400,000 Claude Code sessions, who made the decisions depended on the stage.

The model may handle execution, but people make most of the planning calls that set the direction. In the end, how organized my thinking is before I start decides the result.

Five techniques you can use right away

Here are the techniques from the talk, with prompts. All five share one premise: tell it where you’re starting from. If you say how well you know the problem and how far you’ve thought it through, Claude helps at the depth that fits.

I'm about to start work on a new auth provider in this codebase, and I don't know it at all.
Do a blind spot pass to find the unknown unknowns I might be missing, then help me write a better prompt based on it.

Interview me before you start implementing.
Ask about the ambiguous parts one at a time, starting with the questions whose answers could change the architecture.

Don't implement yet. Make 3 or 4 completely different design directions as HTML artifacts and show them to me.
I'll decide the direction by reacting to them.

I have no criteria for judging what good color grading looks like.
Before we evaluate the options, teach me the core concepts of this field and what separates good from bad.

Make an implementation plan.
Go into detail on the parts likely to change later, like the data model, type interfaces, and anything users see, and keep the rest brief.

When you give references, source code beats screenshots, even code in another language. Code carries intent and structure that never show up on screen. Add the git diff, docs, and internal wiki, and Claude understands the situation far more accurately.

Case study: editing video with Claude Code

These techniques aren’t only for code. Thariq edited Fable’s entire launch video with Claude Code. Video editing was new to him, and the process followed the techniques above step by step.

1. He started from what he knew. All he knew was that Claude could cut and transcribe video with code.
2. He resolved the known unknowns. Unsure the accuracy would be good enough, he first had it explain how Whisper transcription works and whether ffmpeg could precisely cut filler words like “um” and “uh” and silent stretches.
3. He built small first. The effect of UI elements appearing in sync with the audio was prototyped small in Remotion.
4. He learned what he didn’t know. The colors looked flat, so he generated several color grading variations, then realized he didn’t know what good color grading was. Instead of picking one at random, he asked to be taught the field first.

Start from what you know, surface what you don’t, and narrow it down as you learn. It works the same for code, video, or writing.

What I took away

Everyone says Fable is far better than earlier models, but even after using it I couldn’t say exactly where the difference was.

I was using Fable like an older model: short instruction, look at the result, ask for a fix, repeat. Used that way, the difference barely shows. What really sets Fable apart is finding my blind spots with me before I start and carrying long work forward on its own. I never gave it the chance.

I thought capability overhang was about the model. It turned out to be about me. The ability was already there, and I was the one holding it back.