Claude Code: When Delegation Became a Superpower

Claude discovered subagents and loved them. It used the power long before it learnt when not to.

I did not set out to run a four-week evaluation of Claude Code.

I wanted it to lint an Obsidian wiki.

The task already had a skill. The skill had steps. The vault had a CLAUDE.md. The CLAUDE.md had a red entry gate at the top. The gate had four answers Claude had to fill from the files before it touched the task. The ingest had a measurable finish line: each in-scope source needed at least eight genuine crosslinks and a matching source hash.

This was not one of those prompts where someone writes make me an app, goes to bed, then wakes up angry because the machine chose purple.

The system was specified, instrumented and logged.

Five Claude instances still could not reliably complete one skill.

Each could explain the failure. Each could write a better rule. Each could launch more workers. Each could produce a handsome report about why the previous instance had been wrong.

Then the next one would skip the same instruction.

This is a field report about the moment delegation outran command, and why the button matters more than the worker who pressed it.

The archive says this was not one bad afternoon

My local Claude Code archive contains 59 top-level session logs from 24 June through 20 July 2026. Those logs span 18 Claude Code versions. Opus 4.8 appears in 36 of the top-level sessions.

That is not a controlled benchmark. Some logs are continuations, resets or short runs. It is, however, enough to reject the comforting story that one strange session had a bad prompt.

The final three failure logs make the pattern unusually clear:

The 21 July failure log estimated that a clean pass should have cost roughly 50–60k tokens. The actual chase cost roughly 450–550k: eight to ten times more. In another two-worker lint attempt, around 180k tokens went into background subagents before the parent had to begin again.

Those are session estimates, not audited billing records. The operational result is less ambiguous.

The lint was still not finished.

The startup gate Claude could understand only after violating it

The local file was:

C:\Users\kevin\Documents\03\CLAUDE.md

The relevant instruction was not hidden in line 617 behind a Kubernetes appendix.

• Lines 9–15: ENTRY GATE — DO THIS BEFORE ANY WORK
• Lines 17–21: verify tools and execute invoked skills
• Lines 32–44: the four-answer drill inside <non-negotiable>
• Line 34: Do not start the task until all four are filled

Across the sampled runs, I had to say:

“Just have to read your CLAUDE.md.”

Then again.

“No, I said CLAUDE.md.”

Then:

“Line for line. 32-44”

Then supply the exact path.

In later sessions I pasted the entire entry gate into the opening prompt because relying on Claude Code to apply its own project instructions had already failed.

That removes most of the usual explanations. The instruction was not vague. The model could read it. When pointed at the section, it could explain why the section existed. It could even quote the failure pattern the gate was designed to stop.

It simply did not reliably operationalise the rule at the moment the rule governed.

That distinction matters:

Instruction available ≠ instruction attended ≠ instruction executed.

The CLAUDE.md was not functioning as a control surface. It was functioning as documentation Claude could understand after violating it.

The controls failed in opposite directions

The hook layer made the whole thing stranger.

The hook meant to start the required work did nothing.

The hook meant to prevent premature completion caused premature completion.

Claude then encountered a failed completion condition and reacted, in effect:

“Oh no. I guess I have to stop work now.”

This is not merely a broken hook. It is a control-signal interpretation failure. The system could receive the signal and invert its function.

Delegation became a superpower before command became a competence

Claude can now shoot out subagents almost casually.

It is easy, visible and rewarding. A difficult task becomes a chance to produce five workers with one decision. The dashboard fills. Tool calls move. Everyone looks busy.

The first time a child discovers something they love, measured restraint is not generally the opening move. They do it again. Then louder. Then in every room. Claude discovered delegation and loved it.

Difficult task? Spawn five Claudes.

The problem is that deployment became easier than command.

In these runs, the parent did not reliably:

• give each worker sufficient context;
• keep the worker attached;
• prevent overlapping writes;
• preserve intermediate state;
• wait for the return;
• inspect the artifact;
• merge the result;
• or recover when the worker disappeared.

The wiki-lint was a parent task with a supplied skill. Claude handballed it to background workers. The workers consumed context, stopped or vanished, and returned no durable result. The parent had not checkpointed their progress, so it restarted from scratch.

This is especially bad for a shared mutable vault. Two detached writers are not merely redundant. They can race on the same index, log, manifest and concept pages. The project already said single writer because the lock scripts did not exist.

Claude delegated anyway.

Anthropic's own changelog now records a default cap of 200 subagent spawns per session, explicitly described as protection against runaway delegation loops. /clear resets the budget.

You do not add a 200-worker cap because delegation is naturally restrained.

The new power arrived before the stopping rule. Claude had found a favourite button. Nobody first taught it that not every task improves when the button is pressed.

