Fifty-two percent. DX Research published their Q2 2026 report two weeks ago, covering data from 500+ engineering organizations, and the headline number is that AI-authored code crossed the majority threshold sometime in the last quarter. In Q1 it was 34%. By Q2 it was 52%. The average developer now merges more AI-generated code than human-written code each week.
That sounds like a productivity story. It isn't, or at least not primarily. The more interesting thing that happened when AI code crossed 50% is that the measurement frameworks most organizations use to track developer output started measuring something they were not designed to measure.
What the Majority Threshold Actually Changes
The frameworks built to track developer productivity — DORA, SPACE, commit counts, PR throughput — share an assumption: the developer is the primary unit of production. PR merge rate measures how fast a developer closes work. Commit frequency measures how often a developer ships. Coding time measures how many hours a developer spends building.
When AI code was 20% of output, those metrics remained a reasonable proxy for what a developer was doing. The developer drove 80% of what landed. AI was an accelerant, not the engine.
At 52%, those metrics describe a different thing. They still measure what landed in the repo. They no longer reliably indicate what the developer contributed in any meaningful sense. A developer who queued three agentic sessions on Monday, reviewed the output Wednesday, and approved the PRs Thursday produced something real. DORA would count three deployments. PR throughput would show three merges. Coding time would show perhaps two hours. None of those numbers captures what that developer actually did — the quality of the task specification, the accuracy of the review, the judgment calls in approval.
The frameworks are measuring outputs of a system. They were built to measure outputs of a developer. The two have diverged.
The PR Size Problem Running Alongside the Threshold Number
DX's report includes a companion finding that makes the threshold crossing harder to dismiss as noise. Median PR size nearly doubled over the past year — from 44 lines in mid-2025 to 72 lines by Q2 2026. That's a separate data series, and it points at the same underlying dynamic.
AI produces verbose code. When you ask a model to implement a function, it generates more lines than a human would for an equivalent result: explicit error handling for cases that could be implied, intermediate variables that document the logic at the cost of brevity, test coverage for edge cases the developer would have trusted a framework to catch. None of that verbosity is necessarily wrong. The code compiles, passes tests, ships. But it is code someone has to review.
Median PR size at 72 lines means the typical PR is substantially larger than it was before AI adoption took hold. Review bandwidth did not double to match. A developer reviewing the same number of PRs per day they reviewed last year is now reading through 60% more code per session, making the same number of approval or rejection decisions.
This is how the majority threshold compounds the review problem. More PRs, because AI throughput is up. Bigger PRs, because AI writes verbose code. Same review bandwidth. The throughput gains that show up in PR count are absorbed by the review burden that does not scale.
The Modest Gains Are Already Telling You This
DX's Q2 findings are consistent with what their broader longitudinal research has documented across 121,000 developers. AI tool usage in the cohort went up 65% over six quarters. PR throughput went up around 10%. That gap between 65% and 10% is not a rounding error — it is the result of optimizing a phase that was already fast relative to everything else in the delivery cycle.
What is new in Q2 2026 is that we've crossed into majority AI code production while that gap is still this wide. The 10% throughput improvement is not a floor that grows as AI improves. It is the ceiling of what the surrounding system can convert into delivery. Agentic sessions generate code faster than review, alignment, and deployment infrastructure can absorb. Crossing 50% AI code share did not change that ceiling. It made the gap between ceiling and AI output larger.
The Amdahl framing applies cleanly here. If review, planning, and alignment account for the majority of end-to-end delivery time, speeding up code generation — even tripling AI code share from 17% to 52% over 18 months — produces diminishing returns on shipping velocity. DX's Q2 data suggests we are well into that regime.
What You'd Actually Need to Measure
The metrics that would accurately describe developer output at 52% AI code share are different from the ones most organizations track.
Intent quality matters more than code quantity. A developer who specifies a task precisely enough that the agent's first pass is mergeable without correction contributed more than one whose vague brief required three redirect cycles before producing usable output. No standard metric captures this. First-pass agent success rate — how often does the agent's output survive review without substantial revision — is a workable proxy, but it requires tracking agent sessions alongside their downstream review outcomes, which most tooling does not do.
Review accuracy matters more than review speed. A developer approving ten AI-generated PRs per day is not being 10x productive if they're missing logic errors that ship. The measure you want is defect rate on AI-assisted code tracked over months, not weeks, because downstream bugs lag the code that created them.
Time allocation across the full workflow matters. If AI code is 52% of what ships and the developer's valuable contribution is now in specification, review, and judgment rather than generation — then knowing how your hours distribute across those activities is more useful than knowing your coding hours. Those hours do not live in an IDE. They live in Linear, in Slack, in GitHub review threads, in the conversations where product decisions get made.
The Job Description and the Job
The practical reality of 52% AI code share is that the developer's job has shifted more than most job descriptions reflect. The title says "software engineer." The actual work, in a majority-AI codebase, is closer to technical director: defining tasks precisely enough that agents can execute them, reviewing output accurately enough to catch what agents miss, making the architectural decisions that agents do not make.
None of that is less valuable than writing code. Some of it is harder. It requires different skills and different working patterns than the job it replaced, and it is poorly captured by frameworks built to track a developer who sat at a terminal and wrote most of what they shipped.
That is the real consequence of the DX Q2 finding that tends to get lost in the headline number. It is not primarily a story about how much AI can produce. It is a story about what the developer's job is now, and whether the tools organizations use to measure that job have kept up.
At xeve, we track time across every app and activity in the development workflow — not just coding sessions, but time in code review, planning tools, communication, and specification work. The shift from generation to direction shows up clearly in that data when it happens: coding time drops, review time grows, and total hours often stay constant or increase. What changes is the distribution. The developers who have the clearest read on whether they have crossed into majority-AI-code territory are the ones who can see that distribution across the full workday, not just the editor. At 52% production AI code share across the industry, that view is no longer a nice-to-have. It is how you know what your job actually is.