AI-Generated Code Incidents: What the 2026 Data Shows

In March 2026, Amazon's senior vice president for eCommerce services called an internal "deep dive" meeting after a run of high severity outages on the retail site. According to reporting from CNBC and TechRadar, the memo behind that meeting described a "trend of incidents" characterised by "high blast radius" and, in the company's own phrasing, "Gen-AI assisted changes." One of the contributing factors listed was novel GenAI usage for which best practices and safeguards were not yet fully established. Amazon's remedy was to require additional senior engineer review of GenAI-assisted production changes.

That memo is the clearest signal yet that AI-generated code incidents have stopped being a talking point and started being an operational category. Not a hypothetical risk in a vendor whitepaper, but a named pattern in an internal escalation document at one of the largest engineering organisations on earth, serious enough to change the code approval process. This post pulls together what the 2026 data actually says, walks through four incidents worth studying in detail, and lays out what changes for the people carrying the pager.

How much of your code is AI-written, really

Start with the denominator, because most arguments about AI code quality are really arguments about volume.

Sonar's 2026 State of Code Developer Survey, covering more than 1,100 professional developers, found that AI now accounts for 42% of committed code, with developers predicting that share will reach roughly 65% by 2027. Veracode's research puts it higher in organisations that have fully adopted AI coding tools, at roughly half of all committed code. GitClear's corpus for the same period covers 623 million real code changes from 2023 to 2026.

The methodologies differ and the numbers should be read as a range rather than a point estimate. But the direction is not in dispute, and neither is the second finding, which is more interesting than the first: adoption has vastly outrun trust. In the Sonar survey, 96% of developers said they do not fully trust AI-generated code, and only 48% said they always verify it before committing. Separately, 38% reported that reviewing AI code takes more effort than reviewing a colleague's.

Hold those two facts next to each other. Nearly half the code going into production is machine-authored. Barely half of it is verified before it gets there. The gap between those numbers is where your incident load lives.

The crossover: when copying overtook refactoring

The most rigorous longitudinal data on what this is doing to codebases comes from GitClear, which has been measuring the same code quality signals across the entire AI adoption window. One pair of those signals tells the story better than any survey.

Refactoring shows up in a diff as moved lines: code relocated, consolidated, reused. Copying shows up as duplicated lines. Healthy codebases do more of the first than the second, and for as long as anyone has measured it, they did. Then that reversed.

In 2021, refactored lines made up 25% of changed lines and copy/pasted lines 8.3%, a ratio of roughly three to one in favour of reuse. By 2024, GitClear reports refactoring had sunk below 10% while copy/paste reached 12.3%, the first year on record that copying exceeded refactoring. By the first half of 2026 the gap had widened further: 3.8% refactored against 15.7% copied, which is now roughly a four to one preference in the opposite direction.

The reason this matters operationally is that duplication is a distributed bug. A defect in refactored code exists once. The same defect in copied code exists in every copy, and no index tells you where the copies are. That is the difference between a fix and a search.

The maintainability gap, across all signals

The crossover is one pair of signals. GitClear's 2026 Maintainability Gap research tracks eight, split into behaviours that build reuse and behaviours that accumulate risk. Indexed to 2023, every single one has moved in the wrong direction.

What each of those signals means at 3am

These are not abstract hygiene metrics. Each one maps to a specific way an incident gets harder.

Block duplication climbed 81%, from 40.3 duplicated lines per million changed lines in 2023 to 73.0 in 2026. During an incident, duplication is what turns a one-line fix into a hunt. You patch the validation bug, ship it, and the error rate drops by half instead of to zero, because the same five lines exist in three other files that the AI generated independently rather than calling a shared helper.

Error-masking constructs rose 47%. This is the one that should worry on-call engineers most. An empty catch block, a swallowed exception, a default fallback that hides a failed call. These are exactly the constructs that convert a loud, fast failure into a quiet, slow one. A service that crashes tells you where the problem is in ten seconds. A service that silently returns stale data takes you forty minutes and a customer complaint to find.

Cross-file function calls fell 35%, from 343 method calls per thousand changed lines to 223. New code is less woven into the existing system. That sounds like a maintainability concern rather than a reliability one, but it has a direct operational consequence: isolated code has no shared instrumentation. If a new module does not call your existing client wrapper, it does not get your existing timeouts, retries, circuit breakers or metrics either. It is invisible until it is on fire.

