The Delegation Gap: You Use AI at 60%, But Only Delegate 20%

You use AI for more than half your work, and yet you still won’t hand it a whole task. You write it, you review it, you fix it — the judgment call on whether it’s right or wrong is still yours. This isn’t a trust problem: Anthropic has measured it. Developers use AI in roughly 60% of their work, but can only fully delegate between 0% and 20% of their tasks ^[1]. I call that distance the delegation gap. And it isn’t closing on its own: a year ago usage was around 28% ^[2]. Usage has doubled. Delegation hasn’t moved.

What Is the Delegation Gap, and Who Named It?

The delegation gap is the distance between how much you use AI and how much work you can genuinely hand off without going back over it. Anthropic’s 2026 Agentic Coding Trends Report spells it out in black and white in its foreword: developers use AI in “roughly 60%” of their work but report being able to “fully delegate” only 0-20% of tasks ^[1]. Later on, the report names it the collaboration paradox: massive usage and real productivity gains coexisting with minimal delegation.

The “60%” has fine print worth reading. The actual number is 59%, and it comes from an internal Anthropic survey of 132 of its own engineers and researchers, plus 53 qualitative interviews in August 2025 ^[2]. Those same 132 people reported a self-perceived productivity boost of +50%, and more than half fully delegated only between 0% and 20% of their work. These are people working at the frontier of these tools, using them every day. If it happens to them, it happens even more to the rest of the industry.

One attribution note, because it gets misreported: the term “delegation gap” doesn’t appear in Anthropic’s report. It was coined by later analysis, specifically Janne Lammi at Pathmode ^[3]. Anthropic measures the phenomenon and calls it the collaboration paradox. I use “delegation gap” as a working label because it better describes what you see every day: the gap between what the tool touches and what actually gets handed off.

Why Does the Gap Exist: The Model or Verification?

What limits delegation is task verifiability. Model capability is almost never the bottleneck. And that’s not just me saying it — the report itself does. In Trend 4 it explains that engineers tend to delegate easily verifiable tasks, ones where they can “relatively easily sniff-check on correctness,” or low-risk ones, like a quick script to hunt down a bug. The more conceptually difficult or design-dependent a task is, the more likely they are to keep it or work it half with AI instead of handing it off completely ^[1].

There’s a quote from an Anthropic engineer on that same page that sums it up better than any chart: “I’m primarily using AI in cases where I know what the answer should be or should look like.” Translated into a design decision: I only delegate when I already have the correctness oracle in my head. Real delegation means handing over that oracle along with the work — not keeping it for yourself.

That’s the line that separates assisting from delegating. It isn’t the model you use — it’s the verification infrastructure you’ve built around it.

Dimension	Assistance (≈60% of work)	Full delegation (the 0-20%)
Who verifies	A human at every step	A computable gate
Correctness criterion	Implicit, in the senior’s head	Explicit and executable before the task launches
Marginal cost per task	Constant human attention	Amortized into the evals infrastructure
Tolerable risk	High, because there’s review behind it	Bounded by guardrails that stop the loop
Example	Editor-guided refactor	The Rakuten case (detailed below): 7 autonomous hours with numerical verification

How Much Does It Cost to Verify the “Almost Right”?

Verifying near-correct output is the cost that makes delegating not worth it without infrastructure. The Stack Overflow Developer Survey 2025 measures it bluntly: developers’ biggest frustration, cited by 66%, is “AI solutions that are almost right, but not quite” ^[4]. In the same survey, 84% already use or plan to use AI (up from 76% in 2024), but 46% actively distrust its accuracy versus 33% who trust it, and 45.2% say debugging AI-generated code takes them more time. Adoption is rising and trust is falling at the same time.

That cost is deceptive because it never shows up on the token bill. It’s paid in your attention, which is much harder to account for. METR’s experiment measured it in July 2025: in a controlled trial, experienced open-source developers using AI took 19% longer to close their issues ^[5]. The really damning part is the perception. Before the study, they expected to go 24% faster, and after taking the hit, they still believed they’d gone 20% faster. Nearly 40 points between what they felt and what actually happened. It’s worth reading with its context: 16 highly experienced developers on their own mature repos, 246 issues, early-2025 models (Cursor Pro with Claude 3.5 and 3.7 Sonnet). It doesn’t say AI always slows you down. It says the feeling of speed isn’t a metric.

What Makes a Task Delegable? Rakuten Sets the Ceiling

