Performance Reviews in the AI Era: Volume Stopped Signalling Contribution

Commits rose 180% on developers working with autonomous coding agents, while shipped releases rose 30%. That gap is the entire problem with a performance review built on output volume, because volume is now the cheapest thing an employee can produce. What still separates people is what they decided not to ship, what they caught in someone else's work, and how much ambiguity they can absorb without escalating.

What the numbers actually did between 2023 and 2026

The short answer

Evaluate judgement, review quality, scope and calibration, not output volume. Volume rose far faster than shipped work once AI arrived, so it now measures tool access rather than contribution. Score what an employee decided not to ship, what they caught in other people's work, and how much ambiguity they absorbed without escalating.

The best measurement of this shift is not a vendor survey. It is a National Bureau of Economic Research working paper published in May 2026 by Mert Demirer, Leon Musolff and Liyuan Yang. The authors matched more than 100,000 GitHub developers to their AI usage telemetry, then ran an event study across three successive generations of tooling.

Task output rose. Shipped output rose much less.

The measured effect on commits climbs steeply with each tool generation. Autocomplete produced a cumulative 40% increase, interactive coding agents 140%, and autonomous agents 180%. Those are large numbers by any standard in the productivity literature.

The effect then attenuates as you move up the production chain. New projects rose 50%, and actual shipped releases rose 30%. The authors also examined an app marketplace and found a moderate increase in new apps alongside no increase in total usage at all.

Read those four figures in order and the shape of the problem is obvious. The closer a measure sits to keystrokes, the more it moved. The closer it sits to something a customer actually touches, the less it moved.

The merge rate is the cleanest tell

Engineering telemetry vendors see the same divergence from a different angle, and their numbers are worth reading with the conflict of interest kept in view. LinearB reports on 8.1 million pull requests from about 4,800 teams across 42 countries, with 88.3% of developers now using AI regularly against just under 72% in early 2024.

Inside that dataset, unassisted pull requests merge within 30 days about 84% of the time. AI assisted pull requests merge 32.7% of the time. They are also about two and a half times larger, at over 400 lines at the 75th percentile against 157 lines for unassisted work.

Jellyfish, working from 700 companies, 200,000 engineers and 20 million pull requests, reports that top quartile AI adopters shipped roughly twice the pull request throughput of low adopters over a recent three month window. Two vendors, two datasets, one direction: more artefacts, and a smaller share of them surviving contact with a reviewer.

Why output volume stopped signalling contribution

A performance metric works when the thing it counts is expensive to produce and cheap to verify. Output volume used to be both. Writing 400 lines of working code, or a 20 page analysis, took skill and time that could not be faked at any scale.

Volume now measures tool access, not effort

If you rank engineers on merged pull requests in 2026, you are ranking them on which tools their team enabled. You are also ranking how aggressive they are willing to be with an agent. That is a real variable and it does vary across a team. It is not a variable worth paying a bonus against.

The same logic applies well outside engineering. A marketer who produces 12 campaign briefs a week and a marketer who produces 3 are no longer separated by capacity. They may be separated only by their tolerance for shipping a draft that a colleague will have to fix later.

The cost moved onto the reader

This is where the argument gets concrete for managers. BetterUp Labs and the Stanford Social Media Lab surveyed 1,150 full-time US desk workers in September 2025. In the previous month alone, 40% had received AI generated work that lacked the substance to advance the task.

Each incident took about two hours to resolve. The researchers put the cost at $186 per employee per month, which reaches roughly $9 million a year in a 10,000 person organisation. That cost is invisible in a volume metric, because it is booked against the recipient rather than the sender.

This is the second-order effect that a review cycle should be designed to catch. When you reward volume, you are quietly taxing the most conscientious people on the team, who absorb the cleanup and produce less countable output as a result. The same dynamic is playing out in engineering review queues, which is the subject of the piece on why code review became the bottleneck.

The third column is my reading of the evidence in this post applied to common review inputs, not a measured finding. Treat it as a prompt for your own audit rather than as a result.

The three things that actually separate people now

If volume is out, something has to replace it, and vague appeals to quality will not survive a calibration meeting. Three properties hold up under pressure, because each one gets harder rather than easier when generation is free.

Judgement: what they decided not to ship

An agent will produce a plausible answer to almost any prompt you give it. The scarce act is refusing that answer, narrowing the problem, or telling a stakeholder that the request is wrong before anyone builds it.

This is evidenceable. Look for scope cuts recorded in planning tools, requirements pushed back on before work started, and AI drafts that were discarded rather than edited into a submission. A person who never discards anything is not exercising judgement, they are forwarding.

Review quality: what they caught in other people's work

My position is that review quality should carry the same weight as authorship, and in most teams it currently carries none at all. With submission volume up and merge rates down, the reviewer is now the binding constraint on the whole system.

Score the comments that changed a design, the defect caught before release, and the willingness to reject a large change that looked finished. This is also the only criterion that directly counteracts the cost measured in the workslop survey, because it prices the cleanup work someone is already doing for free. It sits alongside the deliberate oversight design covered in the piece on human in the loop architecture.

Scope: how much ambiguity they can absorb

Scope is the size of the problem you can hand someone before you have to specify it yourself. It was always the real ladder in engineering and consulting careers, and it is now by far the clearest one.

The test is simple enough to apply in a single conversation. How vague was the brief, and how much clarification did they need from you before producing something that held up? A senior person converts one sentence into a shipped outcome. Volume metrics have never captured this, which is exactly why they always undervalued the strongest people on a team.

