Most of the conversation about AI and secure coding focuses on what happens when a flawed suggestion gets reviewed and missed. There's a quieter, arguably bigger problem sitting upstream of that: code that never gets reviewed at all. Faros AI's 2026 telemetry analysis of 22,000 developers across more than 4,000 teams found that pull requests merged without any human or automated review are up 31.3% as AI adoption has climbed. That's not a study of developer sentiment. It's measured behavior, and it points to a different failure mode than "AI wrote something wrong." It's "nobody looked."
-
The Self-Reported Gap Matches the Measured One
Sonar's 2026 State of Code Developer Survey asked developers directly whether they trust AI-generated code and whether they review it before committing. The answers, read together, describe a broken quality gate: 96% say they don't fully trust AI-generated code, yet only 48% say they always verify it before committing. Distrust is nearly universal. Consistent review is close to a coin flip.
What makes this pairing worse than either number alone is that it isn't just self-reported anxiety. Faros's instrumented telemetry shows the behavior actually happening at scale, not just developers admitting to a bad habit in a survey. Self-reported distrust and measured unreviewed merges don't need to be perfectly precise to point to the same conclusion: review is failing as a quality gate at current AI coding volumes, and the failure looks structural rather than incidental.
-
"Vibe Merging" Is a New Failure Mode, Not Just Laziness
Code Review Bench research covering 2026 review patterns has given this behavior a specific name: vibe merging. A large AI-generated diff looks plausible and syntactically clean; the reviewer skims it, sees nothing obviously wrong, and approves. It's a distinct failure mode from a careless reviewer, because the code genuinely looks fine on a skim. AI-generated output tends to be syntactically correct and superficially well-formatted, which is exactly the kind of code human reviewers are least equipped to scrutinize quickly, since the usual visual tells of sloppy code inconsistent formatting, obvious typos, awkward structure are largely absent.
The volume problem compounds this. As the queue of AI-generated changes grows faster than review capacity, reviewers face real pressure to approve faster just to keep the backlog manageable. Reported PR review times are up sharply industry-wide even as approval thoroughness trends in the opposite direction: more time spent reviewing, less actually being caught.
-
The Research Backs the Pattern, Not Just the Anecdote
This isn't only an industry-blog observation. Three separate 2026 studies from Carnegie Mellon, Stanford, and an independent open-source analysis converged on the same finding: AI-generated pull requests receive less scrutiny, faster merges, and less discussion than human-written code, despite arguably needing more review given their documented error patterns. Raw code quality in these studies hadn't necessarily dropped in absolute terms; the more precise finding is that review discipline itself is eroding as AI-driven volume rises, which is a distinct and arguably more dangerous problem than any single bad suggestion.
A related academic study from Carnegie Mellon and the University of Lisbon examined the specific characteristics of auto-merged, agent-authored pull requests directly. It found that repositories tend to be bimodal about this: they either auto-merge nearly all agentic PRs or almost none, with more mature, established repositories leaning toward requiring review rather than defaulting to auto-merge. That's a meaningful signal: the organizations with the most experience managing code quality are the ones pulling back from unreviewed auto-merging, not embracing it further.
-
Why Review Capacity Can't Just Scale to Match
It's tempting to assume the fix is simply "review more": add reviewers, allocate more time. The data suggests this doesn't scale cleanly. Harness's 2026 State of Engineering Excellence Report, surveying 700 engineering practitioners, found 81% of developers now spend more time in code review since adopting AI tools, with PRs sitting in review 4.6 times longer than before, even though the same AI tools cut time-to-open-a-PR by roughly 58%. The bottleneck didn't disappear; it moved. Teams that respond to that bottleneck by tightening review get buried in a growing backlog. Teams that respond by loosening review get more vibe merging and more unreviewed auto-merges. Both are versions of the same underlying capacity mismatch, and neither is a stable long-term state.
-
Why This Risk Is Different From "AI Writes Flawed Code"
Every other risk in the AI-and-secure-coding conversation hallucinated dependencies, subtle logic errors, missing defensive programming assumes a human eventually looks at the output and has a chance to catch it, even if they sometimes don't. Code that's merged with zero review removes that chance entirely. It's the difference between a smoke detector with dead batteries and no smoke detector installed at all. Both fail, but one of them never had a shot at working in the first place.
This is also why "better developer discipline" isn't a realistic fix on its own. The pattern shows up in instrumented telemetry across thousands of developers, not a handful of undisciplined outliers, which points toward the review process itself needing structural change, not a reminder email asking people to review more carefully.
-
What Actually Helps
-
Route by risk, not by default. Not every PR needs the same review depth. Changes touching authentication, data handling, or payment logic should never be eligible for auto-merge, regardless of how small or agent-authored they are.
-
Cap diff size for AI-generated changes specifically. Smaller diffs are measurably easier to review thoroughly, and the research on auto-merged PRs found they tend to be smaller and more narrowly scoped in the first place; that pattern can be enforced rather than left to chance.
-
Build in a mandatory automated floor, even for changes that skip human review. A required security and dependency scan that blocks merge closes at least part of the gap for the PRs that would otherwise get zero scrutiny of any kind.
-
Track unreviewed-merge rate as its own metric. Most engineering dashboards track velocity and defect rate; few explicitly track what percentage of merged code had zero review. Making that number visible is often what gets it addressed.
Practicing the Judgment That Catches This
Fixing the process helps, but the underlying skill still matters: reviewers need to be able to catch a plausible-looking but flawed AI diff quickly enough to keep pace with volume, which is a specific, practiced skill rather than a general one. Simulations Labs' security team upskilling programs build exactly this kind of calibration through hands-on Web Security scenarios where the flaw isn't announced in advance, closer to what a real, unreviewed-by-default AI pull request actually looks like than a textbook example ever is.
Want to see if your team can catch what a quick skim would miss? Explore Simulations Labs' security team upskilling model and put your review process to a real test.
-
FAQ
What does "vibe merging" mean? It's a term describing the pattern where a reviewer skims a large, syntactically clean AI-generated pull request, sees nothing obviously wrong on a quick pass, and approves it without deep scrutiny distinct from careless review, since the code genuinely looks fine at a glance.
How common is it for AI-generated code to be merged with no review at all? Telemetry from Faros AI covering 22,000 developers found that pull requests merged without any review, human or automated, are up 31.3% as AI adoption has increased. This is measured behavior, not a self-reported estimate.
Why can't teams just add more reviewers to fix this? Research from Harness found that even as AI tools cut time-to-open-a-PR by about 58%, review time per PR increased 4.6-fold, and 81% of developers report spending more time in review overall. The bottleneck moves rather than disappears when review capacity increases, since AI-driven code volume tends to grow to fill it.
Is unreviewed AI code worse than AI code that gets reviewed but missed? In a meaningful sense, yes. Reviewed-but-missed code at least had a chance of being caught. Code merged with zero review had no chance at all; it's a complete absence of the quality gate rather than a gate that failed to catch something.
Do more mature engineering organizations handle this differently? Academic research examining auto-merged, agent-authored pull requests found that more established repositories tend to require review rather than default to auto-merging agentic changes, while newer or less mature repositories are more likely to auto-merge, broadly suggesting experience with code quality issues correlates with more caution here, not less.
