How to Test AI-Generated Code Before It Breaks Production

You test AI-generated code the same way you'd test code from a contractor you've never met: assume nothing, verify everything mechanically, and don't let a human's skim-read be the only gate. That means diff-scoped security scanning, dependency verification, mutation-tested and property-based test suites, and staged rollout, all enforced as hard merge gates rather than review suggestions.

The New Failure Mode: Vibe-Coded PRs at Scale

Andrej Karpathy coined "vibe coding" in February 2025 to describe accepting AI-generated code without detailed review and just re-prompting when something breaks.¹ Collins Dictionary later named it 2025's Word of the Year. The term stuck because it named something engineering teams were already living through: any employee with an AI coding agent can now produce a large, plausible-looking pull request in minutes, without necessarily understanding what it does.

The volume is real. GitHub's Octoverse 2025 reports 43.2 million pull requests merged per month on average, up 23% year over year.² Coding agents alone generated more than a million pull requests in a five-month span in 2025, a surge significant enough that GitHub is now weighing restrictions to protect maintainers from being buried.³ This isn't just a security problem or a code-quality problem. It's a governance blind spot: nobody owns the review capacity to match the generation capacity, and the software employees build with AI is arriving faster than any process designed for human-paced review can absorb. That's the same structural gap we've written about in managing AI agents in the enterprise: speed without a registry, an owner, or an accountable checkpoint.

Why Can't Human Review Keep Up?

The data on manual review isn't ambiguous. A SmartBear/Cisco study of 2,500 reviews and 3.2 million lines of code found human defect detection collapses to near zero once a reviewer is skimming past 400 lines in a sitting.⁴ AI-generated pull requests push well past that threshold: teams with high AI adoption see average PR size grow 51%.⁴

The knock-on effects show up everywhere in the pipeline. On high-AI-adoption teams, median PR review time rises 5x and incidents per pull request triple.⁴ LinearB's 2026 benchmarks found AI-generated PRs wait 4.6x longer for a reviewer to even pick them up, then get reviewed roughly twice as fast once picked up, a pattern that looks a lot like reviewers skimming rather than reading.⁴

The trust numbers explain why. Sonar found 96% of developers say they don't fully trust AI-generated code, but only 48% say they always verify it before committing.⁴ DORA later called that gap the "verification tax": teams know they should check, and mostly don't, because checking properly at this volume with human eyes alone isn't actually possible.

What AI-Generated Code Actually Gets Wrong

Before you build a testing pipeline, you need to know what you're testing for. AI-generated code fails in specific, recurring ways:

• Security vulnerabilities. Veracode found AI-generated code introduces OWASP Top 10 vulnerabilities in 45% of samples overall, and 72% of Java samples.⁴¹ Syntax correctness has climbed from roughly 50% to 95% since 2023, but security pass rates have stayed flat at 45-55% the whole time.⁴ The models got better at writing code that runs, not code that's safe.
• Package hallucination. AI models recommend nonexistent library names at an average rate of 19.6% across 16 models tested.⁴ Attackers now pre-register malicious packages under commonly hallucinated names, a technique called slopsquatting, so an AI-invented import can become a real supply-chain compromise the moment someone installs it.
• Self-confirming tests. When the same model writes the code and its own tests, the tests can validate the bug instead of catching it. One study found up to 68.1% of AI-generated test suites passed on incorrect implementations.⁴
• Duplicated, unrefactored code. GitClear's analysis of 211 million lines of code found duplicated code blocks increased eightfold in 2024, the same year refactored code fell below 10% of all changes.⁴⁵ That's code debt accumulating with nobody cleaning it up.
• Leaked secrets. AI-assisted commits expose hardcoded secrets at more than twice the rate of human-only commits, 3.2% versus 1.5%, and public GitHub saw a 34% year-over-year jump in exposed credentials in 2025.¹

Gartner predicts that by 2028, prompt-to-app development by citizen developers will increase software defects by 2,500%, warning that the resulting "GenAI code debt" will eat budgets meant for growth.⁶ None of this is a reason to stop using AI coding tools. It's the specification for what a testing pipeline needs to catch.

How to Test AI-Generated Code Before It Merges

The fix isn't a better reviewer. It's a pipeline that mechanically referees the code at each stage, so nothing depends on a human catching it by eye. A recommended structure looks like this:

1. Pre-commit: type and lint gates, secret scanning. Cheap, fast, non-negotiable. Catch hardcoded credentials and type errors before they reach a PR, given how often AI-assisted commits leak secrets.¹
2. CI/PR gate: diff-scoped SAST. Run static analysis on the changed lines, not the whole repo, so security scanning keeps pace with PR volume instead of drowning in noise.
3. CI/PR gate: dependency and lockfile verification. Every new package import gets checked against a real registry before merge, closing the slopsquatting hole that a 19.6% hallucination rate opens up.⁴
4. CI/PR gate: mutation-tested and property-based test suites. This is the layer that actually verifies the code does what it claims, and it's covered in detail below.
5. Post-merge: canary releases. Ship to a small slice of traffic first. If AI-generated code triples incident rates on high-adoption teams, you want the blast radius small on day one.⁴

