AI-Generated Code Is Flooding Your Backlog – Here’s How QA Keeps Up

There’s an insidious pattern we’re seeing across client projects. A defect is discovered, diagnosed, resolved, verified, and closed. Three weeks later, something very similar occurs – not in the same place, but in another subsystem. It wasn’t a regression, exactly. The same logic had been copy-pasted into four places by an AI assistant, and the bug-fix only ever went into production once.

This is the sort of insight that makes it clear why QA is such a challenge when adopting AI coding assistants. The issue isn’t that they inherently generate worse code – it’s that they write increasingly similar code faster than your QA practices can keep up, and the metric that many teams use to evaluate the outcome of the process gets quietly devalued.

The bug you already fixed, three times over

GitClear examined 623 million code changes and found that duplicated blocks increased by 81% (peak in the last three years). The share of moved code (real code refactoring) dropped by 21% between 2022 and early 2026. Copying code now comprises 15.7% of all code changes in repositories, up from 14.6%. Developers are, on average, 5 times more likely to copy than refactor.

Read that as a test lead and it’s horrifying. Your regression suite covers the path you fixed; it has no idea the other three copies even exist. The defect density that used to kill your sprints is now a defect recurrence rate with no visibility.

It’s also why “we fixed that already” is an increasing liability. Something did get fixed, once. Somewhere

Why AI-generated code broke the review math

DORA’s 2025 annual report found that 90% of technology workers are already using some form of AI at work, and Veracode estimates that AI-assisted code comprises approximately 50% of code changes in organizations that use such tools. Take that against the QA mandate: the same team, same regression test suite, same two-day merge window before the branch can be cut.

DORA also correlated higher adoption of AI with increases in both delivery throughput and delivery instability – an indicator that many teams simply ship more but ship with lower confidence in their changes. A QA process built for a certain volume of changes breaks invisibly when multiplied by three, and not in a way that’s immediately obvious. Reviewers skip, approvals are rubber-stamped, and the gates remain formally in place but effectively non-existent.

The honest answer to “how does QA review all these changes” is that it can’t.

But what’s the alternative? Coverage is now a lie

This is where we draw the line between this advice and most testing circles – because we think coverage is also the wrong number to be chasing, even as many of our recommendations intersect with testing advice.

AI-generated code can write your tests for you. Your unit tests, the ones that are “covered,” are now mostly generated by a machine that has no ability to understand the production code it’s writing. Ask an LLM to help you with test coverage, and it will gleefully generate forty variations of a test that instantiate a class, call a method, and verify that no exception was thrown.

Coverage was always a questionable metric, and we’ve long argued that mutation testing is far more informative: by deliberately introducing defects, we can force tests to fail. It discovers false positives and reveals whether tests are actually asserting any meaningful behaviour.

Mutation testing has an intuitive correlate to the problem of assertion-free tests: if you change the production code and nothing fails, the test didn’t do its job. That’s why we advise our clients to stop reporting coverage figures to stakeholders – to customers, executives, whomever – and instead report mutation scores, with caveats, if needed. If your team has a suite that’s 85% covered but never actually stress-tested, it’s far safer to report 40% with a clear explanation of what that means. That way, if the false confidence proves misplaced, the blame doesn’t fall on the QA team that provided overly rosy numbers.

The practical answer is not to make QA review every AI-assisted change more slowly; it is to separate ordinary change flow from high-risk change flow, then concentrate human review where failure would matter most.

Stop gatekeeping. Start routing risk.

When the volume increases, the instinct is to impose a stricter gate: more mandatory reviewers, more approvals, longer checklists. But that simply creates bottlenecks; the pipeline avoids the reviewers or gets routed around, and the gatekeeping process itself becomes a theatre. In large part because the review process itself isn’t equipped to handle the increased volume without sacrificing quality somewhere else.

Testing AI-generated code at scale requires rethinking the QA mission. It’s not about what everyone reviews, but what gets reviewed by whom and at what level of scrutiny – a risk routing strategy. In many ways, QA becomes a triage function, where some changes only need a green pipeline, some only need an automated gate, and some require actual inspection.

It breaks down to four factors that every change should be scored on:

• Blast Radius: How many users or downstream systems are affected if something goes wrong?
• Data Sensitivity: Does the change touch any PII, financial data, auth systems, or audit trails?
• Duplication: Has this logic been copy-pasted elsewhere (and if so, how much)?
• Test Assertions: Did this change come with tests that would fail if the logic were incorrect?

Some of these are easy to score automatically: duplication, assertions. Others will require human input, but the parameters are clear. On the low end of the risk spectrum are small changes, low sensitivity data, no duplication, and basic assertions. These only require a green pipeline. On the high end are auth, financial data, PII, audit trails, novel logic, or a combination of these factors. Those get a senior review and deeper inspection. Mid-tier changes get automated assertions plus a closer look at the risk areas.

You’re not “reviewing less,” per se; you’re reviewing a narrower but more critical set of changes more carefully than before.

Where to start

Start with the lowest-friction changes that make AI-assisted risk visible, reviewable, and measurable:

1. Tag AI-assisted changes. Action: Add a commit tag or message trailer for AI-assisted changes. Why it matters: This creates telemetry on assisted-change volume and location. Payoff: QA can route risk based on visible change patterns instead of guesswork.
2. Limit pull request size. Action: Set a hard line for generated PR size, such as keeping reviews near 200 lines rather than 900. Why it matters: Smaller changes are more likely to receive real inspection. Payoff: Review quality improves without adding process overhead.
3. Add duplication scanning. Action: Add a clone detector to the pipeline and make new duplication a review trigger. Why it matters: It catches the recurrence risk created by copied AI-generated logic. Payoff: QA can find related defects before the same bug spreads across subsystems.
4. Pilot mutation testing on one critical module.

Action: Replace coverage reporting with mutation testing for a single high-value module. Why it matters: It reveals whether tests fail when production logic is deliberately broken. Payoff: Stakeholders get a more honest signal of test-suite quality.

The QA teams that are succeeding in this space aren’t necessarily doing it by buying more tools or spending more money. They recognized early on that a person can’t review every change, and they stopped pretending that a coverage threshold was an appropriate proxy for test suite quality when dealing with AI-generated code. A lot of the wins we’re seeing are from practices that apply to any team, but the critical insight is to understand what the limitations are and what the actual risks are at scale.

If your queue of changes to review is growing faster than your QA team can handle, start with step 1 and step 3: tagging and duplication scanning. In three weeks, you’ll have enough telemetry to understand what the real risks are, and you can have a more meaningful conversation with the delivery leads about where to focus QA resources.

FAQs