If your rotation feels heavier this year and nobody has shipped a major architectural change, the cause may be sitting in your pull request queue. AI-generated code incidents are now a measurable operational category, not a talking point. In a telemetry study of roughly 22,000 developers across more than 4,000 teams, Faros AI found that incidents per pull request rose 242.7 percent in organizations with high AI adoption compared with organizations with low adoption. Throughput rose too, by about 34 percent per developer. The delivery side got faster. The operations side absorbed the difference.

That is the whole story in one sentence, and it is why on-call teams should care more about this report than most engineering leadership decks do. Nothing here says AI-assisted development is a mistake. It says the rate of change entering production has moved, the failure modes have shifted shape, and most incident response processes were designed for a slower, more human-paced flow of changes. This post walks through what the data shows, why AI-authored changes break in unfamiliar ways, what that does to a rotation in practice, and a concrete playbook for absorbing the new load without quietly burning out the people who carry the pager.

What the 2026 data says about AI-generated code incidents

The Faros AI report, published in April 2026 and titled The Acceleration Whiplash, is useful because it is telemetry rather than opinion survey. It compares two years of before-and-after delivery data across a large population, which means it captures what actually landed in repositories and what actually paged someone, not what engineers believe happened.

Throughput went up, and so did everything downstream

The headline numbers pull in two directions at once. Individual throughput rose 34 percent. Epics completed per developer rose 66 percent. Those are real gains and they are the reason AI-assisted development is not going away.

Then the counterweight. Bugs per developer rose 54 percent. Median pull request review time rose 441 percent. Pull request size rose 51.3 percent. Code churn, the measure of code rewritten shortly after being merged, rose 861 percent. And incidents per pull request rose 242.7 percent. The pattern is consistent: generation accelerated, and every downstream stage that depends on human attention became a queue.

Why incidents per pull request is the number on-call should watch

Raw incident counts are easy to dismiss. A team ships more, so of course it breaks more. Incidents per pull request removes that excuse. It is a rate, normalized against the volume of change. A 242.7 percent increase in that rate means each individual change is substantially more likely to cause a production problem than it was before, not merely that there are more changes.

For an on-call engineer, that reframes the job. The rotation is not just seeing more pages because the company grew. It is seeing a higher failure yield per unit of work, which compounds against higher volume. Two multipliers, same number of people holding the pager.

The corroborating signal from the maturity side

The Perforce 2026 State of DevOps Report, based on responses from 820 technology professionals gathered in late 2025, points at the other half of the picture. Organizations with mature DevOps practices were 66 percent more likely to say they respond very effectively to production incidents, and the report attributes that to concrete mechanics: automated rollback paths and clear, rehearsed processes.

Read the two reports together and the conclusion is not subtle. The inflow of risk has increased. The teams that handle it are the ones whose response machinery was already good. Teams with a vague escalation path and a rollback procedure that lives in one person's memory are the ones absorbing the whiplash with overtime.

Why AI-authored changes fail differently

Understanding the failure shape matters because it determines where you spend your detection budget. AI-generated code does not fail like junior developer code, and it does not fail like a rushed hotfix. It has its own signature.

Plausible code with wrong assumptions

The most common pattern is code that is syntactically clean, idiomatic, well-named, and confidently wrong about something environmental. It calls an API with a parameter that existed in a prior version. It assumes a timeout default that your platform overrides. It handles the happy path and one obvious error case, and silently swallows the third. It reimplements a helper that already exists in your codebase with subtly different null handling.

None of these trip a linter. Many do not trip a unit test, because the same tool that wrote the code often wrote the test, and the test encodes the same wrong assumption. They surface in production, under real traffic, at the boundary between your service and something else. That is precisely the class of failure that static analysis catches least and on-call catches most.

Larger changes moving through a slower review queue

The 51.3 percent increase in pull request size and the 441 percent increase in review time interact badly. A bigger diff takes longer to review carefully, so reviewers under time pressure adopt the rational strategy of skimming. The reviewer approves the shape of the change rather than the substance. Review stops being a defect filter and becomes a formality.

That has a direct on-call consequence. When the change that caused the incident was never truly read by a second person, the incident commander cannot lean on anyone's mental model of it during triage. The knowledge simply is not in the room.

Churn as a leading indicator

The 861 percent churn increase deserves attention because churn is a leading indicator that most teams already collect and nobody watches. Code rewritten within a few weeks of merge is code that did not work the first time. High churn in a service is a signal that the service is currently accumulating fragility, which is exactly the sort of thing you want on the on-call handoff note before the weekend.

Diffuse authorship

Traditional triage relies heavily on a social shortcut: find the person who wrote this and ask them. When a meaningful share of a diff was generated rather than typed, the listed author may have reviewed the change quickly and moved on. They are still the right person to page, but their recall is shallower and their confidence is often higher than it should be. Incident commanders need to plan for that gap rather than being surprised by it at three in the morning.

What this does to a rotation in practice

More pages, unchanged headcount

Very few organizations expanded their on-call rotations in proportion to their AI adoption. The typical shape is a team that added AI tooling, celebrated a throughput gain, and kept the same six people rotating weekly. If failure yield per change is up meaningfully and change volume is up a third, the person on call this week is carrying a materially heavier load than the person who held the same rotation eighteen months ago, with no acknowledgment that anything changed.

This is how burnout arrives without a triggering event. There is no single terrible week to point at. There is a slow ratchet, and the people who feel it first are usually the most senior engineers, because escalation gravitates toward them.

Triage takes longer per incident