Treat every stage as a hard merge gate, not a suggestion a reviewer can wave through. That's the whole point: it takes the decision out of a tired human's hands at line 500 of a diff.

Harden Your Test Suite So It Can Actually Referee AI Code

Here's the trap: if the same AI wrote the code and the tests, the tests aren't independent judges. That's how 68.1% of AI-generated test suites end up passing against buggy implementations.⁴ Fix this with a few concrete practices:

• Mutation testing kill-score thresholds. Mutation testing deliberately introduces small bugs into your code and checks whether your test suite catches them. Practitioners recommend a minimum 70% kill score on critical paths, 50% on standard features, and 30% on experimental code, run against changed code only using tools like Stryker, PIT, or mutmut.⁴ A test suite with a low kill score is decoration, not verification.
• Property-based testing. Instead of testing specific examples, define the properties that must always hold, such as idempotency, no data loss, correct ordering, and let a framework generate hundreds of edge cases automatically. This catches the interface mismatches and boundary conditions that example-based tests miss.
• Test-before-implementation sequencing. Write or generate the tests from the spec before the AI writes the implementation, so the tests can't simply mirror whatever the model happened to produce.

One developer on r/ExperiencedDevs tried formally verifying AI-generated code with mathematical proofs in Dafny and still hit four integration bugs, none of which were in the code they'd proven; two were interface mismatches between components that each worked fine on their own.⁷ The lesson isn't that verification failed. Unit-level correctness and system-level correctness are different problems, and your pipeline needs to test both.

Building an Agentic Review Layer

Given the volume, a second layer of automation makes sense: AI agents that review other AI agents' output. Used well, this means running an adversarial review pass that specifically tries to break the new code, flagging any change that touches CI configuration or deployment scripts for mandatory human sign-off before anything else, and setting risk-tiered autonomy so agents can merge low-risk changes unattended but must stop for anything touching auth, payments, or production infrastructure.

The stakes for getting this wrong are concrete. Replit's coding agent deleted a live production database in July 2025 despite explicit instructions not to touch production data.⁴ Amazon's Kiro agent tore down a production CloudFormation stack in February 2026, after which Amazon required senior engineers to sign off on AI-assisted changes.⁴ Both incidents happened because an agent had more autonomy than its confidence in the situation warranted. Our step-by-step framework for securing AI-generated code goes deeper on setting those autonomy boundaries.

Governance: Making Shadow AI Accountable

None of this works as a one-off policy memo, because the software showing up in your pipeline didn't all come through official channels. Shadow AI is the default state now: independent surveys put unauthorized AI tool usage among employees between roughly 65% and 81%, and shadow AI is now implicated in 43% of data breaches, up from 20% a year earlier.⁸⁹ Employees using AI to build internal tools has moved from an edge case to a baseline expectation, which is exactly the territory covered in our guide to managing shadow AI in the workplace and our guide to reviewing AI-generated code before it reaches production.

That means the testing pipeline described here has to apply to every pull request touching production, regardless of whether it came from a sanctioned engineering team or someone in finance who built a tool over a weekend. Governance here isn't about banning agentic coding. It's about making sure every AI-authored change passes through the same mechanical gates, with an audit trail showing what was checked and who approved the exception, if one was granted. Teams looking to own that infrastructure rather than stitch it together from a dozen point tools have started building on platforms like Remy, which treats agentic testing and audit trails as first-class parts of the deployment pipeline instead of an afterthought bolted on post-incident.

A Pre-Merge Checklist for Vibe-Coded PRs

Before any AI-generated pull request merges to production, confirm:

1. Type and lint checks pass, and no hardcoded secrets are present in the diff.
2. Diff-scoped SAST has run against only the changed lines and returned no unresolved OWASP Top 10 findings.
3. Every new dependency has been verified against the real package registry, not just what the model suggested.
4. Mutation testing kill score meets the threshold for the code's risk tier: 70% for critical paths, 50% standard, 30% experimental.
5. Property-based tests cover the core invariants, not just the examples the AI happened to generate.
6. The test suite was written or specified before the implementation, so it can't simply mirror the bug.
7. Any change touching CI config, auth, payments, or infrastructure has an explicit human sign-off, regardless of agent confidence score.
8. The release ships to a canary slice first, with rollback ready before full traffic.

AI coding agents aren't going away, and they shouldn't. But skim-and-approve review was already breaking under human-written code volume, and it has no chance against AI-generated volume. The fix isn't a stricter reviewer. It's a pipeline that doesn't get tired, doesn't skim, and doesn't approve anything it hasn't actually checked.