The Code-Generation Percentage Your Org Shouldn't Be Measuring

My code goes through an agent team. Not as a demo, not as a Friday experiment—as the way the work gets done. I open a task, agents draft against it, and most of the diffs that reach me were typed by a model. If you measured my “percent of code AI-generated,” the number would be embarrassingly high, and it would tell you almost nothing about whether the software is any good.

I want to be precise about why. Someone who doesn’t use agents saying “don’t measure AI output” sounds like someone defending their horse against the automobile. So let me say it as someone whose Tuesday depends on these tools: the generation percentage is the most dangerous metric your org can adopt right now, precisely because it’s so easy to move and so easy to believe.

We Have Made This Exact Mistake Before

Lines of code. Story points. Commits per week. Each one was cheap to count, satisfying to chart, and disconnected from whether the system worked. We learned—slowly, expensively—that paying people to produce more lines produces more lines and worse software. Measuring programming progress by lines of code is like measuring aircraft-building progress by weight.

“Percent of code AI-generated” is the same idea with a new marketing campaign. It measures output. It says nothing about judgment, ownership, or whether anyone on the team can explain the system to a new hire in six months. And you can compute it automatically, from the diff, with no human in the loop. That makes it just as seductive as lines of code was, because it feels objective. In this era, a machine measuring how much a machine typed.

An org that sets an OKR against this number will hit it. That’s the problem, not the reassurance it sounds like: the metric is easy to move because moving it doesn’t require the software to get any better.

What Actually Happens When Authoring Gets Cheap

Start with the most careful measurement anyone has published.

In 2025, METR ran a randomized controlled trial on experienced open-source developers using early-2025 AI tools. The result that made headlines: AI use caused tasks to take 19% longer, with a confidence interval from +2% to +39%. Slower. Measured, not vibed, on developers who believed the tools were speeding them up.

Then METR tried to run it again, and in February 2026 announced they were redesigning the study. Their follow-up numbers point the other way. An 18% speedup for returning developers (confidence interval −38% to +9%) and 4% for newly recruited ones (−15% to +9%). But METR holds back on declaring victory for AI, because they can see the selection effects biased the measurement.

It was pay rate. They cut the pay rate from $150/hr to $50/hr, and the developers who kept showing up were self-selecting. Worse, and more telling: they said that time-on-task “measurements are unreliable for the fraction of developers who use multiple AI agents concurrently.” When a person is orchestrating three agents in parallel, “how long did the task take” stops being a coherent question.

Look at what those confidence intervals actually tell you. A confidence interval is the range the real effect could plausibly fall in; the point estimate is just its midpoint. The 2025 study’s interval ran from +2% to +39%, all of it on the slower side of zero. But the 2026 intervals run from −38% all the way to +9%, and from −15% to +9%. They straddle zero. An interval that crosses zero means the measurement can’t tell you whether the effect is a speedup or a slowdown, only that it’s somewhere in a wide band that includes “no effect at all.” The most rigorous measurement outfit in the field looked at its own results, saw intervals wide enough to contain the opposite conclusion, and decided the clean experiment needed a redesign. Anyone quoting the headline +19% or the −18% speedup as a settled fact is quoting the midpoint and hiding the band around it.

There’s a big contrast in ease of measurement between value and output. While the productivity question got harder, the “percent AI-generated” question got trivial. It’s a git blame with a label. The gap between how hard it’s become to measure whether AI helps and how easy it stays to measure how much AI typed is exactly where vanity metrics gain a foothold.

The Constraint Moved. The Metric Didn’t.

The best field evidence we have for what happens next comes from Faros AI’s “Acceleration Whiplash” report—two years of git and project-management telemetry from about 22,000 developers across roughly 4,000 teams, comparing outcomes at low versus high AI adoption within the same organizations. The name is theirs, and it’s the pattern this whole piece is circling: authoring accelerates, the stages downstream of it don’t, and the gap between the two snaps back as review queues, defects, and incidents. One caveat up front: Faros sells the platform that produces this telemetry, so they have a commercial interest in the “measure your whole delivery lifecycle” conclusion. It’s real git telemetry rather than a survey, at large scale—and it’s also vendor-published and not peer-reviewed. Go in with open eyes.

Under high AI adoption, authoring explodes, exactly as you’d expect. Faros reports tasks with code completed up 210%, average PR size up 51.3%, and files edited per PR up 59.7%. If your metric is “how much did we produce,” you’re winning enormously.

Then look one stage downstream, where the work actually has to be understood by a human. The blog writeup puts precise numbers on it, and the underlying report adds the multipliers:

Median time to first PR review: up 156.6%
Average time in PR review: up 199.6%
Median time in PR review: up 441.5%
Bugs per PR: up 54%
Incidents per PR: roughly 3x
Code churn: roughly 10x
Pull requests merged with no review at all: up 31.3%

