Incidents Per Pull Request Are Up 243 Percent: The AI Productivity Gain Has a Bill

TL;DR: While AI coding tools have increased PR throughput by 16%, telemetry across 22,000 developers shows that the probability of an incident per merged change has tripled. This ai productivity paradox creates a massive operational debt that is currently unbudgeted and landing squarely on SRE and on-call teams.

The number everyone skipped

The industry has spent the last year obsessed with the "top line" of AI-assisted development: how many more tickets we can close and how many more lines of code we can commit. However, the Faros AI Engineering Report 2026, which analyzed telemetry across 22,000 developers and more than 4,000 teams, revealed a staggering counter-metric: incidents per PR are up 242.7 percent.

To be precise, this doesn't just mean we have more incidents because we are shipping more code. It means the change failure rate has shifted fundamentally; there is now a significantly higher probability of an incident for every single merged change.

When measuring the impact of AI, total incident count is a vanity metric that can be hidden by volume. The "incidents per PR" figure is the only honest denominator. It reveals that while AI helps us write code faster, the quality of that code—or the system's ability to absorb it—is degrading at a non-linear rate.

The full table: Both directions of the ai productivity paradox

The data reveals a clear dichotomy. While productivity metrics (output) are rising, stability and process metrics (outcomes) are cratering.

Faros refers to this phenomenon as "Acceleration Whiplash." We are pushing the gas pedal on code generation, but the "brakes"—our review processes and testing suites—are failing to keep pace.

Do the multiplication

The true cost of the ai productivity paradox isn't found in a single row of a table; it's found in the multiplication of throughput and failure rate.

Consider a hypothetical engineering team that previously shipped 200 PRs a month with a 1% incident rate (2 incidents/month). If that team adopts AI and sees a 16% increase in PRs (232 PRs) but their incident probability per PR triples (to 3%), they are now dealing with ~7 incidents per month.

Key Takeaway: The operational load does not rise linearly with AI code generation; it compounds as higher throughput meets a higher probability of failure per change.

This load lands on triage teams, on-call rotations, and customer support escalations. It consumes the time of "load-bearing" senior engineers who are the only ones with enough context to debug ai generated code technical debt that the original author may not fully understand.

The instruments disagree, and that is the finding

There is a glaring conflict between two of the industry's most cited data sources. According to the DORA 2025 report, which surveyed nearly 5,000 developers, AI acts as an "amplifier" where strong organizations get stronger, and there is notably no correlation between AI adoption and burnout.

However, the Faros telemetry—actual system data rather than self-reported sentiment—presents a grimmer view. It found no evidence that strong pre-AI engineering maturity protects against this quality degradation.

This suggests a measurement gap: Surveys measure how developers feel; telemetry measures what the system produces. A survey finding of "no burnout" sitting right next to a 26% rise in stalled work and a 13.8% rise in work restarts is not reassuring. It suggests that developers may feel productive in the IDE, while the actual delivery pipeline is becoming a congested, high-failure environment.

Why review is the visible bottleneck and operations is the invisible one

We talk about PR review times because we can see them. A 441% increase in median PR review time is a metric that hits a dashboard and demands a meeting.

What we aren't discussing is the "hidden" 31% of PRs now merging with no review at all. As human reviewers become overwhelmed by the 51.3% increase in PR size, they either slow down (the bottleneck) or give up (the safety risk).

The resulting operational absorption—the hours spent by SREs fixing what the "productive" developers broke—is rarely tracked as a cost of the AI transformation. It is simply treated as "unplanned work," which historically consumes 30-40% of engineering capacity and is now trending higher.

What DORA actually recommends, and what it leaves out

The DORA 2025 report outlines seven key capabilities for AI success, including healthy data ecosystems, version control practices, and small batches. While these dora metrics are essential for production, they focus almost entirely on the creation of code.

None of the current models sufficiently address the operation of AI-augmented systems. For example, DORA emphasizes "small batch discipline," yet telemetry shows PR sizes are actually ballooning by over 50%. This is a direct, unresolved tension: AI makes it too easy to create "large batches" that human reviewers cannot safely parse.

What to measure instead

To navigate the ai productivity paradox, leaders must look beyond task completion rates.

1. Incidents per merged change: Stop looking at total monthly incidents; look at the failure rate of the individual unit of work.
2. Operational hours per merged change: Track the time spent on triage and fixes relative to the volume of new code.
3. Stalled work and restart rate: These are your leading indicators of burnout and process collapse that surveys will miss.

The uncomfortable budget question

If AI adoption is funded as a "productivity investment," the resulting operational load is a direct cost of that investment. It belongs in the same business case. You cannot credit the 16% gain in PRs to the AI budget while offloading the 243% increase in incident probability to the "on-call" budget.

We are entering an era where the speed of code generation has permanently outrun the speed of human operational oversight.

Why this matters now: As organizations finalize their 2026 budgets, many are doubling down on AI coding assistants based on 2025's optimistic survey data. But the telemetry is clear: the bill for all that "productivity" is arriving in the form of operational instability.

The operational load identified in these numbers represents real work that no one was hired to do. This is precisely why we built Operate. Operate is a self-hosted AI SRE platform designed to bridge this specific gap. It works reactively to investigate incidents from Slack or Teams, and proactively by monitoring for exceptions, silent failures, and latency regressions.

Unlike coding assistants that increase the volume of changes, Operate uses a multi-agent pipeline to find root causes with evidence. When a fix is needed, it proposes a patch for human review. It doesn't replace the engineers absorbing this new load—it simply ensures they don't have to do the manual heavy lifting alone.

Sources & further reading

• According to Faros AI, telemetry across 22,000 developers shows incidents per PR have increased by 242.7%.
• The DORA 2025 Report frames AI as an amplifier of existing organizational strengths and dysfunctions.
• The DORA Publications index confirms that current research focuses heavily on the ROI of AI-assisted software development and the initial "productivity dip."