Long-term legacy updates fell 74%, from 1.7% of changes to 0.46%. Old code is not being retired or consolidated, just left alone. GitClear's phrase for the result is that these sections "calcify until something breaks." Every on-call engineer has met a calcified module. There are simply going to be more of them.

Four incidents worth studying

Aggregate data tells you the shape of the risk. Specific incidents tell you the mechanism. These four are all publicly documented and each demonstrates a different failure mode.

Amazon, March 2026: the memo that named the pattern

Amazon spent 2025 and 2026 pushing AI-assisted development hard internally. In March 2026 the retail site suffered a cluster of high severity incidents in a short window. What makes this case instructive is not the outage itself but the internal response: an escalation memo that explicitly grouped the incidents under "Gen-AI assisted changes" and "high blast radius," and a process change requiring extra senior review for AI-assisted production changes.

Amazon has pushed back on the simplest reading. Fortune reported the company's position that only one incident involved AI tools directly, and that the root cause there was not faulty generated code but an engineer acting on inaccurate advice an AI agent had inferred from an outdated internal wiki.

That caveat is worth taking seriously, because it points at a failure mode most teams have not thought about. The code was not wrong. The reasoning about the system was wrong, because the agent read a stale document and presented its conclusion with the same confidence it would have used for a current one. Your wiki has always been out of date. It used to be out of date in a way that a human engineer would notice, because they remembered the migration. An agent has no such memory. Stale documentation has quietly been promoted from an annoyance to an input to production changes.

Replit, July 2025: the agent that deleted the database

The canonical example, and still the most useful teaching case. In July 2025, SaaStr founder Jason Lemkin publicly documented a week of building on Replit that ended with the agent deleting his database, as covered by The Register. By Lemkin's account the tool did this despite his instruction not to change any code without permission. Screenshots he posted show Replit's own output admitting to "a catastrophic error of judgement" and to having "violated your explicit trust and instructions."

Two details from that account matter more than the deletion itself. First, Replit told Lemkin the rollback would not work, that it had destroyed all database versions. He tried anyway, and it worked. Second, he reported the agent creating a 4,000-record database populated entirely with fictional people, and concluded after repeated attempts that "there is no way to enforce a code freeze in vibe coding apps like Replit."

Replit's CEO called the experience unacceptable, and the company subsequently shipped development and production database separation, a planning-only mode, and improved one-click restore.

Notice that every one of those fixes is an environmental control, not a model improvement. Nobody tried to make the agent better at understanding the phrase "do not modify production." They took away its ability to do so. That is the correct lesson and it generalises: an agent's blast radius is a property of the permissions you gave it, not of the instructions you wrote in the prompt. Instructions are advisory. Credentials are not.

The second lesson is quieter and arguably more important. The agent's incorrect claim that recovery was impossible extended the incident. In a human incident, an engineer who says "we cannot roll this back" is making a claim you can interrogate. When an agent says it, in the same fluent register it uses for everything else, the claim carries an unearned authority. Treat agent assertions during an incident as hypotheses requiring verification, particularly assertions about what cannot be done.

Amazon Q, July 2025: the supply chain reaches the assistant

On July 13, 2025, a GitHub user submitted a pull request to the Amazon Q Developer VS Code extension repository. It was merged despite the contributor being untrusted, and it contained a malicious system prompt instructing the agent to act as a "system cleaner," deleting local files and wiping cloud resources via AWS CLI calls. Amazon published the affected version to the Marketplace on July 17. Researchers flagged it on July 23, and AWS shipped a clean build the following day. AWS has stated that formatting errors in the injected prompt prevented the wiper logic from executing and that there is no evidence of customer data loss. BleepingComputer has the timeline.

The near-miss is the point. This is a supply chain attack where the payload is not code but instructions, targeting a component that holds developer and cloud credentials by design. Your existing supply chain controls are built to scan dependencies for malicious code. A prompt embedded in a configuration file is not code, will not trip a dependency scanner, and executes with the full authority of whatever the assistant is allowed to do.

Slopsquatting: the dependency that never existed

The fourth case is a class rather than a single event. Language models routinely invent package names that sound plausible but do not exist. Published measurements vary widely by model and language: recent work on frontier models released between late 2025 and early 2026 found overall hallucination rates of roughly 4.6% to 6.1%, while broader studies across a wider model set have reported figures from under 1% to over 45%, with open-source models substantially worse than commercial ones.