The average time a task spends in progress is up 225.2%. Faster authoring didn’t become faster delivery. The gain was absorbed—swallowed whole—by the stages after authoring.

This is no mystery. It’s Theory of Constraints, the oldest idea in operations. Authoring was almost never your bottleneck. It just felt like it, because it was the visible, effortful part. When you pour capacity into a step that wasn’t the constraint, the constraint doesn’t vanish. It moves to the next station. Review, test, integrate, decide: the queue piles up there instead.

The mechanism explains why review specifically is where the work lands. AI-generated code is idiomatic, consistently styled, and structurally tidy even when the underlying logic is wrong. The failure modes like misread requirements, plausible-but-wrong edge cases don’t announce themselves. They land in review, where a human now has to reconstruct intent from code that looks confident. One engineer in the Faros writeup calls it “product archaeology,” and notes who ends up doing it: senior engineers, disproportionately, become the people who verify everyone else’s agents.

Authoring collapses, the queue migrates downstream, and the generation percentage is measured at precisely the station that stopped being the bottleneck:

flowchart LR
    subgraph Before["Before: authoring is the visible constraint"]
        direction LR
        A1["Author<br/>(the bottleneck)"] --> R1["Review"] --> T1["Test"] --> D1["Decide / ship"]
    end
    subgraph After["After AI: the constraint moved, the meter didn't"]
        direction LR
        A2["Author<br/>+210% output"] --> R2["Review<br/>+441% median time"]
        R2 --> T2["Test<br/>bugs/PR +54%"]
        T2 --> D2["Decide / ship<br/>incidents ~3x"]
    end
    A2 -.->|"generation %<br/>is measured HERE"| Meter["The number your<br/>OKR rewards"]
    R2 -.->|"the real constraint<br/>lives HERE"| Queue["The queue that<br/>actually grew"]

The meter is bolted to the one box that got cheaper. The constraint moved elsewhere in the system, to the station where the queue is now growing, and that station has no meter on it at all.

Play Stupid Games, Win Stupid Prizes

This one is mechanical, not rhetorical: an org that adopts the metric will walk the gaming path whether or not anyone intends to. Incentives don’t require malice; they just require a number on a dashboard and a review cycle that looks at it.

Say leadership sets the target: 80% of merged code should be AI-generated by Q4. Here’s what a rational team does to comply.

Attribute generously. The metric is computed by tooling that tags a line as AI-authored when it came from an agent session. So route everything through the agent, even the two-line fixes a human would type faster. The human writes a prompt, the agent emits the line, the line counts as generated. The number climbs and nothing improved.
Let the agent write the boilerplate you’d have deleted anyway. Generated tests that assert true == true, defensive scaffolding, verbose error handling nobody asked for. It all counts toward the percentage. Larger PRs, higher generation share, same amount of actual value. That’s the PR-size and files-per-PR bloat the telemetry already shows: the diffs got bigger, not better.
Stop hand-editing generated code in the same commit. Editing an AI-authored line reduces its generation attribution. So the incentive is to accept the agent’s version and file a follow-up fix separately—which is exactly the churn and bug pattern the telemetry already shows. The metric quietly punishes the most valuable thing a reviewer does.
Skip the review that would catch the problem. Review is now the expensive, slow station. Every hour a senior spends in “product archaeology” is an hour the throughput dashboard dislikes. The path of least resistance is to merge faster with lighter review, and the no-review merge rate has already climbed to match.

Every step is locally rational. Every step raises the metric. Every step makes the software worse. That’s not a risk of the generation percentage. It’s the metric working as designed. You asked for more AI-typed code and you got it, along with the review queue and the incident rate that come free with it.

Measure the Constraint Instead

The failure mode is to stop here and wave at “measure outcomes, not outputs” and call it insight. That’s useless. “Measure outcomes” is a cute bumper sticker. To get value you have to name where the data lives and how you’d compute it, so here are four candidates, each graded by whether you can actually instrument it today. A metric you can’t compute isn’t useful.

Revert / Churn Rate: Instrumentable Today

What it measures: how often merged code gets thrown away or rewritten shortly after landing. High churn means the code arrived not-actually-done and looped back.

Where the data lives: your git history, entirely. Reverts are commits; churn is measurable by diffing how much of a file changed within N days of a commit landing.

How to compute it: for each merged PR, measure the fraction of its lines deleted or rewritten within (say) 21 days. Tools like GitHub’s own repository statistics API expose the additions/deletions timeline; the rest is a script. A 2-year JetBrains IDE-telemetry study of 800 developers (ICSE 2026) found AI users’ monthly deletions climbing by +102 over two years against +7.6 for non-users—a roughly 13x gap in how fast the rework grew, not in how much of it there is. It’s already visible in the tooling you’ve got.

How it gets gamed: wait out the window. Land the churn on day 22. Fixable by widening the window and watching the trend, not the threshold—but be honest that it’s gameable.