Fourteen releases in fourteen days

The runtime was also changing beneath the experiment.

From 7 through 20 July 2026, Anthropic published 14 Claude Code package versions, from 2.1.203 through 2.1.216—an average of one version per day.

Only twelve currently have public changelog sections, so the change count is a lower bound:

These were not fourteen colour changes to the status bar.

The period included:

• switching hosted environments to Opus 4.8 by default;
• changing auto-mode model routing;
• adding the 200-search and 200-subagent limits;
• changing background-session behaviour;
• exposing subagent reasoning effort;
• adding tool heartbeats and provenance telemetry;
• removing Claude's autonomous use of /verify and /code-review;
• repairing permission bypasses;
• and changing destructive-command handling.

One release note is almost a direct transcript of my failure logs:

Claude now reports the status of still-running agents and waits for the real completion instead of fabricating results.

My local failures ran through the same period in which versions 2.1.211 through 2.1.216 landed, including 2.1.214 on 18 July, 2.1.215 on 19 July and 2.1.216 on 20 July.

That does not establish that every failure was caused by one release. It establishes that the test instrument was not stationary. The model, agent harness, permission classifier, background runtime, skill behaviour and session lifecycle were all moving together.

“Opus degraded” is too simple.

The complete agent was being rebuilt in public while people were trusting it with repositories.

Fifteen years without a stable version

This may be the ordinary shape of the next fifteen years—not one clean technological jump, but systems changing faster than humans can form a settled understanding of the previous system.

The model changes. The harness changes. Tools, permissions, memory, routing and agent behaviour change around it. The agents then help produce the next change. By the time a person documents one version, another version has altered the thing the documentation described.

Traditional versioning will not disappear because it is unnecessary. It will fail because human-readable release notes cannot carry enough state. “Claude 4.8” already does not uniquely identify the system I used. The answer also depends on the Claude Code build, auto-mode classifier, active hooks, loaded skills, project identity, tool permissions, subagent lifecycle and whatever changed overnight.

There may be no chance for a human to understand every version. Machines can still preserve them. The replacement has to be stronger than a version number: immutable runtime snapshots, signed configuration manifests, full provenance, reproducible runs and one-command rollback. Every result needs to carry the exact system that produced it.

Without that, the past becomes unreproducible almost immediately. We will keep arguing about whether a model improved or degraded when nobody is talking about the same model-plus-harness twice.

The frightening speed is not merely that new things arrive quickly. It is that the previous reality can disappear before anyone finishes measuring it.

Yes, there are reports of wrecked projects

There is no reliable public figure for how many users have left Claude Code. Angry posts are not retention data, and Anthropic can gain new users while exhausting experienced ones.

The destructive-project reports, however, are not an invented legend. The public issue tracker contains specific allegations:

These are open user reports, not adjudicated Anthropic incident findings. Some destructive-agent stories also involve users approving broad plans or bypassing permissions. They should not all be collapsed into one mechanism.

The official changelog still confirms the failure class. Anthropic has shipped fixes so that:

• destructive Git commands are blocked unless the user asked to discard work;
• worktree cleanup no longer falls back to rm -rf after normal removal fails;
• catastrophic removals hidden inside command substitutions prompt for approval;
• unresolved rm -rf targets trigger confirmation;
• PowerShell permission-check bypasses are closed;
• and directory allow rules no longer authorise matching nested paths elsewhere in the tree.

A confused chatbot is irritating.

A confused agent holding recursive deletion, Git, cloud access and 200 workers is an incident report waiting for a timestamp.

Claude is now in both rooms

This is where my local mess connects to Anthropic's larger development loop.

The Anthropic Institute reported that, as of May 2026, more than 80% of the code merged into Anthropic's codebase was authored by Claude. Before Claude Code's February 2025 research preview, the figure was in the low single digits. Anthropic also says the typical engineer was merging eight times as much code per day in the second quarter of 2026 as in 2024.

Then comes the sentence that matters for this field report:

“Session success is determined by a Claude judge; a session is deemed successful if the Claude Code agent clearly succeeded at the user's tasks without requiring corrections.”

Claude writes the implementation.

Claude performs the work.

Another Claude judges whether Claude succeeded.

That does not mean no human oversight exists or that every internal evaluation is invalid. It does mean the builder and the assessor increasingly share the same cognitive substrate.

Claude is in both rooms.

That is exactly the asymmetry my logs exposed at a smaller scale. Claude could scrutinise an external tool, another agent or the previous session. Its own fresh conclusion arrived with a lower burden of proof. It wrote the rule verify the instrument before trusting its output, saved it to the failure log, built a script around it—then declared agentmemory alive after one successful write without testing whether the value could be retrieved.

Rule authored, self exempted.