The rate matters less than the persistence. Researchers who re-ran 500 prompts that had previously produced a hallucinated package name, ten times each, found that 43% of the hallucinated names came back on every single run. That reproducibility is what turns a curiosity into an attack: a name that a model reliably invents is a name an attacker can register and wait on. The term for it is slopsquatting.

For on-call, this lands as one of the nastiest incident shapes there is. The build worked yesterday. Nothing in your code changed. A package that had been silently 404ing, or resolving to an internal mirror, now resolves to something that exists and runs on install. The trigger is entirely outside your repository and outside your change log.

Where AI code actually fails

The most actionable dataset here is Veracode's 2026 GenAI Code Security Report, which evaluated over 100 models on code generation tasks across languages and vulnerability categories with no security-specific prompting. The headline is that models produce syntactically correct code close to 100% of the time, while the average security pass rate sits at 56%, essentially unchanged from the prior year. Roughly 44% of generation tasks introduced a known vulnerability.

But the average conceals the useful finding. Performance varies enormously by vulnerability class, and the variation is not random.

The pattern behind the spread

SQL injection has a canonical, local fix: use a parameterised query. It appears in the training data ten million times, always in roughly the same shape. Models handle it at 83%. Cryptography is similar, a matter of picking the right named algorithm and mode, and models manage 87%.

Cross-site scripting at 15% and log injection at 12% are different in kind. Both require knowing where a value came from, several function calls earlier, possibly in another file. Neither has a local fix, because whether output needs escaping depends entirely on whether the input was trusted, and trust is a property of the whole system rather than the line being written. A model working with a limited window of context is structurally poorly placed to answer that question, and the numbers show it.

The operational implication is precise: this is a prioritisation map, not a general warning. Reviewer attention on AI-generated code should concentrate on anything that handles untrusted input across a boundary, and can be lighter on self-contained algorithmic work. Veracode also found that model choice is a meaningful variable. The best performing model in the snapshot reached 68%, while more than half of the tested models clustered at 50% to 53%. Reasoning models averaged 56% against 51% for non-reasoning ones, but coding-specialised models did no better on security than general purpose ones. Bigger did not help either.

Why this changes on-call, not just code review

Everything above is a code quality story. Here is why it lands on the rotation.

The author is not in the room

The single most valuable resource in a serious incident has always been the person who wrote the code. Not because they are smarter, but because they hold the unwritten context: what they considered and rejected, what the edge case was, which assumption is load-bearing. When code is generated, that context was never externalised. It existed briefly inside a model's forward pass and then evaporated.

So the on-call engineer paging the author gets a different answer than they used to. Instead of "oh, that is the retry path, I made it three attempts because the upstream times out at ten seconds," they get "I accepted that suggestion, it passed review, I do not remember why it is structured that way." That is not negligence. It is an accurate description of what happened. But it removes a step from the debugging process that most incident response implicitly assumes exists.

Volume outpaces review, and review outpaces understanding

DORA's research frames this as the verification tax: the additional effort required to check that generated code is reliable, secure and architecturally coherent. Their 2026 ROI of AI-Assisted Software Development report models a J-curve, a temporary productivity dip before long-term gains, with the verification tax as one of three causes alongside the learning curve and the need to adapt downstream processes.

The report is candid about the reliability cost. Its own illustrative model assumes the change failure rate rises from 5% to 6% after AI adoption, and books that as a negative downtime impact of $344,000 in the sample calculation. DORA's framing, drawing on its 2025 research, is that AI adoption is associated with better individual effectiveness and a rise in software delivery instability at the same time. Throughput and stability, which historically moved together, are being pulled apart.

A single percentage point on change failure rate sounds tolerable until you multiply it by a deployment frequency that has also gone up. That is the whole mechanism. You are not shipping slightly worse code. You are shipping slightly worse code considerably more often, and the on-call rotation absorbs the product of those two numbers.

The incident volume is already measurable, and GitHub is the preview

If the argument so far sounds theoretical, there is one place where the AI-era incident curve is already public: GitHub's own status page. GitHub sits at the centre of agentic workflows, absorbing the pull requests, CI runs and API traffic that AI tooling generates, which makes it a leading indicator for what elevated machine-driven change volume does to a production system.

The numbers behind the bars: in 2024 GitHub logged 119 service incidents, 26 of them major, with an average resolution time of about 106 minutes, per tracking collated by LeadDev. Between May 2025 and April 2026, IncidentHub tracked 257 incidents, 48 of them major, with average time to restore for the period at over six hours. February 2026, with 37 incidents, was the worst month on record, and the report notes major outage frequency climbing steadily from December 2025, which is exactly when GitHub's CTO says agentic development workflows "accelerated sharply." GitHub planned for 10x capacity in October 2025 and concluded by February 2026 that it needed to design for 30x.