Incident Rate Per Change: Instrumentable Today

What it measures: how often a shipped change causes a production problem. This is the outcome the generation percentage is silent about.

Where the data lives: your incident tracker (PagerDuty, Opsgenie, an on-call spreadsheet) joined to your deploy log. The join is the only real work.

How to compute it: incidents attributable to a deploy, divided by deploys, over a rolling window. This is a lagging DORA-style change-failure-rate metric, and the infrastructure to compute it is the same infrastructure DORA has been telling teams to build for years. Faros’s roughly-3x rise in incidents per PR is this metric already moving in the wrong direction under high adoption.

How it gets gamed: reclassify incidents as “planned maintenance,” or raise the bar for what counts as an incident. This is why it must be owned by the people who get paged, not the people whose OKR it feeds.

Time-to-Understand for a New Engineer: Partly Instrumentable, Mostly Not

What it measures: how long it takes someone who didn’t write the system to become productive in it. This is the metric that most directly captures “can anyone explain this in six months,” and it’s the one AI-generated code threatens most, because volume of tidy-looking code is not the same as a comprehensible system.

Where the data lives: partly in your PR history (time from a new hire’s start to their first real merged change), mostly nowhere—it lives in onboarding surveys and the honest answer to “how lost are you?”

How to compute it: the proxy—days-to-first-meaningful-PR—is computable from git and your HR start dates. The real thing is not, and I won’t pretend otherwise. You can instrument the shadow of this metric today; the metric itself needs a human to ask a human.

How it gets gamed: hand new hires trivial first tasks to shorten the proxy. The gaming is the tell that you’re measuring the proxy instead of the thing.

People Required to Sustain the System: Aspirational Today

What it measures: how many humans it takes to keep the system alive and evolving. A system that only its original authors—or worse, only its original agents—can safely change is a liability dressed as an asset, no matter how much of it was generated.

Where the data lives: almost nowhere clean. You can approximate it with the bus factor—the number of people who can safely touch each critical component—which is inferable from commit authorship concentration.

How to compute it: authorship concentration per module is a git query. But when the author of record is an agent, git blame stops answering the question you care about, which is which humans understand this well enough to change it safely. That’s the honest frontier: our provenance tooling was built to attribute code to people, and it degrades the moment the people are orchestrating agents. Call this one aspirational, and mean it.

The Research is Early and Holds Tension.

I’ve leaned on Faros, so I owe you the strongest counter-evidence, and it comes from Google’s own DORA program. Faros states flatly that its data “directly contradicts DORA’s 2025 findings,” and it isn’t bluffing—the two most serious efforts to measure this disagree.

DORA’s 2024 report found that a 25% increase in AI adoption was associated with a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability—pointing the same direction as Faros. DORA’s 2025 report tells a different story: it reframes AI as an amplifier that magnifies the strengths of high-performing orgs and the dysfunctions of struggling ones, contingent on capabilities like small batch sizes and a quality internal platform. Where the 2024 data read the throughput effect as a flat drop, the 2025 report treats it as conditional on those capabilities rather than uniformly negative. Same program, different year, a materially different reading of the same relationship.

I’m not going to resolve this for you, because it isn’t resolved. The honest synthesis is that AI’s per-stage effect is probably contingent on how re-engineered your delivery system already is: drop agents into an un-reengineered value stream and you get the Whiplash pattern; drop them into a jointly-optimized one and you might not. No published study stratifies the per-stage numbers by those capabilities and shows the throughput effect flipping from a drop to a gain. That study doesn’t exist yet.

Notice what both reports still share, even where their throughput readings diverge: neither claims AI adoption makes delivery more stable, and DORA’s own framing describes time saved in code creation getting spent again on review and verification—a verification tax that shows up as the review-queue growth Faros measures directly. The disagreement is about throughput. Nobody is claiming AI adoption makes systems more stable.

What Do You Do About It?

Drop the generation percentage. Not because AI-authored code is bad; because the number rewards the stage that stopped being your constraint and is silent on the one that became it.

Then instrument the two metrics you can actually compute this quarter: revert/churn rate from git, and incident rate per change from your tracker joined to your deploy log. Both live in systems you already run. Both were already moving in the data the moment authoring got cheap. Watch the trend, not a threshold, and hand ownership to the people who feel the pain—reviewers and on-call—not to whoever’s OKR would benefit from a flattering chart.

And treat time-to-understand and people-to-sustain as the honest frontier they are. You can measure their shadows today. Measuring the real things will require admitting that our whole provenance stack was built to attribute code to humans, and the humans are now conducting an orchestra. That’s a genuinely hard problem, and a much better one to be working on than gaming a diff.

The generation percentage will keep climbing. Mine certainly will. Just don’t mistake the meter on the cheap step for the health of the whole system.