A rubric you can use in this cycle

Four criteria, three of them above and one that most rubrics omit entirely. Calibration is the accuracy of a person's own claims about their work, and it turns out to be the criterion most exposed by AI.

The METR study is the reason for including it. When 16 experienced developers worked on mature repositories with AI, they took 19% longer to complete 246 issues. They had forecast a 24% speedup beforehand, and after finishing they still believed AI had made them 20% faster. Self-report was wrong by nearly 40 percentage points in a group with strong incentives to be accurate.

That finding should change how you read a self-assessment form. If your review process weights self-reported impact, you are weighting a signal that a controlled trial found inverted.

Collect the evidence before you open the form, because the failure mode here is sequencing rather than the rubric itself. Managers open the review form, then hunt for evidence that fits the score they already have in mind. Every one of these criteria requires artefacts pulled before the narrative gets written.

Pull three months of review comments, three months of assignment text, and the work that was discarded along the way. That is one afternoon per direct report, and it is the only part of this process that cannot be delegated to a tool.

Do not make AI usage itself a performance metric

In June 2025, Business Insider reported an internal memo from Julia Liuson, president of Microsoft's developer division, telling managers that using AI is no longer optional and that AI tool usage should form part of performance evaluation. The division in question owns GitHub Copilot, which is worth holding in mind while reading it.

I would not put AI usage in a review rubric this year, and I would push back on any HR team that asks for it. The reason is not principle, it is arithmetic. Usage is trivially gameable, it correlates with the volume signal you just discarded, and it converts a judgement call into a compliance behaviour.

The trust data makes this sharper still. DORA's 2025 survey of nearly 5,000 technology professionals found 90% using AI at work and more than 80% saying it improved their productivity, while 30% reported little to no trust in the code AI generates. Mandating usage in that environment tells a third of your team to submit work they do not believe in. The gap between reported adoption and reported trust is examined in the piece on the developer trust and usage gap.

DORA's own framing is that AI amplifies whatever a team already is. Strong practices get stronger and weak ones get worse faster. An adoption mandate is therefore an accelerator pedal rather than a steering input, and most review cycles have a steering problem.

Calibration across managers is where this succeeds or fails

Volume metrics had exactly one genuine virtue. They were hard to argue with in a calibration meeting, because a count is a count. Replacing them with judgement, review quality and scope removes that virtue, and pretending otherwise is how good rubrics quietly die in year two.

So the rubric needs a procedural defence. Every rating should point at a dated artefact that another manager can open for themselves. If a rating cannot survive a colleague reading the underlying evidence for two minutes, it is a narrative rather than an assessment.

Run one cross-manager exercise before the cycle closes. Take two anonymised evidence packs, have three managers score them independently against the four criteria, and then compare. Where the spread is wide, the criterion needs a sharper definition rather than a heavier weight. This is unglamorous work and it is the difference between a rubric and a shared vocabulary.

There is a fairness dimension that deserves saying plainly. Junior employees produce the most AI-assisted volume and have the least judgement history to point at. A rubric like this will read harshly for them unless you weight it against the brief they were actually given. That structural pressure on early-career work is covered in the piece on the junior developer pipeline.

Where this argument is weakest

Three of the eight sources under this post are companies that sell measurement products to engineering leaders. That is worth stating before anything else in this section.

The quality decline is genuinely contested

GitClear and GitKraken analysed 623 million code changes from 2023 to 2026. They found duplication up 81%, refactoring measurement down 70%, legacy maintenance down 74%, functional connectivity down 35% and error masking up 47%. On its own that looks fairly decisive.

It is contradicted by other work at comparable scale. Jellyfish's joint research with Harvard economists, covering 100,000 engineers across 500 companies, reports that coding is faster and that code quality does not appear to be suffering. Both findings cannot be fully right. What both are consistent with is the weaker claim this post actually rests on, which is that volume detached from shipped output.

The evidence on slowdown is unstable in the same way. METR has since labelled its own 19% result out of date. In February 2026 it published follow-up data covering 57 developers, 143 repositories and more than 800 tasks. That data reports roughly an 18% slowdown for the original participants, with a confidence interval running from negative 38% to positive 9%. Newly recruited developers showed a 4% slowdown, with a similarly wide interval. METR also states that selection effects in that follow-up likely bias its own estimate downward.

Read honestly, that is a finding of no clear effect rather than a confirmed slowdown. I still use the study, but only for the perception gap, which was large and consistent across both rounds of data.

The honest cost of this rubric is inter-rater reliability. Four managers scoring judgement will disagree far more than four managers counting tickets, and that variance can encode bias against people who communicate less confidently.

I still think the trade is correct, because a precise measurement of the wrong thing is worse than a noisy measurement of the right thing. But anyone selling this rubric internally should say that out loud rather than promise a rigour it does not have. The broader difficulty of proving return on AI spending sits in the piece on deployments that returned nothing, and it is the same measurement problem one level up.

Frequently asked questions

How to run the next cycle

Two things, and the first one is a diagnostic rather than a change to anything.

Take the last review cycle you completed and mark every sentence in three write-ups that would still be true if the person had generated the work with an agent and never read it. If most of the praise survives that test, your criteria are counting artefacts. That is a 30 minute exercise and it settles the argument internally faster than any research will.

Then pick one criterion, not four, and add it to the next cycle with evidence attached. I would start with review quality, because the artefacts already exist, nobody currently gets credit for it, and it is the constraint on the whole system right now. Add judgement and scope the cycle after, once you have seen how widely your own managers disagree.

Related reading