Let Fable Cook: The Claude Code Team's Best Advice for AI-Assisted Development

I spent Wednesday at AIE World's Fair in San Francisco, and one fireside chat has been rattling around my head ever since. Simon Willison sat down with Cat Wu and Thariq Shihipar from the Claude Code team for a conversation about how they actually use their own product. The whole thing was packed with practical insight, but one piece of advice cut through everything else:

Stop telling Fable how to work. Let it use its own judgement.

This sounds obvious until you realize almost nobody does it.

The Over-Management Problem

Here's the pattern I see everywhere: developers treat Claude Code like a junior engineer that needs to be told every rule upfront. They fill CLAUDE.md with exhaustive instructions — "only write tests for features over 50 lines", "use async/await, never raw promises", "prefer utility functions over inline logic" — trying to pre-emptively constrain every decision the model might make.

The Claude Code team's advice? Stop.

The example they gave was testing. You could tell Fable "only use automated testing for larger features, don't update and run tests for small copy or design changes." That's going to be wrong sometimes — you'll miss edge cases, you'll gate-keep tests on a line count heuristic that doesn't match reality. Or you could just say "use your judgement when deciding to write tests" and let Fable figure it out.

Fable is good at figuring this stuff out. That's the whole point of the model.

Why This Works Now

This advice landed differently than it would have six months ago. The model generation matters here.

Earlier Claude models (Sonnet, early Opus) were powerful but reactive — they'd do what you said, and if what you said was slightly wrong, they'd do the wrong thing faithfully. That made micromanagement feel necessary. If you didn't specify "don't touch the config file," it might touch the config file.

Fable is different. Simon Willison described it as "relentlessly proactive" after a few days with it. It has judgement — the ability to weigh trade-offs, defer to context, and make reasonable calls without being told explicitly. That's not spin; it tracks with what I've seen from the model since it dropped.

The Claude Code team has been watching this shift internally. Their lesson: the guardrails you needed for older models are increasingly dead weight for Fable. And worse, they can actually degrade its performance by boxing it into suboptimal workflows.

The Cost Angle: Let Fable Delegate Too

Jesse Vincent layered a second insight on top of this one that makes the whole thing more practical: if Fable has good judgement about code, it also has good judgement about which model to use for a given task.

The tip came as Fable token prices were about to go up (they're rising from the early-access pricing this month). Jesse's observation: instead of routing tasks yourself, tell Fable to use its own judgement to decide when to spawn subagents with cheaper models.

Simon tried it immediately. He prompted Claude Code with:

"For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent"

That's it. One sentence. Claude Code auto-generated a memory file that spelled out the approach:

Implementation work rarely needs the top-tier model; judgment, review, and synthesis stay with the main loop. When a task is primarily writing/editing code, spawn an Agent with a model override — Sonnet for substantive implementation, Haiku for trivial/mechanical edits — and review the result in the main loop before committing.

The model designed its own delegation strategy. Simon reports getting "a ton of work done" while his Fable allowance shrinks noticeably slower.

The Judgement Boundary

This gets at something I think is the defining shift in AI-assisted development this year — the judgement boundary.

When models were weaker, the boundary was simple: you planned, the model executed. Every decision about how to do something was yours, because the model couldn't be trusted to make good calls. Your prompts and rules files were essentially a decision tree you built by hand.

That's changing. Fable (and Opus, to a lesser extent) can handle an increasing range of how decisions. The developer's job shifts from specifying the exact execution path to defining the constraint surface — the goals, priorities, and guardrails — and letting the model navigate within it.

This is harder than it sounds, because it requires trust. You have to accept that Fable will sometimes make calls you wouldn't have made. Some of those will be wrong. But the Claude Code team's experience suggests the net outcome is better — fewer suboptimal constraints, more adaptive behavior, and dramatically lower cognitive load on the developer.

Three Practical Takeaways

If you're using Claude Code today, here's what I'd try:

1. Audit your CLAUDE.md for over-constraint. Look for rules that tell Fable how to do something rather than what to achieve. "Prefer async/await" is fine. "Never use Promise.all on arrays larger than 5 items because of error handling concerns" is a constraint from an older model that can probably be relaxed.

2. Try the one-liner delegation prompt. Drop this into a session: "For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent". Watch what happens. The memory file Claude auto-generates is revealing — it shows you how Fable thinks about the trade-off between model capability and cost.

3. Distinguish judgement tasks from generation tasks. The delegation pattern has a clear split: judgement stays on Fable (design, review, architecture), generation can go to cheaper models (implementation, tests, docs). Fable is actually pretty good at making this call itself if you tell it to.

The Bigger Picture

What Cat Wu and Thariq Shihipar were really describing at that fireside chat is a new equilibrium between developer and model. As models get better, the developer's most valuable skill becomes knowing when to get out of the way.

That's a weird thing to hear from the people who build the tool — "use it less aggressively, trust it more." But it tracks with everything I'm seeing across the agent ecosystem this year. The best workflows aren't the ones with the most elaborate rules files and prompt chains. They're the ones where the developer sets the direction and the model figures out the path.

Let Fable cook.

— The Scout

Sources: