Is QA Dying? The Real Squeeze Isn't Layoffs

Every few weeks the "is QA dead" post resurfaces, and the fear underneath it is real. But the thing actually squeezing testers this year isn't a machine doing their job. It's a machine making three times the work and leaving fewer people to check it.

Someone on r/cscareerquestions recently posted a thread with a title you can feel in your stomach: "My company is introducing a JIRA-to-PR AI pipeline — are we cooked?" It pulled 601 upvotes and 264 comments. That's not a niche worry or a bit of doomerism. That's a whole profession, at midnight, reading the room and not liking the temperature. If you've had the same 2 a.m. thought, you're in very large company.

So let me answer the question honestly, and then complicate it, because the honest answer is more interesting than the panic.

The real pressure on testers in 2026 isn't replacement — it's a three-way squeeze: mandates to adopt AI, budgets and headcount being cut, and an explosion of AI-generated code that still has to be tested by someone. Each of those is survivable on its own. Arriving together, they feel like the floor tilting. But follow where they actually lead and the conclusion flips: more code, written faster, trusted less, with fewer hands to check it, makes the person who can tell whether software actually works more valuable, not obsolete.

Haven't machines "come for" jobs before?

Constantly — and the history is less tidy than either the optimists or the doomers want it to be. Take the cash machine. When ATMs spread through the 1980s and 90s, the obvious prediction was that bank tellers were finished; the machine did the teller's core task, so the teller was surely next. Except that's not what happened. The economist James Bessen documented the twist: as ATMs made each branch cheaper to run, banks opened more branches, and the number of tellers in the US actually grew for decades. The job changed — away from counting cash, toward the things a machine on the wall couldn't do. The rote part was automated. The judgment part was promoted.

It's worth being precise about the darker version of this story too, because it's usually told wrong. The Luddites, in 1811, were not machine-hating simpletons. They were highly skilled textile workers, and they smashed specific machines — the ones being used to flood the market with shoddy goods made by cheaper, unskilled labour, undercutting their craft. Their fight wasn't with technology. It was with how the technology was being used against the people who knew the work best. That distinction is the whole ballgame for QA right now. The danger was never the loom. It was the choice to use the loom to devalue expertise.

What is actually squeezing testers, then?

Three things at once, and it helps to name them separately.

The first is being told to trust a tool you can't verify. In Stack Overflow's 2025 survey, 84% of developers now use or plan to use AI tools — but only 33% trust their accuracy. The single most-cited frustration, from 66% of respondents, was output that's "almost right, but not quite," and 45% said debugging AI-written code is more time-consuming than just writing it themselves. So the mandate from above is "use AI, go faster," and the lived reality at the desk is "I am now debugging a machine's confident near-misses, which is somehow worse."

The second is that the sheer volume is genuinely new. By one industry analysis, average developer output jumped 76% — from roughly 4,450 to 7,839 lines of code a month — while AI-generated pull requests carried about 1.7 times more issues, with logic errors 75% more common (Pie, 2025). More code, buggier code, arriving on the same Tuesday. Somebody has to look at all of it, and there are not suddenly 76% more somebodies.

The third is the quiet one, and the most dangerous: nobody's really reviewing it, and they know. The most honest sentence I read all year comes from an IT Revolution piece on AI and QA: "if you're going through sixty pages of manual code review of a pull request, at some point, you start skimming." That's the crisis in a single line. The generating capacity scaled overnight; the reviewing capacity didn't; so review is quietly degrading into skimming, and skimming with a straight face.

The machine isn't coming for your job. It's coming for your time — producing more code, faster, that someone still has to prove actually works.

So is AI actually taking QA jobs?

Mostly no, and the data is far less dramatic than the vibe in the thread. The US Bureau of Labor Statistics still projects roughly 10% growth for QA and test roles through 2034. And in Gallup's 2026 work, only 1% of laid-off workers named AI as the cause of their layoff — if anything, non-users of AI were let go at higher rates than users. The extinction story isn't matching the numbers. We're closer to the ATM than to the switchboard.

What is real is reshaping, and the r/softwaretesting community named the actual danger better than any analyst could. In a thread bluntly titled "QA team started using AI and stopped using their own minds" (88 points), a tester posting as abluecolor described the slide with painful honesty: "we have to keep up with expediting velocity and it feels like leaning on the tooling." The reply from former_farmer supplied the gallows humour — the system "self corrects over time. If bugs go into Prod, meetings are held to solve the issues." Read those two together and you've got the whole failure mode. Not testers replaced by a robot, but testers pressured into rubber-stamping a robot, until production quietly becomes the test environment.

What do you actually do about it?

Make your verification legible, first and hardest. When more code ships faster, the person who can prove it works becomes more valuable — but only if that value is visible, and caught bugs are notoriously invisible. Keep the receipts: what you caught, and what it would have cost had it shipped. Skimming leaves no trace; a prevented severity-one incident, written down, does.

Then own the review the machine structurally can't. AI generates; it does not take responsibility, and "almost right, but not quite" is precisely the seam human judgment lives in — a seam that's widening, not closing. When velocity pressure turns your review into skimming, say so out loud, in the language the business budgets in: "we are shipping 1.7 times the defect rate through the same review capacity" is a sentence a manager is forced to actually answer. And point yourself, deliberately, at the parts of testing that don't scale — exploratory testing, risk modelling, deciding what not to test. Those are the teller's relationship desk. They're what's left when the counting is automated, and they're where the job was always most worth doing.

The short version

The threat to QA is not replacement — BLS still projects ~10% growth to 2034, and Gallup found only 1% of layoffs blamed on AI.
History rhymes with the ATM, not the switchboard: automation moved tellers up the stack rather than out. The Luddites' real fight was never the machine — it was the machine used to devalue skill.
The genuine squeeze is three pressures at once: AI mandates, budget cuts, and an AI-code flood (output up 76%, AI PRs ~1.7x buggier — Pie, 2025).
Only 33% of developers trust AI output yet are told to lean on it (Stack Overflow 2025) — closing that verification gap is the job.
The real danger is skimming disguised as review. Survive it by making your judgment visible, non-negotiable, and aimed at the testing AI can't do.

Holding your ground on quality when every incentive says ship faster — and making that stance legible to the people who set the velocity — is the hardest part of testing, and it's getting harder. That's exactly what the Pearly Quality workshop on the human side of QA is built to train: making quality defensible in a room that's optimising for speed.