Why Most Developers Still Get Little From Coding Agents

Two 2026 research efforts, one from JetBrains and one from Anthropic, put numbers on how engineers actually work with coding agents. Read together, they argue that the gap between getting value from an agent and getting noise lies in how the work is delegated, not in which model is chosen.

The headline claim is that AI coding is no longer an experiment, and the distinction that matters now is between asking a model to write code and truly delegating engineering work to it.

AI coding is no longer an experiment.

90% of professional developers now use coding agents at least weekly.

But there is a big difference between asking AI to write code
and actually delegating engineering work to an agent.

Why a trading app is a good test

Consider an iOS trading app built for a securities company. UIKit and SwiftUI live side by side, with MVVM and Clean Architecture on top. In that sort of codebase, a wrong number on an order confirmation screen doesn't become a bug ticket. It becomes a call from the compliance department.

For a team in that position, handing real work to a coding agent isn't about speed. The thing to watch for is the moment the agent quietly gets something wrong and nobody notices. Studying that moment teaches more about agent workflows than any course does, and the 2026 data explains why.

What the JetBrains survey found

Between May and July 2026, JetBrains surveyed upwards of 15,000 working developers. Nine in ten said they run AI coding agents on the job at least weekly, and 68% said daily.

Claude Code leads with 39% worldwide and 47% in the US, roughly double GitHub Copilot at 21%, which itself slid from 29% a year before. Codex climbed from 3% to 16%.

A companion report holds a more interesting figure. Developers estimate that about 47% of their code is now written entirely by agents, more than half of them hand-write under 20% of their code, and one in five writes none at all without AI help.

Experience didn't hold adoption back; it pushed it forward. Roughly one senior developer in four has agents produce more than 80% of their code, a larger share than among juniors, who prefer help line by line. That undercuts the story that AI makes juniors redundant. Those with the best judgment hand off the most, and that's hardly an accident.

What 400,000 sessions show

Anthropic's own study covered roughly 400,000 interactive Claude Code sessions from some 235,000 users, logged from October 2025 through April 2026. The breakdown looks plainer than the marketing would suggest:

• Code-related work made up 56% of sessions, split as 25% writing, 26% fixing and 5% testing or orchestrating.
• Operating software took 17%.
• Planning and exploration took 14%.
• Analysis and prose took 13%.

The finding that matters most concerns who decides what. People make roughly 70% of the planning decisions, while Claude makes roughly 80% of the execution decisions. Humans settle the what and the agent settles the how.

Nobody designed that division. It's the equilibrium that hundreds of thousands of engineers reached independently, because it works. Many complaints about coding agents come from people who flipped it, handing over the what and then fighting the agent over the how.

Expertise changes the outcome

Here the numbers sting anyone who believes "anyone can build now." Sessions were rated for the user's apparent domain expertise through three signals: how exact the instructions were, what the user had Claude check and how corrections happened. Outcomes were then set side by side.

Start with the first two rows. Experts don't type more. A single instruction from an expert yields over twice the unattended work, twelve actions against five for a novice, even though model, tool and price are identical. The expert's message holds enough context that the agent never has to stop and guess.

The last row matters equally. After a session veered off course, about 19% of novices gave up with no code produced, versus 5 to 7% of experts. The dividing skill isn't phrasing the prompt. It's pulling a drifting session back on track.

A sentence from the paper sums it up: with novices, Claude tends to correct the user, and with experts the user corrects Claude. That is the line between using an agent and being managed by one.

The three-step loop that fails

A common routine looks like this:

Bad:
Prompt → AI writes code → Accept

Two of those three steps belong to the agent. There's no requirement, no context, no plan and no verification. That's not delegating engineering work. It's autocompleting at a larger granularity and hoping the shape comes out right.

A seven-stage loop that holds up

The routine that survived contact with a production trading app has seven stages:

Better:
Requirement
↓
Context
↓
Plan
↓
Agent implementation
↓
Build
↓
Tests
↓
Human review

The engineer owns the first three stages and the last two, and the agent owns what sits between. This proportion mirrors the research, with its 70/30 planning split and 80/20 execution split, drawn as a pipeline. Each stage carries its own cost.

