On-Call for Code You Didn't Write (2026)

Key Takeaways

• The ratio that matters is code in production over code you can debug under pressure, and it moved. Brent Chapman put it best in June 2026: "the team's ratio of 'code in production' to 'code we understand deeply enough to debug under pressure' has shifted. And it's shifted in the wrong direction for incident response."
• AI's measured effect on delivery is faster and less stable. DORA 2025 found throughput turned positive but "AI adoption does continue to have a negative relationship with software delivery stability." Their diagnosis is the actionable part: instability comes from change volume outrunning your control systems.
• Codebases are getting harder to read, on the metrics that predict debuggability. GitClear's analysis of 623 million changes reports refactored "moved" code falling from 21% in 2022 and 13% in 2023 to 3.8% in 2026, while block duplication, per million changed lines, rose from 40.3 in 2023 to 73.0, and copy-paste went from 9.4% to 15.7%.
• Oversight has thinned to one person. A study of 25,264 agentic pull requests across 2,361 repositories found that in 78.9% of them a single developer both reviewed and modified the agent's contribution.
• The 3am problem is not AI-specific, and that is why the fix is not either. Google's SRE book has said for years that "roughly 70% of outages are due to changes in a live system". More changes, same causal mechanism.
• Rollback beats reading. You cannot review at generation speed. Google's canary math and Stripe's 30% pager-volume reduction both work by containing changes rather than understanding them faster.
• We are not claiming AI code causes outages. The honest reading is that AI raises change volume and lowers shared understanding, and on-call pays for both. We engage the counter-argument below.

Being on-call for code you did not write is the 2026 version of an old problem: the volume of change entering production has grown faster than any individual's understanding of it, and incident response is where that gap gets settled. The mechanism is not that AI writes bad code. It is that AI writes more code, reviewed by fewer people, in a form that is measurably harder to read later.

This post separates what the data supports from what it does not, then covers what actually helps at 3am.

What the evidence actually says

Start with what is measured, because this topic attracts a lot of assertion.

Delivery stability is the persistent negative. DORA's 2024 report found AI adoption "negatively impacts software delivery stability and throughput." The 2025 edition revised half of that: "Unlike last year, we observe a positive relationship between AI adoption on both software delivery throughput and product performance." But the other half held: "AI adoption does continue to have a negative relationship with software delivery stability."

DORA's explanation of the mechanism is the most useful paragraph published on this subject:

"AI accelerates software development, but that acceleration can expose weaknesses downstream. Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability."

That framing puts the problem where you can act on it. The defect is not in the generated code, it is in whether your delivery pipeline can absorb more of it.

Developers do not trust the output, and the failure mode is specific. Stack Overflow's 2025 survey found "more developers actively distrust the accuracy of AI tools (46%) than trust it (33%)," and identified the dominant frustration precisely: 66% cite "AI solutions that are almost right, but not quite," with 45% saying debugging AI-generated code is more time-consuming. Almost-right is the worst possible property for code you will meet for the first time during an outage. DORA 2025 corroborates the trust gap: 90% report using AI at work while 30% report "little or no trust" in what it generates.

Codebases are trending toward harder-to-read. GitClear analysed 623 million changes from 2023 to 2026 and reports that "moved" code, their proxy for refactoring, fell from 21% in 2022 to 13% in 2023 and 3.8% year-to-date in 2026, while block duplication, measured per million changed lines, climbed from 40.3 in 2023 to 73.0 in 2026 year-to-date, and copy-paste rose from 9.4% to 15.7% in the first half of 2026. Every one of those metrics is a proxy for how easy the code will be to read later, which is exactly the property you need at 3am. Treat this as vendor telemetry rather than peer-reviewed work, and note GitClear's own honesty about causation, which we come back to below.

Review has become a single point of contact. The agentic pull request study (July 2026) is the most concrete data point in the set: across 25,264 agentic PRs in 2,361 repositories, in 78.9% of them "a single developer both reviews and modifies the agent-generated contribution." Adding the pattern where one reviewer makes no commits, "these two single-human workflows account for 88.7% of all agentic PRs."

That last finding is the one with direct on-call consequences. Traditional code review distributed understanding across a team as a side effect. Armin Ronacher named what is lost: "This friction synchronizes people. Some of it was the process by which your understanding became mine, and by which both of us discovered whether we still agreed about how the system worked." Remove the friction and you keep the velocity while losing the synchronisation. At 3am, the synchronisation was the point.

Thoughtworks gave the resulting condition a name in its April 2026 Technology Radar, placing codebase cognitive debt in the Caution ring: "the growing gap between a system's implementation and a team's shared understanding of how and why it works."

What the evidence does not say