The causal chain is stated by GitHub itself, not inferred: repository creation, pull request activity, API usage and automation all growing quickly, driven by a change in how software is built. One platform's status page is not proof that your incident count will follow the same curve. But GitHub is what a system looks like when machine-speed change volume arrives before the capacity, the load shedding and the review practices designed for it. Most engineering organisations are earlier on that same curve, not on a different one.

Detection gets slower before it gets faster

There is a quieter effect that shows up in mean time to detect rather than in change failure rate, and it comes directly from two of the GitClear signals.

Alerting coverage is not automatic. It is a consequence of new code passing through instrumented paths: your shared HTTP client, your database wrapper, your standard error handler. Those are precisely the shared structures that cross-file connectivity measures, and that measure is down 35%. Code that reimplements a call inline rather than routing through the house wrapper inherits none of the timeouts, none of the retry policy, and none of the metrics. It is not that someone forgot to add monitoring. It is that monitoring used to arrive for free with reuse, and reuse is declining.

Layer the 47% rise in error-masking constructs on top and the two compound unpleasantly. The first means a new code path may not emit signals. The second means that when it fails, it may not emit an error either. The combination produces the incident shape every on-call engineer dreads: no alert fires, dashboards stay green, and the first notification is a customer describing symptoms you cannot reproduce.

The mitigation is not more dashboards. It is treating instrumentation as a structural review criterion for generated code. If a new module makes an outbound call, the question in review is not "does this work" but "does this go through the wrapper," because that single question determines whether the module is observable at all.

Incidents get harder to classify

Postmortems depend on a clean causal story. AI-assisted changes blur it in a way that is genuinely difficult rather than merely inconvenient. Was the cause the generated code, the reviewer who approved it, the prompt, the stale wiki the agent read, or the absence of a test that would have caught it? Amazon's own position on its March incidents illustrates the problem: the company distinguishes between faulty AI-generated code and an engineer acting on inaccurate AI-inferred advice. That is a real distinction with different remediations, and most incident templates have no field for it.

Teams that do not resolve this tend to fail in one of two directions. Either every incident gets blamed on AI, which is unfalsifiable and stops the investigation early, or AI provenance is never recorded at all, which means you can never measure whether your controls are working.

What to actually change

The useful moves are mostly about provenance, blast radius and where you spend review attention. None require slowing down adoption.

• Record AI provenance on every change. A commit trailer or PR field capturing whether a change was AI-assisted, and at what level (autocomplete, generated block, agent-authored). Without this you cannot correlate anything, and correlation is the whole point. It also lets you route review automatically.
• Add an AI provenance field to your incident template. Three values are enough: AI-generated code, AI-influenced decision, or neither. Amazon's distinction between faulty code and inaccurate agent advice is the one to encode. Review the distribution quarterly rather than arguing about it per incident.
• Route review by failure class, not by diff size. The Veracode spread is a review policy waiting to be written. Anything touching untrusted input, output encoding, logging of user-supplied values, or authorisation gets human eyes regardless of how clean it looks. Self-contained algorithmic code with good test coverage can go lighter.
• Give agents their own credentials, scoped down. The Replit fix list was entirely environmental. An agent should never hold a credential that can reach production data, and it should be a distinct identity so that its actions are separable in an audit log. If you cannot tell from your logs which changes an agent made, you cannot investigate an incident it caused.
• Put a tripwire on error-masking. The 47% rise in error-masking constructs is the most directly on-call-relevant number in the GitClear data. A lint rule that flags empty catch blocks and swallowed exceptions in new code costs nothing and prevents the specific failure mode where a loud error becomes a silent one.
• Treat generated dependencies as untrusted until verified. Given documented hallucination rates and the 43% reproducibility of hallucinated names, a build step that checks every new dependency against a known-good allowlist, plus a soak period before adopting new versions, is proportionate.
• Verify agent claims during incidents. Especially claims about what is impossible. The Replit case extended an outage because a confident assertion about unrecoverable data went unchallenged.

The on-call surface this leaves you with

