Nobody's going to write a CVE for this new risk. There's no exploit chain to describe and no supply-chain diagram with a red arrow pointing at the compromised dependency.

That’s because the biggest threat these days isn't in the code. It's in the behavior. Developers are increasingly shipping unverified or underverified AI-generated code.

And the problem isn’t just that developers are trusting AI more, though many are. The problem is becoming structural. As autonomous agents are given increasingly large tasks, teams are drowning under diffs so large that they’re impossible for developers to read and fully understand. 

Take Bun’s recent migration from Zig to Rust. An autonomous agent produced a million lines of code in under two weeks. It’s impossible for a human to review that much code in the same time period. Unsurprisingly, at least nineteen regressions surfaced after merge, including critical ones that crashed the program. 

Because verification has become either overwhelming or impossible, some teams are skipping it or doing it with less rigor. Review gets lighter. Tests aren’t created on new product surfaces or get flaky and don’t get maintained. The gap between how much teams trust the output and how much we check it is widening and that gap is where software breaks.

Perhaps the most interesting thing about this move towards less verification is that people are sharing publicly that they’re verifying less. Scroll developer Twitter and you'll find engineers like Peter Steinberger, the creator of OpenClaw, making the case, for example, that PR reviews are dead and that reading a diff is a waste of time since what matters is what’s in the prompt. The solution, he says, is the prompt review. Get the prompt right and you don’t need to read the code.

But here's what that position is: a bet that the model got it right, placed at a scale no human is checking.

This article is about how that bet is becoming more common and what the growing pile of AI-caused incidents already tells us about how that bet plays out.

AI;DR: How the shift happened

A year or so ago, you asked for a helper, you got twenty lines. That's not what a prompt returns anymore. Now, it returns a feature, a migration, or a refactor that touches forty files and rewrites logic. 

Reviewing 10,000 lines of code isn't review — it's skimming. You approve it because it looks likely to work, not because you’ve comprehensively verified the whole thing. No one has the time (or attention span) to do anything more than that. 

The numbers coming out of the teams doing this at scale make it concrete. Airbnb migrated close to 3,500 test files in six weeks, work they'd estimated at a year and a half by hand. These are hints at what’s to come and every dev with an agent is on the same road at a smaller scale, generating diffs bigger than anything they would have written by hand in the same time. 

The problem is that verification layers were built for human-sized diffs. For example, code reviews assume a person wrote the change, at human speed, in a size another person can hold in their head. That’s often not possible anymore. 

If review can't scale, the answer is supposed to be E2E test coverage that verifies the thing actually works, no human reading required. But E2E tests have traditionally taken significant time to scope, time to write, and more time to maintain as the app changes. That was a manageable tax when features shipped at human speed but AI now generates code too quickly. 

Creating tests with the help of a coding agent seems like the obvious answer. However, Reddit and other forums are full of developers who are struggling with that strategy.

The issue is that AI coding agents weren’t designed to write E2E tests so they often generate tests that mirror the implementation too closely so they break too often or that can’t test the business logic of the app. That’s led to developers reporting meaningful decreases in coverage. 

So, one way or another in AI-driven development, test coverage tends to fall behind the same way review does and teams have to often decide between shipping without tests, shipping with inadequate tests, or blocking code from merging. Teams are increasingly choosing the first two. 

Why it accelerated

A hot take travels faster when it’s extreme. "PR review is dead, only the prompt matters," is provocative. It gets quote-tweeted and becomes part of the broader conversation.

But the fact that it was received so well suggests that there are an increasing number of working engineers who simply deeply trust coding agents and their ability to prompt it. 

But it's also faith in AI that the evidence doesn't support.

• The 2025 DORA report found that AI adoption translated into a 10% increase in code instability. 
• A 2026 report by Lightrun that found that 45% of AI generated code changes require debugging in production environments. 
• Veracode found that AI-generated code introduced critical security vulnerabilities in 45% of cases across more than 100 models and 80 coding tasks. That 45% rate held roughly stable across GPT-4, GPT-5, Claude, and Gemini generations. 

Put those together and it’s clear coding agents aren’t trustworthy senior engineers. They’re fast juniors who ship a lot, reach for the insecure pattern about half the time, and don't get more careful over time. That's what’s being handed the keys to unread merges.

To be fair, while Peter Steinberger is skipping code reviews, he’s not skipping end-to-end testing, which he sees as more important in the agentic era. His approach to end-to-end testing centers on giving autonomous AI coding agents their own isolated environments, Docker setups and real execution paths to verify features.

The problem is that OpenClaw is still obviously under testing since it routinely ships vulnerabilities, security incidents, and more to main. By April 2026, SecurityScorecard reported 42,900 exposed OpenClaw instances with 15,200 of them RCE-vulnerable. By May, over 200 CVEs had been published about OpenClaw. 

While Steinberger got it right that the inability to manually review agent output means that E2E testing becomes more important, he didn’t go far enough in comprehensively automating verification with tests. Even with his sophisticated setup, he can’t overcome the drawbacks of E2E testing with computer use agents. 

Where it ends

At the scale AI is shipping code, the math isn't on AI’s side: change enough code and the probability of a break somewhere increases dramatically. Indeed, the incidents are piling up.

Cortex AI released a report in 2025 claiming that incidents per pull request increased by 23.5% which isn’t surprising to teams that have dealt with their own AI-generated incidents or been affected by mass outages by their suppliers. 

The bugs in AI incidents are rarely exotic: a directory that didn't exist, a route pointing at nothing, a destructive command that should have required a gate. These are not clever, adversarial, once-in-a-decade failures. They're the boring, mechanical mistakes that verification catches as a matter of routine. None of these incidents happened because the mistake was too sophisticated to detect. The failure was the absence of sufficient verification.

So, what does the future look like? Outputs are not getting smaller. Agents are instead writing more code in bigger batches. Review is not getting more possible — every gain in generation makes the human read less feasible, not more. If other forms of verification don't move to fill the gap that review left open, nothing catches these before production. 

What looks today like a string of embarrassing one-off incidents is the leading indicator of the future steady state.

The course correction

You didn't trust humans to ship code without having a secondary QA function. Why would you trust agents to ship code without a separate and independent QA function? 

The fix is not what the loudest voices are selling and it's not what the traditionalists want either. Manual, line-by-line human review still works for smaller PRs but it’s not the answer for the kind of massive PRs autonomous agents create. Nobody is going to hand-audit a 340-file diff and pretending otherwise doesn’t help. 

The answer is that verification has to scale the way generation did: automated, continuous, and aimed at the layer where these failures actually happen. Teams need to recommit to testing end-to-end, every change, at machine speed. The routing that pointed at nothing, the folder that didn't exist, the DROP that should have hit a gate: those get caught by running the thing and watching what breaks.

Which makes automated agentic E2E coverage the verification layer that has to exist for any of this to be safe. The teams doing agent-sized work without it are only moving faster until they hit an (inevitable) incident.

Getting your coding agent to do it isn’t the solution either, as Reddit commenters and those writing the CVEs about OpenClaw can attest. Coding agents are not created or trained for the complex requirements of generating comprehensive and useful e2e tests. That’s why we created our purpose-built, agentic E2E testing platform using learnings from more than 100 million test runs for teams like Figma, DoorDash, Rippling, and Cursor. Over 100+ agents that understand QA far better than your coding agent map your app, write the tests, maintain them, and run them in parallel on every change. 

With a purpose-built AI testing platform, verification scales at the same rate the code does – without the gaps and testing mistakes coding agents routinely make. 

The agents aren't slowing down or shipping smaller PRs. That’s why more needs to be done to make sure verification keeps up. 

‍