Claude Fable 5: Stop Briefing Your AI. Start Interviewing It.

Most teams use Claude like a contractor. Write the brief. Hand it over. Wait for output. The model executes on what you gave it, and you get back a version of what you already had in your head.

The Anthropic Claude Code team just described how they changed this with Fable 5. Change number one in how they now work: treat Claude as a thought partner, give it context, involve it early. The specific practice: "Start with a small spec and ask Claude to interview you about the implementation before writing the final spec file."

That one shift changes what the model is doing for you. Not executing. Discovering.

Why the Brief Breaks Down

A brief is your current understanding, frozen at the moment you wrote it. It captures what you know, what you've decided, and what you think you want. It does not capture what you haven't thought to ask yourself.

When you hand Claude a complete brief, it executes to that brief. The gap between what you wrote and what you actually need shows up in the output. You read it, something feels off, and you write another brief to correct it. Iteration, yes. But you are iterating on the execution of an incomplete understanding.

The real problem is that the brief locks in your assumptions before the model can surface them. You've already made the decisions. Claude just runs them.

Karpathy put a sharper point on this: you can outsource your thinking but never your understanding. The brief is outsourced thinking. The interview is the work of building understanding first.

What the Interview Actually Does

When you ask Claude to interview you before writing the spec, you are asking it to use its knowledge of implementation to probe your knowledge of intent. Those are two different knowledge sets. Fable 5 has seen enough implementations to know what questions the brief did not answer.

What comes back is not surface-level clarification. Fable 5 asks the questions that expose the gaps. What happens when the user does X and Y at the same time? Is this state temporary or persistent? Are you optimizing for speed of first result or accuracy of final result? Who else reads this output and what do they do with it?

You exit the interview with a better spec than you started with. Not because Claude wrote it for you. Because the questions forced you to make decisions you had been deferring.

The Specific Practice in Claude Code

Here is what this looks like in practice. You open a new Claude Code session. Instead of pasting in a full spec, you write something like this:

Fable 5 will run a real discovery interview. It asks what your ticket volume looks like. It asks what "right team" means and who decides. It asks what happens when routing is wrong and who fixes it. It asks whether the output needs to be auditable and why. By the time the interview ends, you have a spec that would not have existed before it.

The single-question-at-a-time instruction matters. If you let it ask all questions at once, you get a form. You fill it in and move on. One at a time, each answer shapes the next question. That is an interview, not a checklist.

The Mockup Variant

The Anthropic team described a second mode: "Give it an idea and ask it to think of a few directions it could go, including HTML mockups to review."

This is thought-partner mode applied to exploration rather than definition. You have an idea but you are not sure which direction to take it. Instead of deciding first and briefing second, you ask the model to generate the directions itself.

You see options you did not invent. You react to them. Your taste and judgment operate on concrete proposals rather than abstractions. This is faster than trying to describe a direction in words, and it surfaces possibilities your original thinking had not considered.

Both modes have the same underlying logic: you are using the model's knowledge to improve your thinking before you ask it to execute anything.

Context Is Not the Same as Constraints

The same Fable 5 insight makes a distinction that most teams miss entirely. "Keep it simple" is a constraint. "This might be deleted in a month" is context.

A brief is full of constraints. Deadlines, format requirements, approved tools, word counts. What a brief rarely carries is context: why this matters now, what depends on it, how long it needs to last, who else is affected and how. Context changes what a good solution looks like. Constraints only narrow the solution space.

The interview surfaces context. It does this because the questions it asks are the questions that expose the reasoning behind the constraints. Why do you need it simple? Because the team maintaining it turns over often? Because it connects to a system that changes quarterly? That context produces a different implementation than "keep it simple" alone.

Tony Fadell made a related point recently: someone has to be charged with making the opinion-based decisions. The interview is the mechanism that forces those decisions to happen before implementation, not after. When you brief first, you defer the opinion-based decisions into the execution. They surface as ambiguity in the output. You make them retroactively, under pressure, in revision cycles.

What Scaling Companies Should Change

The brief-first workflow made sense when models were weak. You had to be precise because the model could not handle ambiguity. You wrote complete specifications because incomplete ones produced unusable output. The brief was defensive.

Fable 5 changes the calculus. It can handle ambiguity. It can ask clarifying questions that expose the structure of a problem. The defensive brief is now a constraint on what the model can do for you, not a protection against what it will do wrong.

The practical change is simple: for any work where you are not completely sure what you want, run the interview first. That is most strategic work. Product decisions. Workflow designs. Agent architectures. Anything where the brief would have been your first attempt to think through a problem you had not fully mapped.

Keep the brief for execution work. Tasks where the requirements are genuinely complete, the constraints are fully specified, and you are asking for implementation, not discovery. That category is smaller than most teams assume.

The rest belongs in the interview.