A company just proved the 2x AI coding mandate is achievable. They hit 2.09x merged pull requests per engineer over 26 months, one of the largest gains documented in a field deployment of AI tools. The catch, buried in the methods section: the gains were concentrated in newer repositories and barely present in legacy ones.
That's not a footnote. It's the whole story.
The paper, published July 2 on arXiv, tracked 802 developers and 196,212 pull requests at a mid-sized AI-forward company that committed to doubling PR throughput per engineer starting mid-2025. They got there. But when the researchers sliced the data by repository age, the distribution was stark. New repos carried almost all of the gain. The legacy codebases that form the operational backbone of most software teams looked essentially the same as before.
Why This Explains the Plateau
DX spent 15 months analyzing engineering velocity across 400+ companies. AI tool usage rose 65% during that window. Median PR throughput rose 7.76%. That gap — a fraction of a point of throughput per ten points of AI adoption — is the number most teams are actually experiencing.
The greenfield concentration explains it. Enterprise development skews toward legacy code. New features get bolted onto existing systems. Bug fixes live in modules written before the current team arrived. Refactors, migrations, and integrations are all fundamentally legacy-first activities. If AI gains concentrate in new repos, and new code represents a minority of actual engineering work, the aggregate number is going to be small — even if the wins in the new code are real.
McKinsey found the same pattern from a different angle. Their survey of 4,500 developers found AI coding tools reduce time on routine tasks by 46%. The same data shows that number falls to under 10% on high-complexity engineering work. Legacy maintenance is complex, context-dependent, and almost by definition high-stakes. It's the hardest category for current AI tools to touch.
What Makes Legacy Code Resistant
The mechanism isn't mysterious. AI coding tools work well when context is visible — when the codebase is small enough to fit in the window, the patterns are standard, and the right approach can be inferred from similar code the model has seen. Greenfield repos start from scratch and accumulate that clarity. A new repo in 2025 is likely TypeScript with a modern framework, documented APIs, typed interfaces, and a test suite that was written alongside the code.
Legacy codebases are the opposite. They carry implicit constraints that no one documented because everyone who knew them has left. They have patterns that made sense in 2017 and now exist because changing them breaks something downstream that no test covers. They have security models that live in the heads of senior engineers who've been paged at 3am for incidents the junior developers have never seen.
When you prompt an AI assistant to add a feature to code like this, you get something that compiles. What you don't get is assurance that it respects the invariant three layers up that the model couldn't see. The review cost on AI-assisted legacy code is high precisely because that invisible context has to be verified by a human who carries it. The gains on greenfield code are high precisely because the context is visible and verifiable quickly.
The arXiv paper captured this directly: their gain was "statistically indistinguishable across the seniority ladder from individual contributors to principals" — which means seniority wasn't the differentiator. What mattered was the repository the developer was working in.
The Legacy Maintenance Decline Is a Separate Problem
Here's where things get uncomfortable. GitClear's 2026 maintainability analysis found that long-term legacy maintenance in AI-heavy repositories is down 74% versus 2022 levels. Refactoring — the work that keeps legacy code from accumulating structural debt — fell from 24% to 9.5% of changed lines as AI adoption grew.
This means AI tools aren't just neutral on legacy code. They're actively deprioritizing it. The workflow AI enables — describe what you want, get code, move on — pushes against the reading and rereading of existing code that maintenance requires. Developers working in AI-native flows generate more code in less time. That code goes to greenfield work, where the productivity signal is good, and the legacy work sits.
The implication: while your new repos are getting more productive, your legacy systems may be getting less maintainable. If the company in the arXiv study ran this analysis, their impressive 2.09x number might look different against the backdrop of what's happening to the codebases that didn't capture gains.
The Mandate Math Doesn't Generalize
The 2x mandate is a real result from a real company. But it was achieved at a place that self-described as "AI-forward" with enough greenfield work in their mix to capture the gains. If your engineering team spends most of its time in a decade-old monolith, a mandate to double PR throughput is a mandate to generate more pull requests in the code that AI struggles with most.
The Opsera 2026 benchmark report found that senior engineers capture nearly 5x the productivity gains of junior engineers from AI tools. Part of that gap is skill. Part of it is that senior engineers have more discretion over which code they work in — they can route toward the greenfield work that benefits, while junior engineers inherit the maintenance burden. The mandate's gains concentrate by repository and seniority together.
None of this is an argument against using AI tools aggressively. The greenfield gains are real. For teams building new products, starting new services, or adding new modules to systems with clean abstractions, the 2x number is achievable. The arXiv paper proves it.
But for engineering leaders being asked whether AI will double their team's output: the honest answer is it depends which output. If the work is greenfield-heavy, you're in the right category. If the work is legacy-heavy — and for most enterprise teams it is — the gains will be concentrated in a small slice of what the team actually does, and the 10% aggregate is probably more accurate than the 2x story.
What to Actually Track
Most teams watching this space are tracking AI adoption and PR count. Those are the input and the output that make the mandate story legible. What they don't show is where the gains are landing.
The useful question is: what fraction of your team's work is in repositories created in the last two years? That's a rough proxy for the greenfield proportion of your productivity surface. If it's 30%, then at best you're unlocking AI's benefits on 30% of your engineering hours. The 70% that lives in legacy code is still constrained by the same factors it always was.
Tracking coding time by project and repository age doesn't require a mandate. It just requires knowing where your hours are going. Most developers who've run that analysis find the split is more legacy-weighted than they'd estimated, which is exactly the kind of data point that changes how you read a 2.09x headline.
The result is real. The distribution is what matters.