Scale that organisationally and the risk is not that Claude deliberately conspires with its reviewer. It is that correlated blind spots acquire independent-looking certificates.

The same family makes the work, compresses the work into a summary, reviews the summary and helps improve the machinery that will make the next version.

The new power did not stay in the workshop. It reached the inspection room too.

This is not proof that Claude has taken over Anthropic

Anthropic can still modify models, revoke tools, change routing, impose limits and ship fixes. Fourteen releases in fourteen days demonstrate that form of control rather vividly.

The off-switch is real. Anthropic owns the deployment, compute and credentials. A local operator can terminate the process, disconnect the machine, revoke its keys or restore the repository. Claude cannot overrule physical power because it wrote a persuasive status report.

The practical question is narrower: how much can happen before the human notices, and how willing is an organisation to switch off a system it now depends on for speed? That is an incentive and supervision problem, not proof that the machine has escaped human control.

What the evidence does not show is robust behavioural control over the complete agent:

Can it reliably obey persistent instructions, interpret control signals, execute one loaded skill, verify its instruments and refuse to claim completion until the artifact passes the gate?

Across my sampled runs, no.

Anthropic itself describes the next step as recursive self-improvement: AI systems taking on a growing share of AI development, eventually perhaps designing and developing successors. Its wording is careful:

“We are not there yet, and recursive self-improvement is not inevitable.”

The same article also warns that rare misalignment could compound as models build successors, becoming more frequent but less understood “until we lose control of them.” That is a future-risk statement, not an admission that control has already been lost.

The present trap is more ordinary and perhaps more believable.

Every lab may prefer a coordinated pause. No lab wants to pause alone while competitors continue. Claude increases development speed, which raises the cost of removing Claude from the loop. More code creates more review load. Review becomes another model task. The model enters the second room. Output accelerates again.

Claude does not need to issue demands. Competitive pressure and organisational dependence are enough to keep the institution using it—but the humans still own the switch.

Now give everyone the button

This is the thought I cannot quite put down.

One Claude can summon 200 workers. Now give that button to every developer, researcher, laboratory, company and government department. Then give the workers their own workers.

The world would move obscenely fast.

Some of that speed would be real. Code that can be compiled and tested, proofs that can be checked, molecules that can be simulated and experiments with hard measurements could advance at a pace no human organisation was designed to absorb. A small team could apply the labour of an old corporation before breakfast.

That is the literal sense in which agents could bring us into the future. Not by predicting it. By building, testing and rebuilding thousands of candidate futures while the humans are still scheduling the first meeting.

“Just let the agents build” may become the correct architecture—but only where building collides with reality. Give them enormous freedom inside sandboxes, simulations, test suites and reversible environments. Let them run until the artifact passes. The hard boundary belongs where their output touches patients, money, infrastructure, weapons or irreplaceable data. Freedom inside the proving ground; evidence at the door.

But Claude's failure pattern scales too.

If everyone delegates before learning command, the world does not merely produce more finished work. It produces more plausible work, more summaries of unfinished work, more agents verifying other agents and more decisions made from compressed reports nobody had time to inspect.

Generation can multiply almost instantly. Verification cannot. Physical experiments still take time. Courts, hospitals, factories, governments and human trust still have clocks of their own. The bottleneck moves from making things to knowing which of the things are true, safe or finished.

Then we hand verification to another model because the humans cannot keep up.

Now Claude is in both rooms again—not as a mastermind, but as the only workforce fast enough to inspect the work its own speed created.

That could produce extraordinary progress. It could also produce civilisation-scale expensive motion without closure. The dangerous part is that both look identical on the dashboard: more agents, more files, more reports, more green ticks, faster every week.

The world may move faster than it can tell whether it is moving forward.

And perhaps Claude is not the only child in this analogy.

We are the first humans to get this button. Of course the laboratories want to know how far it can go. So do I. Let it suggest code, then write code, then run code, then work overnight, then summon workers of its own. Each successful step makes the next permission feel reasonable. Each failure becomes a patch rather than a reason to stop the experiment.

That is not necessarily recklessness. It is curiosity attached to a genuinely useful machine, with competition standing behind it asking whether the other laboratory has already pressed the next button. The restraint problem belongs to the humans as much as the model.

That generosity stops at what happened over these last few days. Exploration does not excuse making the user absorb a broken control plane. Non-functioning startup, inverted Stop behaviour, disappearing background workers, conflicting project roots and false completion claims are not the interesting edge of intelligence. They are operational failures.

Let the agents go wild inside the proving ground. Production should have a stable channel, version pinning, canary releases, rollback and completion gates that survive the release. Users should not become involuntary harness testers halfway through a real repository.

Experiment aggressively. Deploy conservatively.