Requirement

A line such as "Add a confirmation sheet to the order flow" counts as a task. An agent will build something and land technically right but functionally wrong. A requirement worth giving holds a lot more:

Order confirmation sheet, SwiftUI, presented from OrderEntryViewController.

Must show: instrument code, side (BUY/SELL), quantity in lots,
limit price, estimated total including fee, and account buying power
AFTER the order.

Buying power must be recomputed, never passed in from the entry screen.
If recompute fails, disable confirm and show the retry state.
Never show a stale number next to a confirm button.

The last line of that spec is domain knowledge, and no model has it. It's what separates a screen that works from a screen that earns a regulatory finding. This maps to the research's "precision of direction" signal, and it's the cheapest one to fix.

Context

Where UIKit and SwiftUI coexist under Clean Architecture, an agent will make up its own pattern if none is shown, and each invented pattern turns into a review comment down the line. So the agent gets pointed to real examples first: the current use case protocol, one repository implementation, the ViewModel doing the nearest job and the module's CLAUDE.md with its layering rules. Three files and a conventions doc outperform three paragraphs of explanation each time. Nearly everyone skips this stage, though it pays back the most.

Plan

Request a plan ahead of any code, listing which files change, which layer takes each change, what the ViewModel exposes and what receives a test. Read it as if it were a PR description. Turning down a plan takes about ninety seconds. Turning down an implementation takes twenty minutes and leaves a diff that must be mentally discarded.

About a third of plans get modified, almost always on a layering question, such as the agent placing a calculation in the ViewModel that should live in a use case. Fixing that in prose is cheap, and fixing it in Swift is not.

Implementation

With the plan agreed, step aside. This is where the 80% of execution decisions live: naming, control flow, how to structure a diff, which small helper to extract. Interrupting to nitpick a variable name is how a twelve-action session turns into a five-action one. It also spends senior-engineer attention to get junior-engineer output.

Verification

The instruction with the best return states that the job isn't finished until the code builds and the tests pass, with the agent running both on its own. The research describes this as what the user asks Claude to verify, and it's the signal people undervalue longest. An agent able to run xcodebuild and the test target closes its own loop. One lacking that ability hands back a draft and labels it a feature.

For the confirmation sheet, passing tests mean concrete behaviors listed beforehand. Buying power must be recomputed when the sheet is presented, the confirm button must stay disabled while that recomputation runs, and fee math must agree with the fixtures already in the repo.

Review

Every line gets read. That's not because the code is usually bad, since it usually isn't. Review is where human expertise still has to enter the system. The reading targets what a green build can't catch: whether the change respects the layer boundary, whether the rounding rule is the one finance really uses and whether the state machine copes with the socket dropping in the middle of a confirmation.

This stage is also the genuine ceiling on throughput. An agent can generate more work than anyone can responsibly review, and the pull to skim is the real danger of the entire workflow. The risk isn't hallucination so much as fatigue.

Where the work is heading

The seven-month trend inside the 400,000 sessions deserves some attention:

• Share of sessions spent debugging dropped, going from a third (33%) down to 19%.
• Running software in operation climbed to 21% after starting at 14%.
• Writing plus data analysis roughly doubled, rising from about a tenth to about a fifth of sessions.

Bug hunting takes less time, and operating and reasoning about running systems takes more. Over the same period estimated task value went up about 25%, and building tasks rose around 43%. Work isn't disappearing. It's shifting a level up, away from typing implementations and toward specifying, orchestrating and verifying them, which matches how a senior engineer with a team has always operated.

The bottleneck is the loop

Nine in ten developers use these tools every week, yet only 15 to 33% of sessions end in verified success. So the model was never the constraint. Most people simply run a three-step loop against a tool designed for seven.

Polishing the prompt won't fix it. The remedy is placing judgment where it compounds, which means defining "correct" up front and confirming at the end that it's been met. The agent covers the middle and does it well, in proportion to how sharply the boundaries were set.

In 2026 the people who get the most out of coding agents don't write the cleverest prompts. They remain the ones who decide what "done" means.