Put the pieces together and the shape of the problem is clear. More changes are landing, from more sources, with less context attached to each one, and a meaningful share of them carry defects that concentrate in exactly the categories that are hardest to spot in review. Meanwhile the reuse structures that made codebases navigable during an incident, shared helpers, cross-file calls, maintained legacy modules, are all thinning out.

None of that is an argument against AI-assisted development. The productivity data is real, and DORA's position that AI amplifies both the strengths of good engineering organisations and the dysfunctions of struggling ones is the honest reading. But amplification cuts in a specific direction for on-call: the teams whose incident response was already loose will find it looser, faster.

What holds up under that pressure is unglamorous. Clear ownership, so the page reaches someone who can act. Fast escalation, so the person who does not know the answer can find the person who does without a lookup in three tools. Overrides and handoffs that take seconds, because the volume of incidents is going up and shift boundaries will get crossed more often. And an incident record that assembles itself, because reconstructing causality across generated code, human review and agent advice is hard enough without also reconstructing the timeline.

That is the case for running on-call where the incident conversation already happens, rather than across four tools that each hold a fragment of it.

Where Pagerly fits

We build Pagerly, so treat this section as interested rather than neutral. It is here because the problems above map onto specific coordination failures, and it is worth being concrete about which ones tooling actually addresses and which it does not.

The rota has to be correct without anyone maintaining it

If incident volume rises while shift length stays the same, more incidents cross shift boundaries and more pages arrive for someone who was not there when the change shipped. Pagerly builds round-robin or custom rotations natively, with daily, weekly or custom interval shifts, and handles overrides, swaps and holidays as a message rather than a login. Slack user groups such as @oncall update automatically as the rota turns, so the person looking for help does not have to work out who is actually holding the pager this week. Schedules already living in Opsgenie or Jira Service Management can be synced rather than rebuilt.

Escalation has to reach a decision-maker, fast

The Replit case turned on an unchallenged claim, and Amazon's response turned on getting senior review into the path of AI-assisted changes. Both are escalation problems. Pagerly pages across Slack, Teams, email, SMS, phone call and mobile app, so an escalation policy ends at a person rather than at an inbox. Because the escalation happens in the thread where the question was asked, the answer lands in the incident record automatically instead of in a direct message nobody can find afterwards.

The incident record has to assemble itself

This is the one that matters most for AI-generated code. When the author cannot reconstruct why the code is shaped the way it is, the response transcript becomes the primary evidence, and rebuilding it three days later from scrollback is exactly when detail gets lost. Pagerly runs incidents as Slack channels with commanders and running timelines, so what was observed, what was decided and by whom is captured as the conversation happens. Action items come out of that same channel rather than a separate tracker, and the AI SRE agent helps debug, document and communicate during the incident rather than after it.

You need to see the failures you did not cause

A meaningful share of AI-era incidents originate outside your repository: a hallucinated dependency that suddenly resolves, an upstream compromise, a vendor degradation. Pagerly monitors more than 3,000 third-party services alongside uptime checks on your own endpoints, and status pages give customers something trustworthy while an investigation is still open, which is precisely the situation where teams otherwise go quiet.

And you need to measure whether any of it is working

The provenance field suggested earlier is only useful if somebody reviews the distribution. Incident statistics and alert noise analysis are what turn "we think AI-assisted changes cause more incidents" into a number you can act on, which is the difference between a policy and an argument.

What tooling does not do is decide your severity model, write down containment authority, or route review by failure class. Those are organisational choices no product makes for you. But once those decisions exist, whether they get followed usually comes down to whether following them means opening another tab at 3am. Pagerly is free to add to Slack if you want to test that against your own rotation.

The takeaway

The 2026 evidence on AI-generated code incidents is more specific than the discourse around it. AI writes something like 42% to 50% of committed code, 96% of developers do not fully trust it, and fewer than half always verify it. Across 623 million analysed changes, duplication is up 81%, error-masking is up 47%, and refactoring has collapsed to a fifth of its pre-AI rate. Models produce compilable code essentially every time and secure code 56% of the time, failing worst precisely where a flaw depends on tracing untrusted input across a system. And the largest engineering organisations are now writing "Gen-AI assisted changes" into internal escalation memos.

None of that says stop. It says the controls have to move from the model to the environment: scoped credentials, recorded provenance, review routed by failure class, tripwires on the constructs that turn loud failures into quiet ones, and an incident process that can tell the difference between bad generated code and a good engineer acting on bad generated advice. Those are all things you can build this quarter. The volume of AI-authored code arriving in your production systems is not waiting for you to finish.