Do We Still Need QA Engineers in the Age of AI? Four Career Pivot Directions Explained

"Do we still need QA roles? Should I switch careers?" These are the most common questions flooding the inbox of Bilibili creator Mingdui. As bugs get caught earlier, developers start owning their own quality, and QA Agents enter the development pipeline, test engineers sitting downstream are feeling the pressure. Mingdui's conclusion is blunt: AI hasn't replaced testing — it's only taken one piece of the job. The other piece hasn't been taken away. If anything, it's become more valuable.

Where the Anxiety Comes From: Bug-Finding Is Shifting Left

For the past decade, finding bugs was essentially the whole job. A typical day for a QA engineer looked like this: receive a build, run through the main flows, file a bunch of bugs, wait for the fix, run it again, repeat. The whole day was click, click, click — and the faster you clicked, the better you were considered at your job.

That's changed. In many teams, shifting bugs left and having developers own their own quality is already the norm. The act of "finding bugs" is migrating left — into the hands of developers and AI. Mingdui breaks "finding bugs" into two distinct actions: the first is discovery — a button doesn't respond, an API returns 500, a field calculates wrong; the second is judgment — can this version ship?

AI has taken over discovery. What it can't do is judgment. AI can write code, run tests, and generate reports, but there's one sentence it can never say: "If something goes wrong, I'll take responsibility." AI can get the work done, but it can't be held accountable. The final call on quality still requires a human.

"Shift-Left Testing" is a major trend in modern software engineering — moving testing activities from the end of the development cycle toward earlier stages, shifting from "test after development is done" to "engage at the requirements phase and trigger automated checks on every commit." The technologies driving this include unit tests and static code analysis embedded in CI/CD pipelines, integration tests auto-triggered at the Pull Request stage, and AI-powered code review tools (like GitHub Copilot and CodeRabbit) that have gained traction in recent years. For QA roles, shift-left means large volumes of repetitive regression work are being absorbed by automation, pushing the value boundary of manual testing upward into judgment calls that can't be reduced to rules.

The Core Skills Haven't Changed — What Changed Is the Target and the Tools

Mingdui makes a sharp observation: QA engineers who only know how to "click through" will get left behind in the AI era — but not immediately. There's still time. The foundational skills of a test engineer haven't actually changed at all: skepticism, edge case reproduction, and closing the verification loop. When everyone else says "it's fine," you're the one who asks, "How do you prove that?"

When everyone assumes AI is capable, the ability to raise doubt and exercise veto power becomes increasingly rare. What has genuinely changed is two things: what you're validating and the tools in your hands. Before, you validated features. Going forward, you'll validate value. AI will first become a tool you wield — and eventually become the very thing you need to validate.

Track One: Move Toward Business Value

The landing point of QA acceptance testing is no longer code quality — it's business value. This track branches into two directions.

Direction 1: User Experience

AI can generate interfaces, write copy, and produce proposals, but it can't make judgment calls. It doesn't know whether placing a button here will make users anxious, whether empty states, poor network conditions, and error messages feel right, or whether the UI/UX has any aesthetic coherence. Someone still needs to own that. Follow this path far enough and it leads to product operations or user experience roles.

Direction 2: Input Data Quality

This is the smoothest transition for anyone with a technical background. Event tracking validation, log analysis, funnel reproduction, and metric definition — these are things QA engineers already do every day. Maintain your sensitivity to data and your analytical instincts, and the same work rebranded as "data operations" holds up just fine.

Track Two: Go Deep on AI

The second track is about genuinely learning and applying AI.

Direction 3: Use AI to Empower Yourself

Test engineers are the most experienced people on any dev team when it comes to automated testing. Writing scripts and building frameworks is home turf for QA. Now you hand that off to a QA Agent to run — and your job becomes two things: get it to run more tests, and keep making it better. You understand automated testing better than anyone, which means you're also the best person to tune and optimize a QA Agent.

Direction 4: Test Intelligent Agents

This is what Mingdui sees as a blue-ocean opportunity. The target of testing has changed — it's no longer a deterministic system where "input A produces output B." Now the subject is an LLM or an Agent. The same input might give you three different answers. So how do you determine whether the output is correct? How do you design the evaluation criteria and assessment framework? This is an entirely new role, and an opportunity space that's still largely uncharted.

Testing deterministic systems and testing LLMs/Agents are fundamentally different. Traditional software testing relies on deterministic assertions — "given this input, expect this output." LLM outputs are inherently stochastic (controlled by the temperature parameter) and context-dependent; the same prompt at different moments might produce semantically similar but textually different responses, making traditional string-matching assertions completely useless. Current industry approaches to evaluation include: LLM-as-Judge (using another LLM to score outputs), vector-based semantic similarity comparison, computing BLEU/ROUGE scores against human-annotated golden sets, and trajectory evaluation for Agents (assessing which tools were selected and whether the call sequence was reasonable). There is no unified standard for this evaluation framework yet — which makes it both a genuine challenge and a window of opportunity for experienced QA engineers to step in and establish methodology.

Transition Tools and Growth Planning

For both tracks, Mingdui's team has developed two in-house tools.

For those aiming toward business value, there's a "growth planning skill": input your current situation and capabilities, set a target role you want to move toward, and it generates a roadmap, a phased plan, and progress tracking. When you drift off course, it helps you recalibrate — like having a personal coach reviewing your progress.

For those going deep on AI, the team's internally refined QA Agent is available to set up and use. It's been forged against real projects — capable of taking repetitive work off human hands and surfacing issues that tend to slip through the cracks. But the final quality judgment still requires a dedicated human owner.

Closing: Testing Won't Disappear — It Will Diverge and Evolve

Back to the original question: do we still need QA engineers in the age of AI? The answer is yes. AI won't make testing disappear — it will cause testing to diverge and evolve: one path goes deep into business value, the other goes deep into AI.

In the age of AI, everyone can use AI to expand horizontally and close information gaps. The real danger isn't being replaced — it's staying closed off and refusing to step through the AI door at all. People who actively seek answers won't be left behind.