Testing AI-generated code: a QA playbook

Testing AI-generated code means treating it as an untrusted contribution: review it as if it came from an unknown outside contributor, security-test it against the failure modes the data says LLMs repeat (45% of AI-generated samples introduce OWASP Top 10 vulnerabilities), watch for regressions driven by churn and duplication, and capture reproduction evidence automatically so defects that slip through are cheap to fix. This playbook turns that into concrete practice.

Why AI code needs its own playbook

Not because AI code is exotic — because its failure distribution is different from human code, and most QA processes are tuned for the human distribution.

The evidence, briefly. Veracode's 2025 GenAI Code Security Report tested output from more than 100 large language models across 80+ coding tasks and found 45% of generated samples failed security tests, introducing OWASP Top 10 vulnerabilities — and that while newer models wrote more functional code, they were no better at writing secure code (Veracode). CodeRabbit's analysis of 470 real open-source pull requests found AI-coauthored PRs carry about 1.7x more issues than human ones, with logic and correctness problems up 75% (CodeRabbit).

Human failure modes cluster around fatigue and shortcuts. AI failure modes cluster around confident plausibility: code that reads clean, compiles, handles the happy path, and is wrong in a way nobody typed deliberately. Your playbook has to assume the code looks right.

Step 1: review discipline

Treat every AI-assisted diff like a pull request from an outside contributor you've never worked with. That framing does most of the work. Concretely:

• Label AI-heavy changes. You can't apply differential scrutiny to changes you can't identify. A PR label or commit trailer is enough.
• Review for intent, not just correctness. The classic AI bug is code that does something correctly — just not the thing the ticket asked for. Read the requirement, then the diff.
• Distrust your own confidence. In Stanford's controlled study, participants using an AI assistant wrote measurably less secure code and were more likely to believe their code was secure (Perry et al., ACM CCS 2023). The overconfidence applies to reviewers too.
• Budget real time. In Stack Overflow's 2025 survey, 45% of developers named time-consuming debugging of AI-generated code as a top frustration, and 46% said they don't trust AI output accuracy (Stack Overflow). If review time isn't scheduled, it gets skipped — that's how the distrusted code ships anyway.

Step 2: security checks aimed at what LLMs actually get wrong

Generic "run a scanner" advice wastes effort. The Veracode data is specific about where models fail, so aim there:

• Cross-site scripting first. Models failed to defend against XSS (CWE-80) in 86% of relevant code samples — the worst category in the study (Veracode). The root cause is structural: an LLM can't reliably know which variables hold untrusted data without context it doesn't have. Any AI-written code that renders user input goes through output-encoding review, no exceptions.
• Injection and log-forging next, for the same untrusted-data reason.
• Auth and secrets by hand. Password handling and insecure object references were among the categories where CodeRabbit found AI code 1.5–2x worse than human code (CodeRabbit). Grep AI-assisted diffs for hardcoded credentials, disabled TLS checks, and permissive CORS.
• Keep SAST in CI — deterministic scanners catch exactly the repetitive flaw patterns models reproduce, and unlike reviewers they don't get tired on PR forty.

The full report is worth reading in the original (Veracode 2025 GenAI Code Security Report, PDF).

Step 3: manage regression risk from churn and duplication

GitClear's analysis of 211 million changed lines found duplicated code blocks rose roughly eightfold during 2024, with copy-pasted lines exceeding refactored lines for the first time in the dataset (GitClear). Duplication is a regression machine: a bug fixed in one copy survives in the others, and tests written against one copy say nothing about its siblings.

Practical countermeasures:

• Track churn as a QA signal. Code revised within two weeks of landing was wrong the first time. Rising churn in a module means rising regression risk — test accordingly.
• Run duplication detection on AI-assisted PRs and make "extract instead of paste" a review norm. Models paste by default; they refactor only when asked.
• Prioritize regression passes by change volume, not by feature age. In an AI-heavy codebase, the "stable" module that got a 400-line AI refactor yesterday is the risk, not the legacy code nobody touched.

Step 4: capture repro evidence like it's free

More code plus higher defect density means more bugs will reach staging and production. The teams that cope aren't the ones that find zero bugs — they're the ones for whom each found bug is cheap to fix. The single biggest cost driver is reproduction: a report that says "search is broken" costs an engineer a round-trip; a report that arrives with evidence costs minutes.

Every bug report on AI-generated code should automatically include:

• Console logs — AI frontend code tends to fail loudly in the console long before the symptom a user notices.
• Network requests and responses — most "it doesn't work" reports resolve to a specific failing call with a specific payload.
• A screenshot or session replay of the actual state.
• Environment metadata — browser, OS, viewport, URL.

If capturing that context requires effort, people won't do it, and you'll pay in round-trips. The mechanics of making it automatic are covered on our vibe coding QA page.

Step 5: accessibility spot-checks

AI-generated UI code fails accessibility quietly: divs with click handlers instead of buttons, missing labels, icon buttons with no accessible name, focus traps in generated modals. Models reproduce the average markup of their training data, and the average is bad — WebAIM's annual analysis of the top million home pages finds detectable WCAG failures on roughly 95% of them (The WebAIM Million).

Make a scan part of the definition of done for AI-assisted UI work: automated checks catch contrast, labels, alt text, and structure reliably, and a keyboard-only pass through new flows catches most of the rest. You can baseline a page in minutes with our free WCAG audit tool — and if you're tempted to solve this layer with an overlay widget instead, read why accessibility overlays don't protect you first.

The playbook on one page

1. Label AI-assisted changes; review them as untrusted contributions, for intent.
2. Security-test against known LLM failure modes — XSS and injection first; SAST in CI.
3. Monitor churn and duplication; point regression testing at high-change areas.
4. Capture console, network, screenshot, and environment automatically with every bug report.
5. Run accessibility scans and a keyboard pass on AI-generated UI before merge.

None of this is exotic. It's ordinary QA discipline, re-aimed at a new failure distribution and run at a higher cadence — because the code now arrives at a higher cadence.

Steps 4 and 5 are where BugPort fits, honestly stated: our extension and widget capture the console, network, screenshot, and environment evidence with each report and file it into Linear or GitHub, and our scanning engine runs the WCAG checks against your real pages. The review and security discipline in steps 1–3 you still have to bring yourself. If the capture side is your gap, start with bug reporting for QA teams.

FAQ

Is AI-generated code less secure than human-written code?

On the available evidence, yes, in specific ways. Veracode found 45% of AI-generated samples introduced OWASP Top 10 vulnerabilities, with XSS defenses failing in 86% of relevant samples, and the Stanford study found developers using AI assistants wrote less secure code while feeling more confident about it. The gap is concentrated in context-dependent flaws — the model can't know which data is untrusted.

Do newer models fix the quality problem?

Not so far on security. Veracode's core finding was that models improved at producing functional, syntactically correct code over time but showed no comparable improvement in producing secure code (Veracode). Plan your process around the failure modes persisting, and treat any improvement as a bonus.

How much extra QA time should we budget for AI-assisted work?

There's no universal number, but budget explicitly rather than assuming AI time savings cover it. In METR's randomized trial, experienced developers were 19% slower with AI tools while believing they were faster — self-reported speed is not a safe input to capacity planning. Measure your own cycle: time from bug found to bug fixed, before and after AI adoption.

What's the fastest single improvement a team can make?

Automatic context capture on bug reports. It requires no process change from developers, compresses the longest step in the fix loop (reproduction), and pays off on every bug regardless of who — or what — wrote the code.