Three things, stated plainly, because this is where similar posts overreach.

It does not say AI-generated code causes more outages. No study we found establishes that. DORA measures a relationship with stability and attributes it to change volume and missing control systems, not to defective code. Anyone citing DORA as proof that AI code is buggy is misreading it.

It does not establish that AI caused the code-quality decline. A separate January 2026 GitClear report, AI Coding Tools Attract Top Performers, But Do They Create Them?, finds AI users authoring four to ten times more work than non-users while conceding "Weekly 'Commit Count' is far from an end-all productivity metric," and raises selection effects as an alternative explanation. Duplication rising alongside AI adoption is correlation, and the people publishing the data say so.

It does not show a documented major outage caused by AI-written code. We looked specifically. The widely circulated claim that an AI tool caused a 13-hour AWS service interruption, per the Financial Times account, traces to Financial Times reporting sourced to four anonymous people, describes an agent taking an autonomous infrastructure action rather than generating code, and Amazon disputes it directly, attributing the event to misconfigured access controls rather than AI. There is no AWS post-event summary for it. We are not going to build an argument on a contested anecdote, and you should be sceptical of posts that do.

There is also a serious counter-argument worth stating in its strongest form: a misconfigured permission is a misconfigured permission regardless of what triggered it. Amazon's position is essentially that this class of failure "could occur with any developer tool (AI powered or not) or manual action," and that is not obviously wrong. The 2026 reframing is about volume and distribution of understanding, not about a novel defect class.

One widely quoted counter-statistic deserves a correction rather than a citation. METR's 2025 randomised trial found experienced developers took 19% longer with AI tools while believing they had been sped up, and that figure is still widely circulated. But METR's own page now carries a notice: "These results are out of date. We have released results that are current as of early 2026, in a continuation of this study." Their February 2026 continuation points toward a speedup rather than a slowdown, though with confidence intervals crossing zero and METR itself cautioning there is "very weak evidence for the size of this increase." If you have been citing the 19% slowdown as a current finding, stop; the authors say it no longer reflects present-day impact.

Why on-call absorbs it

The causal chain is short and each link is sourced.

Google's SRE book established the base rate long before this debate: "roughly 70% of outages are due to changes in a live system". If most incidents arrive by deploy, then raising deploy volume raises incident volume mechanically, with no need for the code to be worse.

Now add the second effect. Investigation speed depends on someone recognising the code. With 78.9% single-reviewer oversight, the probability that the person on-call has read the change that broke production has fallen. SRE Weekly's summary of Chapman's piece put the practical question as: "when that new code breaks in production at 3am, how well can the on-call engineers debug it?"

So: more changes reaching production, and fewer people carrying context about any given one. Both curves point at the same person.

What actually helps

Ordered by evidence, not by novelty.

1. Mark AI-authored changes, so provenance survives to the incident. The strongest precedent is not a vendor practice but a project policy: the Linux kernel requires disclosure. "If you used any sort of advanced coding tool in the creation of your patch, you need to acknowledge that use by adding an Assisted-by tag." And it draws the accountability line explicitly: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)."

For on-call this is not a compliance exercise. It is metadata that tells you, at 3am, whether the change you are staring at was reviewed deeply or approved quickly, and who to wake. No industry-wide standard exists yet, so adopt the kernel's convention rather than waiting for one.

2. Invest in rollback speed, not review throughput. You cannot read at generation speed. Rootly's May 2026 argument is blunt about the queueing reality: "A human trying to read AI-written code at AI's writing speed isn't running a process: it's running a queue with a person at the front of it apologizing." Their conclusion: "The constraint has moved from how fast you can write code to how confidently you can ship it." They disclose their own exposure, reporting that over 80% of their pull requests have AI as the primary author.

3. Canary, and know the arithmetic. Google's SRE Workbook gives the cleanest version of why partial exposure works: "If we instead use a canary population of 5%, we serve 20% errors for 5% of traffic, resulting in a 1% overall error rate." A change you do not understand is exactly the change that should meet 5% of traffic first.

4. Prefer deterministic remediation where it fits. Stripe's July 2026 writeup reports "a 30% reduction in pager volume (~200 fewer pages a year)" and "12 fewer days of shards stuck in unhealthy states annually", using state machines and graph search, with no model in the loop as described. Their design principle is worth stealing: "Instead of writing runbooks for anticipated scenarios, we define invariants and available operations, and let the algorithm compose them into recovery plans." If a failure class is well understood, do not point a model at it.

5. Build the control systems DORA names. Strong automated testing, mature version control practice, fast feedback loops. This is the least exciting item and the one with the most authoritative backing, since it is DORA's own prescription for exactly the instability they measured.