A task is fully delegable when its correctness can be checked cheaply and automatically. The best counterexample to the gap is in the report itself. Rakuten set Claude Code to implement a specific activation-vector extraction method on top of vLLM, an open-source library the report puts at 12.5 million lines across several languages. Claude Code finished the job in seven hours of autonomous execution, in a single run, and the implementation reached 99.9% numerical accuracy against the reference method ^[1].

Those seven unsupervised hours didn’t work because of raw model power. They worked because the task came with its own correctness oracle built in: compare the output against a reference method and require numerical agreement. There was a verification condition that was computable and cheap to run. That’s the rule I use to decide what I let go of and what I keep: full delegation if and only if a computable acceptance criterion exists. Without that oracle, what you’re calling “delegation” is really assistance with the manual review postponed.

How Do You Close the Gap? Loop Engineering, Not the Next Model

The gap closes by building the verification infrastructure. The next model isn’t going to build it for you: usage doubled in twelve months and full delegation stayed pinned at 0-20% ^[2]. There are four moves that turn assistance into delegation, and none of them depend on waiting.

Executable acceptance criteria before launching the task. Tests, invariants, numeric thresholds, schema checks. If you only define what “correct” means once you’re already looking at the output, you’re eyeballing it. The criterion has to exist beforehand, like in Rakuten. For using your test suite as the agent’s contract, see the testing strategy for when AI writes code fast but breaks things.

Evals and judges for what doesn’t fit in a test. Not everything reduces to an assert. For subjective or semantic output you need scored evals and, when it calls for it, a model acting as judge of the agent’s responses. Setting that up properly, with metrics and observability, is the subject of how to evaluate AI agents in production.

Verification gates and guardrails that stop the loop. Continuous human supervision doesn’t scale: if you have to watch every step, you haven’t delegated anything. A computable gate decides whether the result passes or escalates, and a guardrail cuts execution when it strays off course. The step-by-step with code is in how to implement guardrails for AI agents.

Loops with a stop condition and measured improvement. An agent that retries without a limit or a success criterion is a cost generator. The stop condition (a max number of iterations, a gate that authorizes the merge or escalates to a human) is what makes the loop safe, and it’s the core idea in how to design agentic loops with a stop condition. Making the loop actually improve over time is the territory of the skill that makes my agents improve themselves.

The skeleton of a delegable task isn’t a mystery. What matters is where the acceptance criterion lives:

// El criterio de aceptación existe antes de lanzar al agente:
// una función que solo devuelve ok si la salida es correcta.
type Verificacion = { ok: boolean; detalle: string }

async function delegar(
  tarea: string,
  aceptar: (salida: string) => Promise<Verificacion>,
  maxIntentos = 3,
): Promise<{ estado: 'merge' | 'escalar'; salida: string; motivo?: string }> {
  let feedback = ''
  let salida = ''
  for (let intento = 1; intento <= maxIntentos; intento++) {
    // agente: tu SDK de agente (Claude Agent SDK, LangGraph, etc.)
    salida = await agente.ejecutar(tarea, feedback)
    const v = await aceptar(salida)             // tests, invariantes, juez, umbral
    if (v.ok) return { estado: 'merge', salida } // el gate autoriza el merge
    feedback = v.detalle                         // reintento informado, no a ciegas
  }
  // preserva la última salida y el motivo para quien recibe la escalada
  return { estado: 'escalar', salida, motivo: feedback } // condición de parada → humano
}

// aceptar() para el caso Rakuten: ejecutar el método nuevo,
// compararlo con el de referencia y exigir coincidencia >= 0.999.

The model shows up in a single line. Everything else is verification infrastructure, and it’s the only part you have real control over. These patterns (acceptance criteria, evals, guardrails, loops with a stop condition) are what we work through in the course AI Agent Design Patterns, because they’re what separates a team that delegates from one that just assists.

Common Mistakes When Moving From Assisting to Delegating

Delegating Without an Executable Acceptance Criterion

This is the root error almost everything else stems from. If you launch the agent without first defining what a good result looks like, you end up manually verifying every iteration and paying the “almost right” tax (that 66% Stack Overflow frustration rate ^[4]) over and over. The oracle first, the agent second.

Measuring Productivity by Feel

METR made the warning clear: perceived speed can be off from reality by nearly 40 points (they believed +20%, it was -19% ^[5]). If your only proof that “AI makes us faster” is that the team feels that way, you don’t have a metric. You have a mood survey.

Confusing Usage With Delegation When Reporting to the Business

“We use AI in 60% of our work” and “we delegate tasks end to end” are two different statements, and in most teams only the first one is true. Reporting usage as if it were delegation inflates expectations, and it blows up in your face later when someone asks what’s actually been handed off. The honest answer is usually: 0-20%.

Supervising Continuously Instead of Through Gates

