Developers Use AI for 60% of Their Work and Can Delegate Almost None of It

Two numbers from Anthropic's own research, sitting right next to each other:

Developers use AI in roughly 60% of their work.

Developers report being able to fully delegate 0% to 20% of tasks.

Most people read that and assume one of them must be wrong. Neither is. The gap between those two figures is the most honest description of agentic coding in 2026 that I have seen, and almost every strong opinion about AI and software development is really just an argument about which number to ignore.

The two camps are both reading half the data

The maximalists quote the 60% and conclude that engineering is basically solved, that headcount is a legacy concept, and that anyone still hiring developers has not understood what is happening.

The skeptics quote the delegation figure and conclude the whole thing is a party trick, that it writes plausible nonsense, and that the emperor is quite obviously naked.

They are describing the same tool. AI is in most of the work. It can be trusted to finish very little of it alone. Both facts, at the same time, without contradiction.

What that actually describes is a fast, tireless, occasionally overconfident collaborator that is genuinely useful across the majority of your work and cannot be left alone with the outcome. Anyone who has managed a talented junior will find this an extremely familiar shape.

The productivity argument nearly everyone makes is the wrong one

Here is the finding that reframed this for me. Anthropic's data suggests roughly 27% of AI-assisted engineering work is work that would not have been done at all without it.

Not done faster. Done at all.

The internal tool that would have saved the support team six hours a week and never cleared the backlog. The exploratory spike nobody could justify. The papercut bug that annoyed everyone for a year and was never worth a sprint slot. The refactor that was obviously correct and obviously not urgent.

That is a completely different economic claim than the one in every AI sales deck. The pitch is "your team ships the same work faster." A large chunk of the actual value is "your team ships work it was previously never going to ship."

It also explains why so many teams run an AI pilot, measure cycle time, see a rounding error, and conclude the tools do not work. They measured the wrong thing. The output grew sideways, into work that never appeared on the roadmap, and their metric could not see it.

Meanwhile, the horizon is genuinely stretching

It would be easy to read all this as deflationary. It should not be.

Anthropic reports that Rakuten pointed Claude Code at a vLLM implementation inside a codebase of 12.5 million lines. It finished in seven hours of autonomous work, in a single run, hitting 99.9% numerical accuracy against the reference method.

Seven hours. One run. A real codebase, not a toy repository with a tidy test suite.

The trajectory that implies is agents working across days, not minutes, with humans supervising at decision points instead of reviewing every line. That is a different working rhythm than autocomplete, and it arrives whether or not your team is ready for it.

Which means your bottleneck is about to move

Follow the logic. If generation gets cheap, fast, and long-horizon, while trust stays low, then the constraint in your engineering organisation stops being "can we write this" and becomes "can we verify this."

Most teams are not set up for that, because for the last twenty years the scarce resource was the writing.

An agent can hand you a 2,000 line change at four in the morning. It might be excellent. It might contain one subtly wrong assumption that no test covers, wrapped in code that reads beautifully, which is the most dangerous kind of wrong there is. Reviewing it properly takes real, expensive, senior attention. Not reviewing it properly takes about four seconds and feels great.

So the discipline that decides whether agentic development works for you is not prompting. It is the boring stuff:

• Test coverage that actually means something, because it is the only thing standing between a plausible change and production.
• Review capacity that scales with generation, or a deliberate decision to generate less.
• The willingness to reject work that looks right. This is a cultural muscle and most teams do not have it, because rejecting a colleague's work is socially expensive and rejecting a machine's work feels like admitting the machine beat you.
• Small, reviewable changes, because a large agent-authored diff is where the wrong assumption goes to hide.

We wrote about the adjacent version of this problem in shipping AI-built apps without the breach. Same root cause: the code arrives faster than the scrutiny.

What we actually tell clients

That AI-native does not mean "the AI does it." It means the team is built around the reality of these two numbers.

Use it everywhere. Trust it nowhere unsupervised. Invest the time you save on generation into verification, because that is where the risk migrated. Expect the win to show up as more things shipped rather than a dramatic drop in cycle time, and measure accordingly, or you will conclude your working tools are broken.

The teams getting real leverage out of this are not the ones with the cleverest prompts. They are the ones who took the delegation number seriously and built the review discipline to match the generation speed.

If you want an engineering partner that works this way rather than one selling you the 60% and quietly hoping you never check the other number, that is how our AI Native practice runs. Tell us what you are building and book a discovery call.

Figures from Anthropic's 2026 Agentic Coding Trends Report. Verified against the primary source on 12 July 2026.