The number that should discipline this whole conversation
METR (Model Evaluation and Threat Research) ran a randomised controlled trial, published at metr.org: experienced open-source developers working on real issues from their own repositories were given AI tools for a subset of tasks.
They took 19% longer on the assisted tasks.
And afterwards, they believed the tools had made them about 20% faster.
A gap of roughly thirty-nine percentage points between what happened and what it felt like — in the flattering direction.
The study used early-2025 tooling, on experienced developers in codebases they knew well. Tools have improved and the result may not replicate today. What it establishes is narrower and does not expire: your sense of whether delegation is working is not evidence. It was wrong by a wide margin in the one setting where somebody measured it properly.
Every recommendation below exists because instinct cannot carry this decision.
The two questions that actually decide it
Not "is the model good enough." Not "do I trust it yet." Two properties of the task:
Can a machine check it? Is there something the harness can run that returns pass or fail — a test suite, a build exit code, a schema validation, a diff against a fixture, a screenshot compared to a design? Anthropic's own documentation on autonomous operation states this as the dividing line: a runnable check is the difference between a session you watch and one you walk away from.
How cheaply can it be undone? A checkpoint, a worktree, a branch, a committed baseline. Not "will it go wrong" but "what does wrong cost."
Plot the task on those two axes and the answer falls out.
| Hard to reverse | Cheap to reverse | |
|---|---|---|
| No mechanical check | supervised, step by step, you in the loop | timeboxed autonomous attempts — accept or restart |
| Mechanical check exists | gated autonomy: the gate decides done, you release it | dispatch it headless, at fleet scale if it decomposes |
Nobody teaches this grid and every experienced operator converges on it. The tutorials teach how to prompt a subagent, which is the wording of the job ticket. This is the staffing decision.
The ladder, and why you climb it slowly
Six rungs. Each one subsumes the one below it.
The model writes; a human runs every command and owns every effect. Slow, and the right starting point when the environment itself is unfamiliar.
The harness acts. You approve each step and read the diffs. This is where you learn what it gets wrong, which you cannot skip.
Plan approved up front, edits auto-accepted, you review at checkpoints rather than per action.
A goal condition or a Stop hook decides "done." You audit the evidence afterward rather than watching it happen.
Headless runs, background sessions, loops. You see records and gate results. This rung adds a new failure mode: nobody was watching.
Parallel isolated workers plus orchestration. Adds coordination failures — duplicated work, collisions, cost multiplication — the same failure modes documented in Anthropic's own agent-teams and multi-agent-research writing.
The rule: you may climb a rung when the one below has stopped surprising you.
Because each rung inherits every failure mode beneath it and adds one of its own. Rushing is the classic error, and the tutorial genre encourages it by presenting rungs four and five as product news.
It is tempting to read rung 5 as mastery. It isn't. Autonomy is purchased with verification and reversibility infrastructure, not with confidence. A team with excellent gates on a low-stakes task belongs at rung 5; the same team on their core business logic, without a check that actually catches the failure mode that matters there, belongs at rung 1 — regardless of how sophisticated their tooling looks elsewhere.
Mastery is rung-matching, not rung-climbing. The skilled operator is the one who correctly puts a task on rung 1 when it belongs there.
Parallelism multiplies production. Never review.
Simon Willison put it in one sentence: the natural bottleneck is how fast you can review the results.
Ten background sessions consume quota ten times as fast — and generate review debt at exactly the same rate. The bottleneck was already review. Parallelism does not move it; it feeds it.
So scale parallelism only on work whose review is cheap: mechanical checks, self-authored specs, low stakes. And where you need more review capacity, buy it structurally — adversarial reviewers in fresh context, writer/reviewer session pairs — while remembering that a reviewer told to find gaps will report some even when the work is sound.
An operator who cannot say where the review capacity for a fleet comes from has not designed a fleet. They have designed a backlog.
Decomposition has to survive the failure modes, not just describe the work
The documented ways delegated work goes wrong are stable across sources: stopping at looks done; drifting out of scope; duplicating a sibling's work when the brief was vague; degrading as context fills; writing placeholder implementations under loop pressure.
Decomposition that survives them:
- One task per dispatch. Not one theme, one task.
- Disjoint file ownership per worker. The agent-teams documentation is blunt: two teammates editing the same file leads to overwrites, so break the work so each owns a different set of files.
- The brief carries objective, output format, tool guidance and boundaries — not just the request.
- The check rides with the task. Either in the prompt or as a gate outside it, but attached.
- Scope fences in the reviewer's brief: nothing outside the task's scope changed.
Task decomposition turns out to be the same skill as org design. That is not a metaphor — it is the same problem with a different worker.
What smart people get wrong
The cheapest failure-mode education available
Read the version-gated notes in the documentation as scar tissue.
Background subagents used to silently auto-deny permission prompts. Subagents with no resolvable tools used to launch anyway and return confusing results. Worktree-isolated agents found path escapes back into the main checkout. Nested-subagent defaults flipped twice in three releases.
Every "fixed in v2.1.x" is somebody's incident. That changelog is a public record of how autonomous delegation actually fails, written by the people who had to fix it — and reading it is a verification habit in its own right.
What to do on Monday
Take the three tasks you were about to delegate. For each, answer only two questions:
Can the machine check it? If no, you are supervising, and no amount of prompt care changes that.
What does wrong cost? If the answer is "a repeat," experiment freely. If it is "a customer finds out in March," you are on rung 1 regardless of how well it has been going.
Here's where this grid gets genuinely uncomfortable rather than clean: a task like "clean up this customer list" looks cheap to reverse (it's a copy, you kept the original) and mechanically checkable (row count, duplicate count) — grid says rung 3 or 4, dispatch it. But "clean up this customer list" that silently also merges two records that were never actually the same customer is a check that passed and an outcome that's wrong, because the check you wrote (row count changed correctly) isn't the check that would have caught the actual failure (two Alexes both named Alex Rivera collapsed into one). The grid tells you the task is checkable. It doesn't tell you whether the check you actually wrote is checking the right thing — that part stays a judgment call no framework resolves for you, and it's worth sitting with rather than treating the grid's "yes" as the end of the question.
Then meter one of them. Wall-clock, cost from the run's own output, whether the gate passed first time. Three data points beat a year of impressions — the same reason the METR trial that opened this page measured instead of asking developers how fast they felt, and the same discipline applies at your own desk regardless of whether that specific study replicates on today's tooling.
Rot register
Verified 2026-08-05. Delegation features are the fastest-moving surface in the product.
| Claim | Re-check at |
|---|---|
| Subagent defaults and background behaviour | code.claude.com/docs/en/sub-agents |
| Headless contract and the bare flag | code.claude.com/docs/en/headless |
| Goal-condition evaluator behaviour | code.claude.com/docs/en/goal |
| Agent teams status, limits and token cost | code.claude.com/docs/en/agent-teams |
| Worktree isolation boundaries | code.claude.com/docs/en/worktrees |
| The 19% / 20% trial | metr.org — early-2025 tooling; read the conditions before generalising |
Every rung up trades attention for tokens. The cost function, the dials that move it, and the ledger line worth keeping per work product.
