AI is quietly turning developers into testers

Nobody sent an email about it. No org chart changed. But something has shifted in how software teams work, and if you talk to developers right now you hear it in the way they describe their week.

They write less code than they used to. They read a lot more of it.

Copilot, Cursor, Claude Code and the growing swarm of coding agents now produce a serious share of what ends up in production. Pull requests are bigger. Features that used to take days appear in an afternoon. The velocity dashboards look wonderful, and leadership is happy.

Then the bill arrives, and it arrives downstream.

The numbers are no longer anecdotal

For a couple of years this was a hallway argument. Now there is data.

Faros AI instrumented 22,000 developers across more than 4,000 teams and compared each team’s lowest-AI quarters with its highest-AI ones. The upside is real: epics completed per developer up 66 percent, task throughput up 33.7 percent, PR merge rate up 16.2 percent. Then the other half of the report. Bugs per developer up 54 percent. Production incidents per pull request roughly tripled. Code churn up nearly tenfold. PR size up 51 percent. Median review time five times longer. They called the pattern the Acceleration Whiplash, and the name fits.

What sticks with me is something more understated.. Pull requests merged with no review at all, human or agentic, were up 31.3 percent, and Faros does not read this as a deliberate decision to skip oversight. Reviewers simply could not keep up with the volume arriving at their desk. Nobody chose that. It just happened, one busy sprint at a time.

The business side of it shows up in a separate study. Wakefield Research surveyed 400 executives and engineering leaders for Sauce Labs and found that 80 percent had traced a production incident, outage or customer-impacting defect back to AI-generated code in the previous twelve months. Sixty-five percent said their worst quality incident that year cost half a million dollars or more. And here is the part that should stop you: only 6 percent said they use AI tools to test that code all the time or often.

We are generating at machine speed and verifying at human speed. The gap between those two numbers is where the work now lives.

Why the quality burden lands on the developer

Three things push it there.

First, AI code is plausible. It compiles. It passes the obvious unit tests. The naming is sensible and the structure is tidy. On a quick read it looks like something a competent colleague wrote on a good day. The failures show up later, at integration boundaries, under real load, with data nobody anticipated, or when an assumption about the wider system turns out to be wrong. Those are judgement problems, not pattern-matching problems.

Second, adding people has not solved it. This is where I would push back on the popular story that teams simply cut QA and got what they deserved. In the Sauce Labs data, 64 percent of organisations actually grew their QA headcount over the past year, and incidents climbed anyway. More reviewers at the end of the pipeline is not a fix when the volume arriving at that end has multiplied. The bottleneck moved, and throwing bodies at the old bottleneck does very little.

Third, AI-written tests can make things worse rather than better. Models tend to write tests for the code that exists rather than the behaviour that was intended. Coverage looks healthy while intent goes unchecked. When the same family of model produces both the implementation and the tests that bless it, you have built an echo chamber and called it a safety net.

So the developer who used to own a feature now owns something harder: the question of whether it is actually correct. Does it match the requirement, not the prompt? Does it fit the architecture? Does it handle the cases the model never saw? Will anyone be able to maintain it in six months?

That is testing. It has always been testing. It just used to have somebody else’s name on it.

The most interesting argument here comes from an AI optimist

If you think this is a case of testers defending their turf, look at what Salvatore Sanfilippo has been writing.

Sanfilippo, better known as antirez, created Redis and rejoined the company in late 2024. He is an old-school C systems programmer, he has spent his career arguing for small, readable, hand-crafted code, and he has publicly told people not to fall for anti-AI hype. Nobody is going to accuse him of being threatened by a coding agent.

His post from July, "Control the ideas, not the code", makes an argument that should interest every test professional. Reading generated code line by line, he says, has become a poor use of a working day. Nobody can meaningfully review five thousand lines. Models are strong at locally optimal code and weaker at the big design decisions, so scanning function by function checks the thing least likely to be wrong. And every hour spent reading is an hour not spent asking what the software is actually supposed to do.

So what does he think should absorb that time instead? Quality, testing, and writing down the design in human language so the next person inherits the mental model rather than reverse-engineering it from source.