If a human has to watch every step the agent takes, they haven’t delegated the task. They’ve duplicated the review work, and made it slower on top of that. Good supervision is discrete: a gate that decides and a guardrail that cuts, with your attention reserved for what actually escalates.

If You Close the Gap, What Do You Gain?

You don’t gain “the same thing, but faster.” You expand what’s viable to build. The report estimates that close to 27% of AI-assisted work is tasks that wouldn’t have gotten done otherwise: interactive dashboards, “nice-to-have” tools, projects that scale, exploration that wasn’t worth doing by hand ^[1]. Closing the gap doesn’t just speed up the existing backlog — it expands it.

At the organizational scale the pattern repeats, and I cite it as a reference point, not a promise. Zapier reached 89% AI adoption across the whole organization, with more than 800 internal agents deployed ^[1]. TELUS built over 13,000 custom AI solutions, shipping engineering code 30% faster, with more than 500,000 hours saved ^[1]. None of those numbers come from buying the biggest model. They come from the scaffolding that makes letting go of a task safe.

The report closes with the role shift that, to me, is the heart of the matter. Trend 1: “From implementer to orchestrator.” The job stops being centered on writing code and shifts to orchestrating agents that write it, evaluating their output, and setting direction ^[1]. And one line sums up the stance better than any of mine: “It’s not ‘fully delegated’ but highly collaborative.” The goal, in their words, isn’t to take the human out of the loop — it’s to make their judgment count where it matters most.

That’s what separates teams that delegate from teams that just assist. Human judgment is the permanent layer of the protocol, not a transitional phase that a better model will eventually eliminate. The gap closes the day you decide to build a verification infrastructure around it.

Sources

1. 2026 Agentic Coding Trends Report (Anthropic). Reports “roughly 60%” and “fully delegate” 0-20% and the collaboration paradox; the “sniff-check on correctness” mechanism and the engineer’s quote (Trend 4); the Rakuten case, 7 h / 12.5M lines / 99.9% (Trend 3); the 27% of work that wouldn’t have gotten done, TELUS and Zapier (Trends 6 and 7); “From implementer to orchestrator” and “It’s not ‘fully delegated’ but highly collaborative” (Trend 1).
2. How AI Is Transforming Work at Anthropic (Anthropic, Societal Impacts). The study behind the 60% figure: 59% of work done with Claude (28% twelve months earlier), a survey of 132 engineers plus 53 interviews (August 2025), “more than half” delegate only 0-20%, self-perceived productivity +50%.
3. The orchestration era needs intent (Janne Lammi, Pathmode). Origin of the term “delegation gap”; cited only to credit the name — the figures come from Anthropic.
4. Stack Overflow Developer Survey 2025, AI section. 84% use or plan to use AI (76% in 2024); 46% distrust it versus 33% who trust it; 66% frustration rate with solutions “almost right, but not quite”; 45.2% say debugging AI code takes more time.
5. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR). RCT: 19% slower with AI; expected +24% and still believed +20% after the study; 16 developers, 246 issues, Cursor Pro with Claude 3.5/3.7 Sonnet.

Frequently Asked Questions

What Is the AI Delegation Gap?

The delegation gap is the difference between how much developers use AI (roughly 60% of their work) and what fraction of tasks they can fully hand off without reviewing them afterward (only 0-20%). The name was popularized by analysis of Anthropic’s 2026 Agentic Coding Trends Report; the report itself calls this phenomenon the collaboration paradox.

Where Do the 60% and 0-20% Figures Come From?

From a study by Anthropic’s Societal Impacts team: an internal survey of 132 of its engineers and researchers, plus 53 qualitative interviews, conducted in August 2025. Those engineers reported using Claude in 59% of their work, double the 28% from a year earlier, and more than half said they could fully delegate only between 0% and 20% of their tasks. The report’s “roughly 60%” rounds up that 59%.

Will More Capable Models Close the Delegation Gap?

Not on its own. In twelve months usage doubled (from 28% to 59%) and full delegation didn’t move from 0-20%. What limits it is task verifiability, and you’re the one who builds that with executable acceptance criteria, evals, guardrails, and loops with a stop condition. A better model produces better output, but it doesn’t tell you whether it’s correct.

Which Tasks Are Worth Fully Delegating to an AI Agent Today?

Ones with an acceptance criterion that’s computable and cheap to run: checkable with tests, invariants, numeric thresholds, or an automated judge. The Rakuten case (7 hours of autonomous work verified at 99.9% against a reference method) worked for that reason. If you can’t check correctness automatically, you’re not delegating it — you’re just postponing its review.