QA isn't dying, it's changing shape

Every time a platform like ours comes up, someone asks the anxious question underneath it, which is whether this replaces QA. It comes up on calls with engineering leaders, and more quietly from QA engineers themselves. I get why people reach for it, but it's the wrong question, and the framing misses what's actually happening.

Why it's the wrong question

"Does this replace QA?" assumes QA is one thing, a set of tasks that either a person does or a machine does. It isn't. Most QA roles are two jobs bundled together: the work that has to get done before a release can go out, and the thinking that decides what that work should be. Agents are very good at the first and have very little to say about the second.

The tax

The parts of QA that agents take over are the parts nobody became a QA engineer to do: writing the same brittle script for the hundredth time, babysitting a broken suite, manually clicking through a regression pass at 6pm before a release. That work was always a tax on the job, not the job itself, and handing it to an agent isn't a loss.

It's worth being honest about how much of the week that tax takes. A suite that breaks whenever a screen is redesigned has to be repaired before it can tell you anything, and a regression pass done by hand gets squeezed into whatever time is left before the release. The people doing it usually know exactly where the product is weakest, and rarely get the time to act on it, because the suite needs fixing again.

The job

What's left is the part that was always the actual skill, which is judgement.

Knowing what's worth testing and what isn't. Not every flow deserves a test, and a suite that tries to cover everything ends up slow, noisy and ignored. Good QA engineers know which journeys would really hurt if they broke, like sign-up, checkout or the one feature customers pay for, and put their effort there.

Understanding where a product is genuinely fragile. Every app has its weak spots: the screen that depends on three services, the flow that only breaks on a slow connection, the feature that was rewritten in a hurry. That knowledge comes from time spent with the product and the people building it, and it isn't written down anywhere an agent could read it.

Designing the cases a machine wouldn't think to. An agent will happily check that the happy path works. It takes a person to ask what happens if the user backgrounds the app halfway through a payment, signs in on a second device, or has an account that predates last year's migration.

Deciding what "good enough to ship" means for the release. A known bug on a settings screen might be fine for a routine release and unacceptable in the week of a launch. That's a call about risk, customers and timing, and it belongs to someone who understands all three.

The quality strategist

The role evolves into something closer to a quality strategist: someone who shapes what quality means, focuses attention where it matters most, and helps teams ship with greater confidence.

In practice, that looks less like executing test plans and more like owning them. A quality strategist decides what the agents test and writes those tests in natural language, describing what the user is trying to do rather than which buttons to press (we've written about how to write a great test). They review what comes back, decide which failures matter, and notice the patterns, like the area that keeps regressing or the test that fails for reasons nobody trusts.

It changes the conversation with the rest of the team, too. When QA is no longer the people who run the regression pass, they stop being the last gate before a release and get involved much earlier: in planning, pointing out where the risk sits in a new feature before it's built, and in product conversations about what the team is willing to ship with. That's a more senior seat at the table, and one a lot of QA engineers have wanted for a long time.

What this means for teams adopting agents

The mistake I'd most like teams to avoid is bringing in agents and sidelining the people who know the product best. Agents can run every test on every build, but someone still has to decide what those tests are, and the best person for that is usually the one who has spent years finding out where the product breaks. QA should be deciding what the agents test, not being sidelined by them.

We wrote about how this fits alongside the tests and people teams already have in How Semaloop works with your existing tests. The short version is that the agents take the repetitive work, and the judgement stays with people.

More valuable, not less

When the tax goes, what's left is the part of QA that was always hardest to find: knowing where a product is fragile and what's worth protecting. The people who have that become more valuable, not less, and the teams that keep them close to the agents will ship with more confidence than the teams that don't.