AI coding agents beat human developers at narrow, well-specified work — dependency upgrades, test backfill, boilerplate, scoped bug fixes — because they're cheap, parallel, and tireless. Humans stay decisively better at ambiguity, architecture, novel problems, and judgment. The research supports a task-level split, not a replacement story: agents add capacity; they don't substitute for engineers.
That answer has the diplomatic both-sides shape that usually signals hedging, so the rest of this post is the evidence behind it — including the studies where AI made developers measurably slower. We build an autonomous agent for a living, which gives us an obvious bias and also a large pile of merged and rejected PRs to reason from. The question worth asking was never "which is better." It's "which is better at what," and that question has a specific, checkable answer.
What AI coding agents do faster than human developers
The work agents win at shares three properties: the specification is complete, the outcome is machine-verifiable, and the codebase already contains the pattern to follow.
- Scoped tickets with reproduction steps — the bug is described, the fix is bounded, the tests prove it
- Test backfill — the spec is the current behavior of the code, which the agent can read
- Dependency upgrades — mechanical changes where CI is the referee
- Boilerplate — CRUD endpoints, DTOs, wiring that follows the pattern in the next file over
On this work an agent isn't marginally faster; it's playing a different game. It starts within minutes of a ticket landing, runs many tickets in parallel, works while the team sleeps, and costs dollars per attempt instead of engineer-hours. A human who's technically faster at any single one of these tasks still loses on throughput, because the human can't do forty of them this week and shouldn't want to.
The common thread is verification. Where a test suite can say "correct," raw generation speed converts into finished work. Where it can't, speed converts into review burden — which is where the human column begins.
Where human developers stay decisively better
Ambiguity. Turning "checkout feels slow" into a scoped, prioritized problem is most of the job on hard tickets. Agents consume the output of that work; they don't produce it. Every agent vendor's docs — ours included — tell you to write better issues, which is an admission of exactly this boundary.
Architecture. Choosing an event bus over direct calls, or deciding what becomes a service, plays out over years of consequences the diff never shows. An agent optimizes the change in front of it; architecture is about the hundred changes after that.
Novel problems. Agents interpolate from patterns — in your codebase and in training data. Work with real prior art gets solved; work without it gets a confident wrong answer. The failure mode isn't refusal, it's plausibility.
Judgment. The highest-leverage senior move is often closing the ticket unbuilt, cutting scope, or spotting that the feature contradicts where the product is going. Agents complete tickets. They don't question whether the ticket should exist, and the ones that try are guessing.
None of this is a temporary gap that one more model release closes. It's a structural split: agents are strongest exactly where the problem is already defined, and defining the problem is the part of engineering that was always scarce.
What the research says about AI vs human coding productivity
Three credible studies look contradictory until you notice what varied between them.
Peng et al. (February 2023) ran a controlled experiment where developers implemented an HTTP server in JavaScript. The group with GitHub Copilot finished 55.8% faster than the control group. Greenfield task, complete spec, self-contained — the exact shape of work from the agent column above.
METR's randomized controlled trial (July 2025) found the opposite sign. Sixteen experienced maintainers worked 246 real issues on mature open-source repos they knew deeply — projects averaging over a million lines of code. With AI tools allowed, tasks took 19% longer. The detail that should worry you more: the same developers estimated AI had made them 20% faster. Perceived speedup and measured slowdown, in the same people, on the same tasks.
The 2024 DORA report (October 2024) adds the team-level view from over 39,000 survey respondents: a 25% increase in AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability, with growing batch sizes as a likely culprit — AI makes it easy to ship bigger changes, and bigger changes break more.
The same technology produced +55.8%, −19%, and −7.2% across three credible studies. The variable isn't the model. It's the shape of the work.
Reconciling them is straightforward. Scoped, self-contained, verifiable work gets dramatically faster. Deep work in complex, familiar codebases gets slower, because the human's context beats the model's and the human pays a review tax on everything the model produces. And at the org level, extra code volume without extra verification degrades stability. All three findings point at the same conclusion: route by task shape, and don't trust self-reported speedup — measure.
Which tasks fit an agent and which need a human
| Task | Better fit | Why |
|---|---|---|
| Dependency upgrades | Agent | Mechanical change, CI is the referee |
| Test backfill on existing code | Agent | The spec is the current behavior |
| Bug with clear reproduction steps | Agent | Bounded scope, verifiable fix |
| CRUD endpoints, DTOs, wiring | Agent | The pattern already exists in the repo |
| Vague ticket ("dashboard is slow") | Human first | Scoping is the actual work |
| Architecture and system design | Human | Consequences outlive the diff |
| Novel algorithm, no prior art | Human | Nothing to pattern-match |
| Deciding not to build it | Human | Judgment, not generation |
"Human first" is doing real work in that fifth row: a human scopes the vague ticket, and the scoped result often lands back in the agent column. The boundary between the columns drifts downward as models improve — but it has drifted slowest on the bottom rows, and the bottom rows are where engineering salaries were always earned.
Why "replacement" is the wrong frame
The replacement question assumes the amount of coding work is fixed, so capacity added on one side must subtract from the other. Anyone who has run an engineering team knows the backlog doesn't behave that way. Every team we've seen carries a standing population of issues that will never get an engineer-hour: the flaky test, the stale docs, the dependency three majors behind, the forty "someday" tickets. That work isn't waiting for a cheaper engineer. It's waiting for any capacity at all.
That's where agent throughput mostly goes in practice, and it's why the honest comparison for a delegated ticket is rarely agent versus engineer. It's agent versus nobody. The counterfactual for the stale-docs ticket wasn't a senior developer spending Thursday on it; it was the ticket turning three years old. This is the job we built Codowave around — pointing agent capacity at that population — but the frame holds for any tool in the category.
The replacement frame fails in the other direction too. Teams that use agents as engineer-substitutes on the human column — the ambiguous, architectural, novel work — rediscover METR's result at organizational scale: slower delivery, more review burden, and DORA's stability dip. Capacity is only capacity when it's pointed at work the agent can verify.
The math of delegating a ticket to an agent
The capacity framing becomes concrete when you price a single ticket. Run this with your own numbers; ours are round for arithmetic.
A senior engineer at $200k fully loaded, at 2,000 productive hours a year, costs about $100 an hour. A small scoped ticket — the agent-column kind — takes two to three engineer-hours including the context switch, so $200–300 shipped by a human.
An agent attempt on the same ticket costs a few dollars of compute plus a 15–30 minute human review: call it $30–60 all-in, whether the PR merges or gets rejected. If the agent's clean-merge rate on that category is p, the expected cost per shipped ticket is roughly the attempt cost divided by p. At a 50% merge rate that's $60–120 per shipped ticket against $200–300 for the human. The break-even merge rate lands somewhere between 15 and 25% — low enough that a mediocre agent on well-chosen tickets still pays.
The same arithmetic is the case against delegating everything else. On human-column work, p collapses toward zero and review time balloons, so you pay repeated review costs to reject PRs — the METR result, restated as a denominator problem. The math doesn't say agents are cheap. It says the delegation frontier is real, it's measurable per category, and it sits further left than most engineers' pride suggests.
The teams getting real value in 2026 aren't the ones asking whether the agent is better than their engineers. They're the ones who stopped spending $300 engineer-hours on $60 tickets — and stopped pretending $60 tickets are what their engineers are for.