Will AI Replace QA Engineers? I Think We're Asking the Wrong Question.

Let me tell you what's actually happening.

Somewhere right now, a CTO is in a budget meeting. Someone slides a deck across the table. It shows AI-generated test suites, automated coverage reports, Copilot writing unit tests in seconds. The slide says something like "AI-Augmented QA Strategy." What it means is: we're cutting three people from the QA team.

Nobody says that part out loud. But everyone in the room understands it.

This is the conversation the industry isn't having honestly. Not "will AI replace QA" — that's the LinkedIn debate. The real question is: are companies using AI as a convenient excuse to gut quality budgets they always wanted to cut? And the answer, in a lot of organisations, is yes.

That's going to hurt them. Some of them badly.

The Budget Math That Looks Right and Isn't

I get why it's tempting. AI genuinely does compress some of the routine work in QA. Test case generation, regression scaffolding, writing documentation — these things are faster now. An engineer who knows how to use these tools can cover ground that used to take a larger team.

So if you're looking for a justification to reduce headcount, the timing is convenient. You can point at the tooling and say the productivity gap is covered.

What doesn't show up in that slide is the kind of work AI can't do.

AI generates tests based on what already exists — known requirements, existing code paths, documented behaviour. It is genuinely useful there. But the failures that cost companies the most money are almost never in the documented behaviour. They're in the edges. The interactions nobody mapped. The user behaviour nobody anticipated. The way two systems that each work fine individually behave when they talk to each other under load at 2am on a Tuesday.

That takes human judgment. It takes someone whose job is to sit with a system and think adversarially about it. Not just run a suite and report a number.

When you cut that person to save on headcount, you don't eliminate that work. You just stop doing it.

Some Companies Already Ran This Experiment

It's not theoretical. We've seen what happens.

Zillow built an AI pricing model, trusted it to make real purchasing decisions at scale, and didn't invest enough in testing the boundaries of where its confidence broke down. The model performed fine on the data it knew. It didn't perform fine in the actual market. They wrote down $569 million and closed the programme. The thing that was missing wasn't better AI — it was someone stress-testing the model's limits before those limits were discovered by a housing market.

Air Canada deployed a customer-facing chatbot that, when asked about bereavement fares, told a grieving passenger he could buy a full-price ticket, travel, and then apply for a discounted rate retroactively. That policy didn't exist. The passenger followed the advice. Air Canada refused the refund. A tribunal ruled against them. The airline actually tried to argue the chatbot was a separate legal entity responsible for its own statements. The tribunal wasn't impressed.

Amazon spent years building a recruiting AI on a decade of hiring data, and the system quietly taught itself that women's colleges and CVs mentioning the word "women's" were negative signals. Nobody caught it in testing. Reuters caught it after deployment. The project was shut down.

These aren't stories about AI being dangerous. They're stories about what happens when the human function responsible for adversarial thinking — for asking "what if this does something we didn't expect" — isn't in the room.

The Part Nobody Wants to Say

QA has always been the discipline that gets squeezed when budgets tighten, because its value is invisible right up until it isn't. When QA is working, nothing bad happens. When nothing bad happens, leadership asks why they're paying for it. This is the oldest cycle in software.

AI didn't create this problem. It just gave it a new excuse.

"We have automated testing now." Used to be Selenium, then CI/CD pipelines, now it's AI-generated test suites. The argument is always the same: we've automated the work, so we need fewer people. And there's always just enough truth in it to make the budget cut feel reasonable.

What changes with AI-powered products is the stakes. When your product has an AI component making decisions — generating text, giving advice, taking actions on behalf of users — the failure modes are different in kind, not just degree. The system can be wrong in ways that look confident. It can be manipulated. It can produce outputs nobody anticipated because nobody anticipated the input.

Testing this properly requires more human judgment than testing a CRUD application, not less. Cutting QA to save money while deploying AI is exactly backwards. You're reducing oversight at the moment you're increasing complexity.

What This Means in Practice

The Knight Capital story from 2012 is worth keeping in mind here. Knight Capital deployed new trading software without fully decommissioning the old code. A repurposed flag triggered the wrong behaviour. For 45 minutes the system executed 4 million trades nobody intended. By the time humans understood what was happening, $440 million was gone. The firm was finished as an independent company.

The lesson isn't about bad code. It's about automated systems executing at speed, beyond the point where humans can observe and intervene in time to stop the damage. That dynamic — fast, confident, wrong — is exactly how AI agents behave when they're operating outside their tested parameters.

The testing discipline required hasn't changed. The speed at which an untested AI system can cause damage is higher than it's ever been.

So Will AI Replace QA?

No. But I think a lot of companies are going to act as if it has, and some of them are going to have very bad years as a result.

The engineers who will struggle are the ones doing the work that AI genuinely can automate — writing repetitive test cases, maintaining regression suites, producing test documentation. That work is changing.

The engineers who will be more valuable than ever are the ones who can think adversarially about complex systems. Who understand failure modes that aren't in the spec. Who can look at an AI-powered feature and ask the questions it was never designed to answer.

That's not a smaller job than it used to be. It's a harder one.

It doesn't. It never did.