Writing code stopped being the expensive part. Deciding whether it should ship didn't.
Yesterday the Hacker News front page argued about it from two ends. AI promised less work, I've never worked more drew over 600 comments. Next to it, Jan van den Berg's The Mythical Man-Month in the Age of AI made the sharper point: the coordination overhead didn't go away, it moved from managing people to managing agents, and someone still has to define done, review the output and integrate it. "Adding agents to a project with unclear requirements gets you the wrong answer faster."
The data says the same. Fiona Chen and James Stratton at Harvard joined Jellyfish engineering telemetry for 725,938 workers at 718 software firms, January 2021 to March 2026. With coding agents, commits per worker went up 20% and pull requests 23%. Time from PR submission to merge went up 49% -- 3.45 days on a 7-day baseline. Review comments per PR, up 35%. Resolved Jira issues: no statistically significant change.
Uber saw it from the inside. At the AI Engineer World's Fair, Will Bond said time to first review went from 3 hours in 2024 to 9 hours in 2026, while PRs per month and lines per PR both grew.
The bottleneck moved from typing to judgment. Review, and the definition of done that review enforces, is the scarce resource now. Everything upstream of it got cheaper. My bet is that this is where the job is going anyway: software is becoming manufacturing, and most of what's left for engineers is forms of QA and design. Teams that treat review as overhead to squeeze are fighting the shape of the work.
PRs Are a Vanity Metric
If an agent can open ten PRs before lunch, PR count measures your token budget. Worse, it rewards the exact thing that hurts: more volume pushed onto the same reviewers.
Two numbers are worth putting on the wall instead:
- Time to merge: opened to merged. This is what the developer, and eventually the customer, actually waits on. Time to first review is its leading indicator, and it's the one Uber watched triple.
- Cost per accepted change: what review spent to get one change that shipped and stayed shipped. Accepted means merged and not reverted within two weeks. The spend includes the rounds burned on PRs that were abandoned or rolled back -- which is where cheap code makes most of its waste.
Few teams track reviewer minutes, so review rounds are a fair proxy. Dump your PR data into a table and it's one query (Postgres):
select date_trunc('week', opened_at) as week,
count(*) filter (where accepted) as accepted,
round(sum(review_rounds)::numeric
/ nullif(count(*) filter (where accepted), 0), 2) as rounds_per_accepted,
percentile_cont(0.5) within group (
order by extract(epoch from first_review_at - opened_at) / 3600) as p50_h_first_review,
percentile_cont(0.5) within group (
order by extract(epoch from merged_at - opened_at) / 3600) as p50_h_merge
from (
select *, merged_at is not null
and (reverted_at is null
or reverted_at > merged_at + interval '14 days') as accepted
from changes
) c
group by 1
order by 1;
Look at the denominator. A week where three PRs got six review rounds, one was reverted the next day and one was abandoned reads as six rounds for one accepted change -- not "two PRs merged". Same people, same week, very different story. percentile_cont skips NULLs, so unreviewed and unmerged changes drop out of the medians and only count against you in the cost column. And the last two weeks will always look a little too good, since their revert window hasn't closed.
Reviewer Time Is the Budget
Once review is the budget, the moves are the boring ones:
- Small changes. A reviewer can hold a small diff in their head and actually judge it. A big one gets skimmed and approved. Put a size limit in CI and make crossing it a deliberate act.
- A definition of done a machine can check. Format, lint, types, tests green, coverage on the changed lines, size under the limit. If a machine can say no, a human should never be the one saying it. Reviewers then spend their minutes on what only they can judge -- is this the right change, and does it fit.
- Tests come with the change. A change without tests asks the reviewer to run it in their head. Tests are how the author hands confidence to the reviewer, and the agent that wrote the code can write them too -- as long as CI runs them where the agent can't edit them.
- Go Start to Finish. In Principles of Effective Work I wrote that "a work half done is worse than a work that never started," because half-baked work forces cognitive load on whoever picks it up. A generated PR its own author hasn't read is exactly that. The author -- human or agent -- gets it to done before it costs anyone else a minute.
This is Just Enough Design applied to process. No review board, no new ceremony; a gate that moves the cheap checks to the machine and keeps the expensive ones for people.
The Tradeoff
Smaller changes mean more PRs, and every PR is a context switch for someone. Split a feature into eight pieces and you can make each one easy to review and the whole thing hard to understand. Stacked changes help, and so does a short note up front telling reviewers where the series is going.
The metric can be gamed, too. A team that dreads reverts will forward-fix instead, and the cost column looks great while main burns. Keep the revert rate next to it, and don't turn any of this into an individual scorecard -- the moment people are ranked on it, it stops measuring anything.
And a machine-checkable definition of done is only as good as its checks. Green CI on weak tests is a rubber stamp.
None of that is a reason to go back to counting PRs. The cost of generating a change is heading to zero; the cost of a person deciding it's right isn't. Spend your engineers on judgment, and measure what that judgment costs per change that sticks.