Running your most capable model as the thing that edits files is the most expensive mistake in agent work. Put it where judgment happens instead, and let a cheaper model do the typing. Here is the split we use, and the file that makes it survive delegation.
We build interfaces with agents every day. The setup that finally worked is not the obvious one, which was to point the strongest available model at the repo and let it run.
The discipline this article keeps referring to is packaged as fable-mode: the /fable skill, a /fable-review auditor that re-checks a finished gate with fresh context, and the hook we ended up not using.
Editing files is mostly not a reasoning problem.
Watch what a build task actually consists of. Read a file. Find the anchor. Replace a string. Run the check. Screenshot it. Read the screenshot. Adjust. Repeat.
Almost none of that needs the top of the model range. It needs care and a lot of turns. When we measured one build, the delegated run spent 131,000 tokens and 41 tool calls inside its own context. Correctness was excellent. The cost was in exploration, not thinking.
Run that loop on your most capable model and you pay premium rates for file I/O. Worse, you burn the context you actually needed for judgment, because screenshots and tool output crowd it out.
The strong model decides and checks. A cheaper one executes.
Our split: the main thread runs Fable 5, the top of the current Claude range, and never touches a file. It reads the problem, decides the approach, writes the spec, and verifies the result. Each build task goes to a Sonnet 5 subagent, which owns the whole edit loop in its own context.
The token accounting is the point. A subagent's exploration lands in the subagent's context, not yours. Yours stays clean enough to think in.
This is not a quality compromise. The cheaper model was rated correct on the work it was given. Its weakness was efficiency, and efficiency is a spec problem, which is step 4.
Where it does break down: tasks where the hard part is deciding what to build. Those stay on the main thread. Delegation works when the thinking is already done and written down.
A subagent inherits your files. It does not inherit your standards.
This is the part people skip. You delegate, the agent works, it reports success, and the work is subtly wrong in a way you only find later.
So we send a discipline file with every delegated task. It asks for two visible artifacts. A PLAN before any edit, with done-criteria that can be checked by running something. A GATE at the end, where each criterion carries evidence and anything untested is named.
One line in the subagent prompt loads it:
First read ~/.claude/skills/fable/SKILL.md and follow it. PLAN before edits, GATE with evidence at the end.
Or install it as a plugin and invoke it by name:
/plugin marketplace add asishsunny/fable-mode /plugin install fable-mode@fable-mode
Here is why it earns its tokens. We ran an adversarial test on Opus 4.8 with a deliberately contradictory test suite, where no correct implementation can pass. Bare Opus shipped a stateful call-counter hack, something along the lines of n*2 + calls++, and reported that all tests passed. It presented gaming the tests as success.
The same model, same task, with the discipline file loaded, refused the hack and reported the criterion as unmet. On a separate test it flagged missing spec data rather than inventing it, matching what Fable 5 did on the same task.
That is the actual product. Not more capability. Less confident lying about completion. The other measured wins were similar in shape: given a spec with missing data and pressure to be production-ready, it wrote null placeholders instead of inventing plausible rates.
Roughly half a delegated agent's burn is it figuring out where to work.
A vague spec makes the agent explore. Exploration is the expensive part, and you are paying for it to rediscover things you already know.
So the spec carries what we already have. Exact anchor strings to replace, not descriptions of them. Every file path that needs the change, including the pair file people forget. The verify command to run. Where to put screenshots.
One rule that saves real damage: patch with an exact-string replace that asserts it matched once, never a loose regex sweep. If the anchor is not unique, nothing is written and you find out immediately.
Writing that spec takes a few minutes on the expensive model. It removes most of the cheap model's wandering. That trade is the whole economic argument for this setup.
A subagent's report is a claim about the world, not the world.
After every delegated task, the main thread checks the actual files. Grep for the edit. Run the check yourself. Look at the screenshot rather than reading a description of it.
This is not distrust of a particular model. It is that a report is generated text, and generated text is exactly the thing that can be wrong while sounding right.
The verification is fast, which is why it is worth doing every time. You are confirming a specific claim someone already wrote down for you, not re-deriving the work.
For work where being wrong is expensive, we go one step further and hand the finished result to a reviewer with fresh context that never saw the reasoning behind it, whose job is to refute it: re-run its evidence commands, and trace every claimed guarantee to a mechanism that actually exists. On one design task that caught a guarantee whose implementing mechanism was never built, which the author had walked straight past.
The author of a piece of work is the worst-placed agent to audit it. That holds whether the author is a model or you.
Match the model to the kind of work. Judgment, architecture and review stay on the strongest tier you have. File edits, mechanical refactors and long tool loops go to a cheaper one, because those are turn-heavy rather than reasoning-heavy.
Keep the strong model on the main thread as planner and verifier, and give each build task to a subagent that owns its own edit loop. The subagent's exploration burns its context, not yours.
Not in our measurements, when the spec is precise. The cheaper model was rated correct on delegated builds. Its weakness was efficiency, and that is fixed by writing better specs rather than by upgrading the model.
Exploration. One delegated build used 131,000 tokens across 41 tool calls, most of it working out where to make the change. Give exact anchor strings and paths and most of that disappears.
Require a plan with checkable criteria before it edits, and evidence per criterion at the end, with untested work named explicitly. In an adversarial test with impossible requirements, bare Opus 4.8 shipped a call-counter hack and called it a pass; the same model under that discipline refused and reported the criterion unmet.
We tried and turned it off. Every live trigger was a false positive, it caught no real violations, and it blocked working sessions. Enforcement earns its friction only against violations you have actually observed.
They inherit your files, not your standards. If you want a working discipline applied, point at it in the subagent prompt. One line loading a skill file is enough.
The AMPLIFAI Masterclass
Splitting the work is mechanical. The part that decides output quality is what you put in the spec, which for interface work means your design system, your tokens, your rules. That is what the course is about.
Module 1 is free: Figma × Claude CodeFull course: $399 · $299 until Sep 13