The Delegation Gap: Closing 60% Usage to Actual Autonomy with Intent Specs

Two numbers from Anthropic's 2026 Agentic Coding Trends Report explain most of the frustration I hear from engineering teams.

Developers now use AI in roughly 60% of their work. They report being able to fully delegate only 0 to 20% of tasks.

The report calls that the delegation gap. Its readers group the findings into eight trends, and the two summaries we relied on name them differently, but they agree on the story: coordinated agent teams, long-running agents, human oversight that has to scale, and development economics that change when timelines compress. Read the trends together and they tell one story. The models can run for hours. The teams cannot tell them what to do for hours, or check what they did.

That is a specification problem and a verification problem. It is not a model problem. Which is good news, because specification and verification are things engineers already know how to build.

Why the gap is where it is

Ask a developer why they will not hand a task to an agent and walk away, and the answer is rarely "the model is not smart enough". It is one of these.

"I do not know what it will decide when it hits the thing I did not mention." That is a missing constraint.

"I will not know whether it did the right thing without reading everything." That is missing verification.

"It will probably solve a slightly different problem." That is a missing objective, stated as an outcome rather than an activity.

The report's own framing supports this. It names verification as the new bottleneck, and it describes the future as supervised software development with a faster production layer and a much stricter control layer, not unattended development. Long-running agents make each unstated assumption more expensive, because the agent acts on it for hours before anyone looks.

There is a second, less discussed number: about 27% of AI-assisted work consists of tasks that would not have been completed otherwise. Delegation does not shrink the backlog. It widens what the team attempts. That is worth knowing before you promise anyone a headcount reduction.

Intent as infrastructure

The framing that fixes the rest is the one Pathmode's reading of the report calls intent as infrastructure: the specification stops being a document someone wrote once and becomes a file the agent reads every time it starts, kept next to the code, changed through review.

The pathmode framing I keep coming back to: an intent spec, objective, outcomes, constraints, edge cases, verification, is not more documentation. It is executable. The decision is committed next to the code, preflighted before a long run, read at session start. And specs that an agent proposes stay proposals until a human authorises them.

Here is the anatomy I use. It is deliberately short. If it grows past a screen, the task is too big to delegate in one piece.

# intent: webhook-retry

## Objective
Webhook deliveries that fail transiently are retried and eventually succeed
without duplicating side effects at the receiver.

## Outcomes (observable, testable)
- A 5xx or timeout from the receiver is retried with exponential backoff, max 5 attempts.
- A 4xx is not retried and is recorded as a permanent failure.
- The same delivery id is never sent twice with different payloads.
- P95 delivery latency for healthy receivers does not change (baseline: 180 ms).

## Constraints
- Do not change the public webhook payload schema.
- Do not touch anything under services/billing/.
- No new runtime dependency.

## Edge cases the implementer must handle
- Receiver returns 2xx after we timed out (treat as delivered; do not resend).
- Process restart between attempts (retry state must survive it).
- Receiver flaps: alternating 5xx and 2xx.

## Verification
- Unit tests for the backoff schedule and the 4xx/5xx split.
- An integration test with a fake receiver that times out then succeeds; asserts one delivery.
- Load test: 1,000 deliveries, P95 within 10% of baseline.
- Reviewer runs the integration test locally before approving.

## Not in scope
- Dead-letter UI. Alerting. Both are separate intents.

Every section maps to one of the reasons people do not delegate. Outcomes answer "what does done mean". Constraints answer "what may it not touch". Edge cases answer "what will it decide when it hits the thing I did not mention", because now you did mention it. Verification answers "how will I know", and makes the checking cheap enough to do.

The spec is executable because the harness reads it

A spec nobody reads is documentation. Three mechanics turn it into infrastructure.

Read at session start. The harness loads intent.md for the task as the first context, before the repository map. The harness study's finding that production agents lean on auto-discovered Markdown context files is the same mechanism; this is one more file in that set, scoped to the task rather than the repository.

Preflighted before a long run. Before an agent is allowed to run for hours, a human reads the intent and signs it. That is the authorisation step. The point of a long-running agent is that nobody watches it; the intent is what they agreed to before they stopped watching.

Verification is executed, not read. The verification section names tests and thresholds. The harness runs them. The review packet includes their output. A reviewer who reads the packet is checking evidence, not re-deriving it.

Measuring the gap on your team

You cannot close a gap you do not measure, and the report's numbers are an industry average. Yours will differ.

Do not expect the number to jump from 20% to 60%. Expect a few task classes to move from supervised to delegated, and the rest to stay where they are until you can write a verification section for them. That is the honest shape of the curve.

What the report says, and what its readers say it says

A note on sourcing, because this post leans on a report that is easier to quote than to read.

The three numbers are not in dispute. Every summary we found quotes the same figures: AI in roughly 60 percent of developers' work, full delegation of only 0 to 20 percent of tasks, and about 27 percent of AI-assisted work being tasks that would not otherwise have been done. Those are the report's headline statistics and they are what the argument here rests on.

The eight trends are where the summaries diverge. One widely shared reading, Pathmode's, names them as the orchestration shift, the delegation gap, long-running agents, multi-agent systems, cross-organisation adoption, backlog expansion, verification as the new bottleneck, and intent as infrastructure. Another, from NYU Shanghai's research institute, quotes the report's own trend headings as the software development lifecycle changing dramatically, single agents evolving into coordinated teams, long-running agents building complete systems, human oversight scaling through intelligent collaboration, agentic coding expanding to new surfaces and users, productivity gains reshaping software economics, non-technical use cases expanding across organisations, and dual-use risk requiring security-first architecture. The second list reads like the report's chapter titles; the first reads like an analyst's synthesis of them, and "intent as infrastructure" in particular is best treated as Pathmode's framing of what the report implies rather than a phrase the report leads with.

