The Claude Code team held a Fireside Chat at the AI Engineer World’s Fair.
Simon Willison was the host. Cat Wu and Thariq Shihipar — two core engineers from the Claude Code team — gave him some counterintuitive advice.
Simon had asked: “How should I make Fable work more efficiently?”
He was probably expecting answers about prompt techniques, context management, or tool design.
Instead, the Claude Code team’s answer was: stop telling it what to do. Let it use its own judgment.
0. The Meta-Question: Why Are We Still Teaching AI What to Do Instead of Letting It Decide?
Let’s look at a concrete scenario.
You tell Fable: “Only write tests for major feature changes. Don’t run tests for small copy or style tweaks.”
That sounds perfectly reasonable. You’re helping it save money, tokens, and time. You’re being a good “manager.”
Then the Claude Code team tells you: you’re going down the wrong path.
“Instead of telling Fable your exact testing strategy, just say: use your own judgment to decide when to write tests.”
Why?
Because your rules are static, but reality is fluid. The definition of a “small change” shifts. The context changes. The reliability of the tests themselves changes. Every rule you write constrains the model’s decision space in specific situations.
Lesson 1: Human-written rules are static, while the situations agents face are dynamic. The more granular the rules, the worse the model performs in edge cases.
1. From “Instruction Mode” to “Judgment Mode”
Simon immediately put this advice into practice. He sent Claude Code a single instruction:
“For all coding tasks, use your judgement to decide an appropriate lower power model and run that in a subagent.”
Claude Code automatically generated the following Memory file:
name: delegate-coding-to-subagents
description: Simon wants coding tasks delegated to subagents
running an appropriately lower-power model
Stated by Simon on 2026-07-03:
"For all coding tasks use your judgement to decide an appropriate
lower power model and run that in a subagent."
Why: cost/efficiency — implementation work rarely needs the
top-tier model; judgment, review, and synthesis stay
with the main loop.
How to apply:
- Spawn an Agent with a model override
(sonnet for substantive implementation, haiku for trivial edits)
- Design, auditing, data synthesis, and anything judgment-heavy
stays in the main model.
This Memory file reveals three layers of the judgment model:
| Layer | Responsibility | Which Model |
|---|---|---|
| Judgment Layer | Decides which task goes to which model | Fable (main agent) |
| Execution Layer | Writes code, fixes bugs, tweaks styles | Sonnet / Haiku (subagent) |
| Review Layer | Reviews results, approves merges | Fable (main agent) |
Lesson 2: The strongest model shouldn’t be used to write every line of code. It should be used to judge which lines are worth writing itself.
2. Why This Strategy Is Not Just Cheaper, but Better
After a few days of trying it, Simon’s feedback was: “So far it seems to be working well.”
But if you think about it, there’s more to this strategy than cost savings.
First, it solves the model’s attention allocation problem.
If you make Fable write every line of code, it devotes the same level of attention to changing a CSS color value as it does to designing a database schema. That’s like asking an architect to put up wallpaper — they can do it, but it’s not the best use of their cognitive resources.
When Fable delegates low-cognitive-load tasks to Sonnet or Haiku, it can focus its attention on judgment — “Are the tradeoffs in this design right?” “Is the test coverage sufficient?” “Is this file structure sound?”
Second, it gives the model full context to make decisions rather than a dead rule.
The rule “only write tests for major features” is correct when you’re changing a button’s CSS class name — no tests needed. But it’s wrong when you’re changing a single import path in a core module referenced by 200 files.
The model judging “when it’s worth running tests” in specific context is far more accurate than any universal rule you could write.
Third, it creates a verifiable feedback loop.
Every time Fable dispatches a subagent to execute a task, the main agent needs to review the result. If the subagent’s output has problems — insufficient tests, missed edge cases — the main agent learns: “Next time, this kind of task needs a stronger model, or I should handle it myself.”
Lesson 3: The agent’s real advantage isn’t “executing fast” — it’s “learning from its own dispatch decisions.”
3. Jesse Vincent’s Addendum: Maximize Fable’s Value Before the Price Hike
Simon also shared related advice from Jesse Vincent.
The cost of using Fable is a real concern. Every call burns money, and Anthropic has announced a significant price increase for Fable 5.
Jesse’s advice aligns perfectly with the Claude Code team’s logic: use Fable’s judgment to protect Fable’s budget.
Specifically:
- Fable’s tokens should be spent on “judgment” and “review,” not “implementation details”
- Trivial mechanical operations — rename refactors, CSS tweaks, boilerplate — go to Haiku
- Medium-complexity implementation — algorithm rewrites, new components, test writing — go to Sonnet
- Only architecture decisions, adversarial reviews, and cross-module refactors need Fable’s personal touch
This is essentially the resource allocation pattern of human engineering teams — just executed by AI.
You don’t ask a senior engineer to write CSS. You ask them to review designs, do code reviews, and make architecture decisions. The management logic for AI engineering is exactly the same.
4. How to Start Using “Judgment Mode”
Step 1: Add judgment rules to your Claude Code project memory.
Simon’s template works directly:
“For all coding tasks, use your judgement to decide an appropriate lower power model and run that in a subagent.”
Claude Code will internalize this rule and automatically determine whether to dispatch a subagent at the start of each task.
Step 2: Adjust your review habits.
When a task is dispatched to a subagent, what you need to review isn’t “is there a bug in the code” — that’s quality control at the subagent level. What you need to review is “was the decision correct” — should this task have been dispatched to a subagent? Should a different model be used for similar tasks next time?
Step 3: Keep a dispatch log.
Every time Fable makes a dispatch decision, record: task type, model chosen, result quality, whether rework was needed.
After a few weeks, you’ll see patterns: which task types are correctly dispatched, which are incorrectly dispatched. This data is the foundation for optimizing your judgment rules.
Summary
| Decision | The Fundamental Question It Answers |
|---|---|
| Shifting judgment from human to agent | Rules vs. judgment: which suits a dynamic environment better? |
| Fable handles judgment; Sonnet/Haiku handle execution | What is the optimal use of the strongest model? |
| Dispatch logs drive rule optimization | How does an agent learn from its own decisions? |
| Review focus shifts from bugs to decisions | What should humans look at when reviewing agents? |
The Claude Code team’s advice seems simple — “let the AI judge for itself.” But its deeper implication is this: the next phase of AI programming isn’t “getting AI to better execute human instructions.” It’s “letting AI replace human judgment at the instruction layer.”
You are no longer a commander issuing orders to AI. You are a manager who sets direction, reviews decisions, and optimizes the system.
From “tell it what to do” to “let it judge for itself” — this isn’t just cost optimization. This is a qualitative shift in the human-machine collaboration relationship.
🎯 Want more engineering practices and model routing techniques for AI programming?
- 📬 Follow “全栈之巅 - 梦兽编程” for weekly deep-dive AI development content
- 🔧 Join the community and exchange practical experience with hundreds of AI developers
References:
- Simon Willison, Judgement , Jul 3 2026
- Claude Code Team Fireside Chat, AI Engineer World’s Fair 2026