6. Break the single-reviewer pattern on production paths. Given 78.9%, requiring a second reviewer on agent-authored changes touching critical paths is a targeted intervention rather than blanket process. Thoughtworks' companion entry, feedback sensors for coding agents, notes that "developers have long relied on deterministic quality gates such as compilers, linters, structural tests and test suites; here, they're wired into agentic workflows so that failures trigger timely self-correction," which catches mechanical problems before a human queue forms.

What this means for AI in the investigation

There is an obvious tension in an AI SRE vendor writing this post, so let us be direct about it.

If the problem is that nobody on the team has read the code, an agent that can read all of it quickly is genuinely useful. Reading unfamiliar code fast, correlating a deploy with an onset time, and checking whether a commit actually reached production is mechanical work, and it is the part of investigation that scales badly for humans at 3am.

But the same evidence that motivates the post limits the claim. Agents are unreliable at exactly the step that matters most: OpenRCA 2.0 found agents name a correct service 76.0% of the time but ground it in a verified causal path only 61.5% of the time. An agent that hands you a confident wrong cause for unfamiliar code is worse than no agent, because you have no independent basis to doubt it. That is the failure mode we cover in AI SRE accuracy.

The honest positioning: an agent should compress the evidence-gathering, state what it ruled out, and be explicit when it could not confirm the mechanism. Aurora's investigation prompts encode two rules that matter specifically here, and they are readable in the open-source repository rather than asserted in marketing. First, that "merged does not always mean deployed", so a commit on main is not evidence it is running. Second, that a symptom is not a cause: "the pod is OOMKilled" is a symptom, while "memory leak in the request parser introduced in commit X" is a root cause. Both exist because change attribution is where investigations of unfamiliar code go wrong.

The 3am checklist

When you are paged for code you have never read:

1. Establish what changed and whether it actually shipped. Merged is not deployed. Confirm the running version before building a theory on a commit.
2. Check provenance and reviewers. Who approved it, how fast, and was it agent-authored. This tells you how much latent understanding exists in the org and who to wake.
3. Decide rollback versus forward before diagnosing. If rollback is cheap and fast, that decision does not require understanding the code, and it buys you daylight. Note the tradeoff: rolling back can destroy the state you would need to understand the failure.
4. Reduce exposure rather than fixing. Feature flag off, shift traffic, scale the healthy path. All available without understanding.
5. Distinguish symptom from mechanism before you write the postmortem. An unread codebase makes it very easy to stop at the symptom, and a postmortem that stops there guarantees the recurrence.
6. Record what you learned where the next person will find it. The context that used to spread through review has to be rebuilt somewhere, and an incident is when it is cheapest to capture.

The summary

The claim worth making is narrow and holds up: AI raises the volume of change entering production and reduces the number of people who understand any given change, and on-call absorbs both effects. The claim not worth making is that AI writes code that breaks more often, because nobody has shown that.

The fixes follow from the narrow claim, which is convenient, because they are things good teams were already doing: contain changes, roll back fast, keep provenance, and build the control systems that let higher change volume be safe. None of it requires the code to be good. That is the point.

Run it against your own unfamiliar code

Aurora is Apache 2.0, so you can put an agent on your own codebase in about five minutes and judge the change-attribution quality yourself. The only external requirement is one LLM API key; cloud connectors are optional.

git clone https://github.com/arvo-ai/aurora.git && cd aurora

make init                # generates secrets, copies .env.example to .env
nano .env                # add OPENROUTER_API_KEY (or OPENAI_API_KEY / ANTHROPIC_API_KEY)
make prod-prebuilt       # pulls prebuilt images from GHCR and starts

Open http://localhost:3000. The first user to register becomes admin.

Point it at a service nobody on your team wrote and see whether its change attribution holds up. The two rules quoted earlier, that merged does not always mean deployed and that a symptom is not a root cause, ship as part of the open-source investigation prompts rather than as a marketing claim, so the behaviour you get locally is the behaviour we described.

• Start free: aurora-ai.net (hosted, no infrastructure to run)
• GitHub: github.com/Arvo-AI/aurora
• Related guides: PR Risk Review: Catch Incidents Before Merge · The Agent-to-Human Handoff · AI SRE Accuracy · Root Cause Analysis for SREs

Sourcing note. Delivery data comes from DORA's 2024 and 2025 reports, developer sentiment from the Stack Overflow 2025 survey, code-quality metrics from GitClear's own telemetry (attributed as vendor research), oversight data from the agentic pull request arXiv preprint, and remediation practice from Google's SRE Workbook and Stripe's engineering blog. Claims this post deliberately does not make are listed in the second section. Verified July 28, 2026.