The 2026 State of AI Coding Report, published by New Relic and Hanover Research, contains a contradiction the industry hasn’t resolved: 94% of tech leaders rate AI-generated code as higher quality than human-authored code at review. On the other hand, in the same six months, 82% of them had a production failure tied to AI code, 86% report more senior-engineer time spent firefighting, and production incidents are up 78%.
Higher quality at review. More failures in production. Both are true at once, and the report spends 19 pages trying to explain it without once mentioning testing or QA.
That omission isn’t evidence the answer lies elsewhere. It’s evidence the industry is framing the problem incorrectly. This is the first in a series on a different framing—one we call “test as context.”
Software gets built from context
That was true before AI, and it’s true now. What changed is the cost of getting it wrong.
Development usually starts from PRDs, tickets, and prompts. Those explain what’s being built and why. What they rarely carry is the behavioral detail: the positive and negative paths, the edge cases, the expected failures, the validation rules. That detail lives somewhere else—and when it’s missing from the work, a change can look clean in review and then break behavior three features away.
This was always the failure mode: a bug ships (or eats a review cycle) because it needed context that lived in a spec, an incident report, or another developer’s head rather than in the diff. The report’s own data shows the habit predates AI: 62% of teams ship code without line-by-line verification, and they were doing it before a model wrote a single function.
The Sembi Software Quality Pulse Report—based on responses from nearly 4,000 QA engineers, developers, security professionals, and engineering leaders—found that 53% of their code is now AI-generated or AI-assisted, and more than a third of teams say AI-driven development has pushed testing demands up by 26–50% or more.
Code arrives faster and in higher volume than review processes were built to absorb. Context that used to be merely helpful becomes load-bearing. When it’s missing, the cost stops being an occasional bug and starts showing up as a line item: review cycles, rework, regressions nobody spotted, budget burned re-explaining the same expectations to every new change.
Note that this argument is not that AI-generated code isn’t good enough—models improve every week, so that claim ages badly. The variable isn’t the tooling; it’s whether the work starts from an accurate account of how the product is expected to behave.
Your tests are that account
Here’s what QA teams already understand: a well-maintained test repository can be one of the most current descriptions of how a product is supposed to work.
Your PRD describes what you meant to build. Your test suite describes what you actually built. When a defect gets fixed or behavior changes, the smoke and regression tests get updated—the original PRD usually doesn’t. Over years of releases, the suite quietly drifts into being the closest thing your team has to a current, written record of how the product behaves today.
Test cases are the contract for expected behavior—the agreed definition of correct, written down and checkable. Every negative path a tester thought to cover, every boundary condition that once caused an incident, every validation rule that exists because a customer found the gap first: it’s all in there, maintained, specific to your product, and more current than anything else you’ve written down.
And in most organizations, it’s structurally invisible to the people—and now the tools—writing the code. The Sembi Pulse Report data puts a number on how sealed-off that knowledge is: only 1.82% of organizations report fully integrated QA tools within their DevOps pipelines. The most current description of the product sits in a system almost nothing else in the delivery chain can reach.
The knowledge reaches development late, as a bug report
Think about how behavioral knowledge actually flows on most teams. A developer, or their AI assistant, writes a new feature. The rules and edge cases that feature needs to respect live in the test repository, where neither the developer’s workflow nor their coding tools easily reach them. So the code gets written from the PRD and an inference about intent. The change ships or heads to review. Then—days or weeks later—a regression run or a tester catches what the missing context would have prevented, and the knowledge finally arrives in front of the developer. As a defect.
That loop was tolerable when code moved at human speed. At AI speed, it runs constantly, and every lap costs the same rework it always did—just more often. The verification gaps were always there. AI simply started shipping fast enough to hit all of them.
The fix isn’t slowing down, and it isn’t another after-the-fact check bolted onto the end of the pipeline. It’s moving the knowledge. The behavioral record your QA team already maintains needs to sit in front of the work—reachable by developers and the AI tools they use—before the code is written, not after it breaks.
This doesn’t replace requirements with test cases. PRDs explain what and why; tests add how the system is expected to behave in practice. Together they’re the full picture. Separately, one of them is doing a job the other can’t—and right now it’s doing that job from the wrong end of the development cycle.
What this asks of QA—and what it offers
If the test suite is the most accurate description of the product, then keeping it that way stops being QA housekeeping and becomes part of the product itself. Suites full of duplicates, stale cases, and drift describe the product badly. Clean, current suites describe it well—and a well-described product is exactly what AI-assisted development is starving for.
That reframing cuts both ways, and the second direction matters more. The teams that maintain test repositories have spent years being treated as a checkpoint at the end of the process. Test as context repositions that same work as an input at the start of it. The knowledge QA maintains isn’t a record of what got checked. It’s the standard everything—human-written or AI-generated—gets built against.
The industry conversation about AI code quality is currently a conversation about models, prompts, and review tooling. The 19 pages that never mention testing are looking for the answer in the wrong place. The most valuable context for AI-assisted development already exists, inside the systems QA teams have been maintaining all along. The interesting question—the one this series will take up next—is what happens when that context stops being locked away.
