For fifty years, the scarce resource in software was someone who could write the code. Every process we built assumed it: sprint planning, story points, hiring plans, the whole shape of an engineering org. That assumption broke, and most teams have not reorganized around the break yet.
Writing code is no longer the constraint. Finding out whether it works is.
The volume is already here
This is not a forecast. In DORA's 2025 report, 90% of technology professionals said they use AI at work. JetBrains put regular use at 85% of developers, with code quality the number one concern they named. Satya Nadella said AI writes 20 to 30% of Microsoft's code. Y Combinator reported that a quarter of one recent batch had codebases that were 95% AI-generated.
A team of five now produces the change volume of a team of twenty. What none of them produced is twenty people's worth of judgment about whether that change is correct.
Faster and less stable, at the same time
DORA 2025 found something worth sitting with. AI adoption now correlates positively with delivery throughput, a reversal from 2024. It also continues to correlate negatively with delivery stability. The same teams shipping more are shipping worse. DORA's own summary of the effect: AI does not fix a team, it amplifies what is already there.
Telemetry from delivery pipelines tells the same story from the inside. Faros AI's 2026 analysis of 22,000 developers found bugs per developer up 54%, the ratio of incidents to pull requests up 242%, and median time in code review up 441%. Their acceptance rate for AI suggestions tripled over the same window.
Generation got cheap. Verification did not. Everything downstream of the keyboard is now the expensive part.
That 441% is the tell. Review time did not explode because reviewers got slower. It exploded because the queue in front of them grew faster than they did, and because reviewing code nobody on the team wrote is harder than reviewing code a colleague wrote. The bottleneck did not disappear. It moved one step to the right, into review and QA, where it is now sitting on your roadmap.
Tests are the obvious gate. They are not holding.
The intuitive answer is to let the agents write tests too. They will. The problem is what those tests actually do.
Researchers who studied 48,563 agent-authored commits found agents add mocks in 36% of test commits, against 26% for human commits. A mock-heavy test asserts that your code called a function you also wrote down. It does not assert that the feature works. A separate 2026 study of agent test-writing found that print statements outnumber assertions by three to five times in agent-generated tests, and concluded these are “observational debugging tools rather than robust validation mechanisms.”
And there is a hard number for what weak tests cost. When researchers manually audited patches that passed SWE-bench, they found 29.6% behaved differently from the correct fix. Passing tests. Wrong code. The benchmark's reported success rate was inflated by 6.2 percentage points purely because the tests were not strong enough to notice.
We went deeper on this evidence in what the research says about agent-written tests, and on the specific failure modes in what Claude Code gets wrong about testing.
The tester cannot be the author
Every failure above has one shape. The thing that wrote the code also decided whether the code was correct, using the same assumptions, the same misreading of the ticket, the same blind spot. An agent that misunderstands the requirement writes a test that enshrines the misunderstanding, then reports green.
This is not an AI problem. It is the oldest rule in QA, and it is why testing became a separate discipline in the first place. Independence is the whole point. What is new is that the industry spent two years handing verification back to the author because the author got fast enough to offer.
So the constraints on QA in the agentic era are specific:
- Independent of the code. Verification has to come from somewhere other than the process that produced the change, or it is a self-graded exam.
- Anchored to intent. The reference has to be what the product was supposed to do, from the PRD, the ticket, the design, not what the implementation happens to do today.
- Fast enough to keep up. QA that takes a week is not a gate when the codebase changes every day. It is a report on a version that no longer exists.
- Free of maintenance debt. A suite that needs constant repair loses to the pace of change. Teams delete the suite, or worse, ignore it while it stays red.
Where this ends up
The teams that win the next few years will not be the ones that adopted AI coding fastest. Nearly everyone did that already, and the throughput gains are table stakes. They will be the teams that rebuilt verification to match the new output rate, and can therefore actually ship what they generate.
That is the whole thesis behind Nua. Test agents that use your product the way a person does, that read your specs and tickets to know what correct means, that never wrote the code they are checking, and that run every night without anyone maintaining them.
Ship fast is solved. Break nothing is the open problem.
Nua is AI QA built for agentic coding. It finds bugs before your users do, reproduces the ones they report, and turns every fix into a regression test.