Read that again. One of the most credible hand-coders of his generation, arguing the pro-AI side of this debate, lands on testing and specification as the work that survives. That is the same place the Faros telemetry lands coming from the opposite direction. Review at the end of the pipeline does not scale with volume, so quality has to be established earlier and proven differently.

His own practice backs it up. The new Redis Array type took four months, and his account of it is not a story about prompting. It is a story about reading the whole thing line by line, building heavy test coverage, stress-testing the implementation from many angles, then rewriting modules he was not happy with. His conclusion was that for serious systems work you still have to be fully involved, but that the safety net let him attempt a level of complexity he would otherwise have skipped.

One honest caveat, which he raises himself: he is a domain expert with a deep mental model of what correct looks like. He is openly unsure what the right path is for younger programmers who have not built that model yet. That caveat is the whole problem in one sentence. If the job is now controlling ideas and proving quality rather than typing code, where is a developer supposed to learn how to do that well?

What the good teams are doing differently

The teams handling this well have stopped treating verification as a phase and started treating it as a discipline.

They separate generation from judgement. The machine produces, humans own the test strategy and the calls about intent. They write clearer specifications and acceptance criteria before generation starts, because verification needs something to verify against, and "looks right" is not a referent. They push quality gates earlier, into the development environment, instead of stacking more review at the end. They keep pull requests small enough that a human can actually read one. They use independent models or agents to cross-check output rather than asking the system that wrote the code whether the code is good. And they treat AI-generated changes with the same healthy scepticism they once reserved for an unfamiliar contractor’s first commit.

None of this is exotic. Most of it is what experienced testers have been arguing for since long before anyone had heard of an LLM.

Two questions I keep asking engineering leaders

When did you last train your developers on testing?

For most organisations the honest answer is never. Testing was somebody else’s competence, so it was somebody else’s training budget. Developers picked up unit testing from a colleague, learned the framework from the docs, and that was considered sufficient because a testing function existed downstream to catch what slipped.

That arrangement has quietly stopped working, and nobody has updated the training plan to match. We are asking people to own quality using knowledge they were never given. Then we act surprised when coverage numbers look healthy and incidents climb anyway.

The gap is not tooling. Your developers can already drive the tools. What they mostly have not been taught is the thinking: how to analyse risk and decide what actually deserves a test, the difference between a test that passes and a test that proves something, how to design test cases from requirements rather than from an implementation that may already be wrong, how exploratory testing finds the failures no suite was written for, and how to read a defect as information about a process rather than as a bug to close.

That body of knowledge exists. It is taught, it is structured, and it is certifiable. Foundation-level testing training takes a few days and gives a whole team shared vocabulary, which on its own removes a surprising amount of friction between developers and testers. From there the paths diverge into test analysis, test automation engineering, and the deeper specialisations. None of it is new, and none of it was invented for the AI era. It just became load-bearing for a group of people who never sat through it.

If your developers are shipping AI-generated code into production, a few days of proper testing education is not a nice-to-have this year. It is the cheapest risk reduction available to you.

When did you last bring a developer to Agile Testing Days?

Training gives them the foundations. The conference gives them something training cannot: the arguments, the war stories, and the people. Test professionals have spent their careers on exactly the questions your team is now hitting: how do you probe for risk instead of chasing coverage, how do you write down intent so that it survives contact with an implementation, how do you argue for quality in a room that only wants to hear about velocity.

That knowledge is unevenly distributed, and it is largely not in your codebase.

AgileTD 2026 runs from 16 to 19 November in Potsdam and online, with more than 100 sessions and over 80 speakers covering agile testing, automation, AI in quality engineering, DevOps and leadership. Early-bird pricing runs until 20 September 2026. The programme has always been built for whole teams rather than for testers alone, and this year that matters more than usual. The developer who spent last quarter cleaning up after an agent will find a room full of people who have thought hard about the problem they are living in.

Send them. Better yet, go with them. The conversation on the way home is usually where the change actually starts.

The upside is real

I want to be clear that none of this is an argument against AI-assisted development. The throughput gains are measurable and they are not going away. Competitive pressure will make the adoption decision for anyone still weighing it.

But the gains only become durable when testing catches up with generation. Teams that treat testing as a first class skill in the AI era will ship better software faster than teams still counting lines generated and PRs merged.

Maybe it is the right time for your developers to make the move.