That does not weaken the argument. It sharpens it. Whichever list you prefer, the report describes agents that run for days with strategic human checkpoints, teams of agents coordinated by an orchestrator, and oversight that has to scale because agents flag uncertainty rather than attempting everything. Each of those is a description of delegation, and each of them needs the thing the intent spec provides: a statement of what done means, what may not be touched, and how the work will be checked, written before the run rather than reconstructed after it.

Two more intent specs

The webhook example above is a feature. Delegation fails differently on a bug and on a migration, so here are both, shorter, because the shape should flex with the task.

A bug gets a contract, not a specification. The spec-driven tooling this year, Spec Kit, OpenSpec and Kiro, all separate the lightweight case from the full one, and the harness study's advice on proportionate specification is the same: a one-page change contract can be sufficient.

# intent: export-truncation (bug)

## Symptom
CSV export stops at 10,000 rows for accounts with more than 10,000 records. Ticket 4412.

## Expected
Export contains every record the account can see, in the existing column order.

## Constraints
- Do not change the CSV column set or order.
- Do not touch services/billing/.

## Verification
- A characterisation test that reproduces the truncation on a 12,000-record fixture, failing before, passing after.
- Existing export tests unchanged and green.
- Memory profile of the export job within 10% of the current one on the same fixture.

## Not in scope
- Export performance. Pagination in the UI.

A migration is the brownfield case, and the extra section it needs is characterisation: what the system does today, recorded as tests, before anything changes. OpenSpec's delta specifications and Kiro's brownfield emphasis are both about this. The agent's first job is to write the tests that pin current behaviour; only then does the change begin.

# intent: sessions-to-redis (migration)

## Objective
Move session storage from the Postgres sessions table to Redis without a user-visible change.

## Characterise first
- Write tests that pin current session behaviour: creation, expiry at 30 days idle, revocation on password change, concurrent logins.
- Those tests must pass against the current implementation before any migration code is written.

## Outcomes
- All characterisation tests pass against Redis.
- Dual-write period: sessions written to both stores; reads from Redis with Postgres fallback; a metric counts fallbacks.
- Cutover only when fallbacks are zero for 7 days.

## Constraints
- No change to the session cookie format.
- The Postgres table is not dropped in this change.

## Rollback
- A flag switches reads back to Postgres; dual-write means no data is lost.

## Verification
- Characterisation suite green on both stores. Load test at 2x current peak. Fallback metric visible on the dashboard before cutover.

Neither spec is long. Both would have saved the delegation that went wrong in the case they describe: the bug fix that quietly changed a column order, the migration that dropped a table on day one.

Objections

Isn't this just a PRD? A product requirements document describes what to build for people. An intent spec describes what done means for a machine that will run unattended, which is why it has outcomes that are tests, constraints that are enforced, and a verification section that executes. The overlap is the objective; everything else is different because the reader is different.

Isn't this waterfall? Only if the spec is written once and never touched. The tooling that has grown up around this, and the harness study's reading of it, is explicit that specification is iterative: implement, discover a constraint, reconcile it across the spec and the code, keep going. The webhook example's edge-case section exists because the first run found the edge case. A spec that grows past a screen is the signal that the task should be split, not that the format has failed.

The agent will just write the spec for itself. It can and often should draft it; agent-authored specs are proposals until a human authorises them, and that authorisation is the whole point of the preflight step. What changes is what the human reviews. Reviewing a half-page intent before a long run is cheaper and more effective than reviewing a large diff after it, because the intent is where the misunderstandings are visible.

We tried specs and the agent ignored them. Then the spec was context and not control. Constraints that matter are also enforced by the harness's permission configuration and by the policy proxy; the prose explains, the configuration prevents. An agent cannot ignore a path it is not allowed to write to.

Measuring without fooling yourself

The four-week baseline above will produce numbers, and numbers about developer productivity have a history of being misread. Two cautions from the curriculum work we did this year.

Measure task classes, not people. A delegation rate per engineer becomes a league table within a week, and a league table changes behaviour in exactly the ways that corrupt the measurement. Per task class, per team, per application, the numbers describe the work.

Do not equate activity with outcome. Generated lines, merged pull requests and tokens consumed all go up when delegation increases, and none of them says whether the software got better or the team got faster. The METR work on developer speed and the DORA research on delivery performance are the standard cautions here: measured slowdowns have coexisted with perceived speedups, and delivery outcomes depend on the whole system, not the coding step. Count accepted outcomes, review minutes, rework and escaped defects, and treat a rising delegation rate with rising rework as a warning, not a win.

And keep the 27 percent in view. Work that would not otherwise have been done is real value, and it is also the reason the backlog does not shrink. If the sponsor was promised a smaller team, the honest number is the one that shows a larger backlog.

The spec is the control layer

The report's phrase for where this all goes is a faster production layer and a much stricter control layer. Intent specs are the cheapest part of the control layer to build, because they are text, they live in the repository, and every engineer already knows how to review them.

They also make the rest of the control layer possible. A permission configuration needs to know what the task may touch; the constraints section says so. A release gate needs to know what must pass; the verification section says so. An audit needs to know why a change exists; the objective says so.

Write the spec. Read it at session start. Run the verification. Ship it with the code. Then watch which tasks you stop supervising.