The QA role isn't disappearing, obsolete approaches are

Every so often someone asks if AI is going to replace QA. The question is framed wrong. What I see disappearing isn't the role — it's the obsolete approach to that role: the QA who executes test cases with no holistic view of the product, and the dev who ignores the functional impact of what they build because "that's QA's problem."

The human with AI will replace the human without AI. I don't use that line to scare anyone — I use it because it accurately describes what's already happening. The mechanical part of QA work — running the same test case a hundred times, manually reviewing a coverage report, writing every equivalence-class scenario from scratch — is exactly the part an AI agent does better, faster, and without getting tired.

What it doesn't replace is judgment. Deciding what deserves a test and what doesn't. Understanding what impact a change has on the real business, not just on the code. Reading an ambiguous result and deciding whether it's a bug or expected behavior. That work becomes more valuable, not less, the more the rest gets automated.

That's why I think of modern QA as a bridge between the functional and the technical, not as a stage separate from development. A QA Engineer with AI can be a full team on their own: someone who designs test cases with formal techniques, runs execution supported by their own tools — I built Script Manager with that idea in mind — and reads the real code quality metrics, not just the last test's result, leaning on something like SonarCloud to see where the real technical debt is.

This isn't an apocalyptic prophecy or a victory lap. It's a surgical cut: one part of QA work goes to the machine, and the other part — the one that was always hardest to teach — becomes the center of what a QA contributes.

I originally published this on LinkedIn