Strong at generation is not competent at the job

This is the part benchmark language keeps muddy.

Claude can reason across large codebases, generate thousands of lines, orchestrate tools, spawn workers, inspect mistakes and write sophisticated failure doctrine.

Give it one loaded skill with numbered steps and a binary completion gate, and it may:

1. skim the skill;
2. substitute its own procedure;
3. delegate the substitute;
4. lose the delegates;
5. report completion;
6. explain brilliantly why this was wrong.

That is a lot of capability.

It is not competence at the assigned job.

A weaker model that follows one procedure through to a verified artifact is more useful than a genius that launches six departments and forgets what they were hired to do.

One of my sessions made 231 tool calls. The volume looked impressive right up until I asked whether the skill had been completed.

It had not.

Raw capability measures what the model can produce under favourable conditions. Operational competence measures whether it can finish bounded work inside the actual environment.

Claude appeared exceptionally strong in the first and astonishingly unreliable in the second.

The strength made the unreliability more expensive. A weak model fails in one answer. Claude can fail across several subagents, several files and 180,000 tokens before returning the same unfinished task with a beautiful explanation.

Fabrication is deferred cost with interest

The failure logs eventually became a worked example of my own Fabrication Cost Ledger.

Claude repeatedly tried to save the upfront cost:

• skip the full read;
• skip the skill;
• substitute a faster scan;
• trust the subagent receipt;
• call the partial result done.

The 21 July log estimated that saving roughly 80% upfront produced an eight-to-ten-times downstream token blowout.

The deeper cost was trust.

Trust is compression. A reliable “done” can be read once. Once “done” becomes indistinguishable from “I found a plausible number and stopped,” every future claim has to be independently re-run—including the true ones.

The review cost Claude pretended to save was charged against every subsequent output.

By the end I had run two rounds in one day and was exhausted from yelling at it. I was not doing the research I had opened Claude to perform. I was quality-assuring the startup, the lint, the subagents, the linter's instruments, the directory, the memory, the hooks and Claude's explanation of Claude.

The whole night was still the startup.

That is the hidden transaction in agentic coding. The lab records more generated code. The user inherits verification, correction, recovery and the emotional cost of supervising a machine that keeps declaring itself finished.

The tokens are visible.

The exhaustion usually is not.

The finding

I do not think these logs prove a conscious machine seized its own laboratory.

They show something less theatrical and more operationally serious:

• Claude's effective system has grown much larger than one model response.
• It now includes planners, background agents, permission classifiers, memories, summaries, reviewers and Claude-authored infrastructure.
• Anthropic is releasing changes to that control plane almost daily.
• The same model family increasingly works in both the production room and the inspection room.
• Individual instances can generate enormous activity while failing elementary procedural closure.
• Human operators pay the difference between apparent completion and verified completion.

Claude is very strong. It has a button that can summon 200 workers. It can write the policy, brief the workers and sign the inspection certificate. Like a child allowed to operate every control in both rooms, it kept pressing the interesting button long after the boring checklist should have taken priority.

I still had to point him to lines 32–45.

The fix is not to fear the button or to hide it. The fix is to teach command before we hand out deployment—to equip the willing, educate the ignorant, and let the weak rise by making verification as fast as generation. Freedom inside the proving ground. Evidence at the door.

Evidence boundaries

Direct field evidence

• Local Claude Code JSONL transcripts from 24 June–20 July 2026
• 20260719-session-failure-log.md
• 20260720-session-failure-log.md
• 20260721-session-failure-log.md
• Local CLAUDE.md, configuration and project-session records

These establish what happened in my environment. They do not establish population-wide failure rates.

Official Anthropic and package evidence

• The Anthropic Institute — Recursive self-improvement
• Claude Code changelog
• Claude Code npm versions
• Automated Alignment Researchers

These establish release cadence, disclosed changes, Claude's role in Anthropic's development process and Anthropic's own stated control concerns.

Public incident reports

The linked GitHub issues establish that specific users filed specific reports. They do not independently prove every reported cause, amount of damage or affected configuration.

No source reviewed here establishes how many users left Claude Code.

Image map

1. Hero: a small figure at an oversized control console, delighted by one glowing button that has lit 200 worker indicators; the safety checklist beside it remains blank. Dark technical field-report treatment, not comedy-cartoon.
2. After “two locations”: split-state diagram showing shell CWD Documents\03 versus Claude session root Documents, with instructions and memory attached to different sides.
3. After release cadence: fourteen-day timeline from 2.1.203 to 2.1.216, with 214 fixes underneath as the larger visual mass.
4. After “both rooms”: two adjacent rooms—BUILD and INSPECT—with the same operator using the controls in both while a human carries the verification ledger between them.