Even holding severity constant, the mean time to understand goes up. The responder opens the suspect diff and finds a change that is larger than usual, written in a style that does not match the surrounding code, with a commit message that describes intent accurately but omits the reasoning. Reconstructing why the change was made the way it was takes longer, and the usual shortcut of asking the author yields a thinner answer.

Postmortems drift toward the generic

The honest root cause for a growing share of incidents is something like: a change was generated, reviewed superficially, and made an incorrect assumption about a dependency. That is uncomfortable to write down, so it tends to get laundered into a softer finding about insufficient test coverage. The action item becomes add more tests, which addresses a symptom and nothing else. Over time the postmortem corpus stops reflecting reality, and the organization loses its main instrument for learning.

A practical playbook for absorbing the load

None of the following requires banning AI tooling, which would be both unpopular and a competitive mistake. It requires treating change provenance as operational data and tightening the loop between deploy and detect.

Instrument change provenance

Tag pull requests with a signal for AI involvement. Many teams already have a commit trailer or a bot label available. Feed that tag into your incident records so that within a quarter you can answer a specific question about your own organization rather than an industry average: what share of our sev1 and sev2 incidents traced back to changes with heavy AI authorship, and is that share moving? Your number may be better or worse than the study. Either way you now have a local baseline to manage against.

Shorten the deploy-to-detection window

If failure yield per change is up, the single highest leverage improvement is catching the bad change closer to the moment it ships. That means canary or progressive rollout for anything customer facing, automated rollback triggers wired to error rate and latency rather than a human noticing a dashboard, and deploy events posted into the same channel where the on-call engineer already lives. The Perforce finding about automated rollback is the practical core of the whole report: the teams that respond well are the teams that can undo a change without a meeting.

Make rollback the default first move

Write it into the runbook explicitly. When a recent deploy correlates with a new alert, the first action is to revert, and diagnosis happens afterward on a stable system. This feels wasteful to engineers who want to understand the failure, and it is the correct trade in almost every case. It becomes more correct as change volume rises, because the cost of a wrong revert falls when deploys are cheap and frequent.

Rebalance review capacity honestly

If generation capacity increased and review capacity did not, the queue is a mathematical certainty. Options include capping pull request size, requiring a second reviewer for anything touching a service on the current high-churn list, or explicitly allocating review time in sprint planning rather than treating it as free. Some teams have had success requiring the author to write a short plain-language explanation of what the change does and why, which is a cheap and surprisingly effective filter against changes nobody actually understood.

Rebuild the alert-to-owner path

Higher incident volume punishes every gap in routing. An alert that fires into a channel nobody watches, an escalation policy with a stale phone number, a rotation that silently has nobody assigned during a holiday: all of these were survivable at lower volume and become expensive now. Audit the path from alert to acknowledged human, end to end, and test it with a real page rather than assuming it works.

Track your own whiplash metric

Pick one rate and watch it monthly. Incidents per deploy is the simplest. Change failure rate works if you already collect it. The point is not benchmarking against the industry, it is noticing your own trend early enough to act on it rather than discovering it in an exit interview.

Tag AI involvement on changes and join it to incident records, so you can measure your own failure yield instead of guessing.
Automate rollback triggers tied to error rate and latency, because the mature-response advantage in the survey data comes from mechanics, not from heroics.
Revert first, diagnose second whenever a recent deploy correlates with a new alert.
Cap pull request size and protect review time explicitly, since review is now the bottleneck stage.
Watch code churn per service as a leading indicator and put high-churn services on the on-call handoff note.
Test the full alert-to-human path quarterly, including escalation and holiday coverage.
Name the real root cause in postmortems, even when it is a review process failure rather than a test coverage gap.

Where tooling has to change

Response belongs where the work already happens

When incident volume rises, every context switch is a tax paid many times over. A responder who has to leave chat, open a separate incident console, find the deploy history in a third place, and then come back to communicate is losing minutes per incident that compound across a week. The teams handling higher volume well have generally collapsed that surface: the page arrives, the rotation is visible, the incident channel opens, the deploy timeline is attached, and the status update goes out, all without leaving the place the team already works.

This is the practical argument for Slack-native on-call tooling rather than a stylistic preference. Pagerly runs rotations, paging, incident channels and status updates inside Slack precisely because the marginal cost of a context switch scales with incident count. At two pages a week the overhead is invisible. At eight it is the difference between a manageable rotation and a bad one. The same logic applies to schedule overrides and swaps: when the load goes up, the friction of arranging coverage determines whether people actually get relief or just quietly absorb it.

Alert quality matters more, not less

A rising incident rate makes noisy alerting far more damaging, because the responder is already operating with less slack. This is the moment to cut alerts that have never once led to an action, consolidate duplicate signals from overlapping monitors, and make sure each remaining alert names the service, the likely blast radius, and the first diagnostic step. Alert hygiene is unglamorous and it is the cheapest capacity you can add.

What to do this week

The uncomfortable reading of the 2026 data is that a lot of organizations have already taken the throughput gain and are paying for it on the operations side without having decided to. The gain is real and worth keeping. The bill is being sent to a small number of people who rotate through a pager, and in most places nobody has looked at the invoice.

Three things are worth doing in the next week, and none of them require a budget. First, pull the last quarter of incidents and check honestly how many trace to a recent change that nobody deeply reviewed. Second, verify that you can roll back your highest traffic service automatically, and time it. Third, ask the people currently on call whether the load has changed, and listen to the answer rather than benchmarking it against a report.

The industry data gives you the shape of the problem and a reason to take it seriously. Your own numbers tell you whether you have it, and how badly. The teams that come out of this era well will not be the ones that adopted AI tooling fastest or slowest. They will be the ones that noticed the operational bill early and built the response machinery to pay it.