QA does not disappear, it moves left and up

The quality assurance function has been written off twice in my career. Once by test automation, on the reasoning that if the tests are automated you do not need people to run them. Once by “shift left” and the developer-owns-quality movement, on the reasoning that if engineers write their own tests you do not need a separate discipline.

Both waves removed a specific activity. Neither removed the need for the discipline, and both were followed by a period in which organisations rediscovered, expensively, what the discipline had been doing that nobody had written down.

We are about to do it a third time, and the pattern is recognisable enough to say in advance what will happen.

What actually goes away

Let me concede the strong version of the argument first, because it is partly right.

Agents are good at generating tests. Given a function, they will produce unit tests covering the obvious paths, several edge cases, and usually some error handling. The quality is roughly that of a competent engineer working quickly, which is to say better than what most codebases have. Coverage as a number goes up, and it goes up for very little money.

They are also good at the mechanical end of test maintenance: updating a suite after a refactor, filling in cases for a new branch, converting between frameworks. That work was real, it consumed real hours, and a lot of it is now close to free.

So a specific job does go away: the person whose primary output was writing and maintaining functional test code against a specification someone else wrote. That job was already shrinking and it is now shrinking fast. Anyone whose value proposition is “I write the tests” should read the market accordingly.

There is a trap hiding in the left column. Tests generated from the implementation test the implementation. If the code has a bug and the test was derived from the code, the test asserts the bug. Coverage rises, confidence rises, and the suite has learned to certify the defect. This is not a hypothetical failure mode, it is the default one, and it is why the right column is the whole discipline rather than a nice-to-have.

Left: into the definition of done

The first place quality work relocates is upstream, before anything is built.

An agentic life cycle runs on machine-checkable acceptance criteria. A ticket says what “done” means in terms precise enough that a system can evaluate whether it happened. This is the mechanism that makes the whole thing safe, and it lives or dies on the quality of the criteria.

Writing good criteria is a quality skill. Specifically, it is the quality skill: taking a fuzzy statement of intent and turning it into a set of observable conditions, including the negative ones. It is what good testers have always done, except that historically they did it after the fact, in a test plan, downstream of a specification that was already wrong.

The difference between a criterion written by someone with a testing background and one written by someone without is stark and easy to demonstrate.

Weak:   "User can reset their password."
Better: Given a registered account, when a reset is requested,
then a single-use link is sent to the account address
and is valid for 60 minutes.
And: the link cannot be reused after a successful reset.
And: requesting a reset for an unknown address returns
the same response and timing as a known one.
And: an expired link returns a specific error, not a
generic failure.

That third condition, about identical responses for known and unknown addresses, is the tell. It is an enumeration disclosure defence. Nobody writes that unless they habitually think about how a thing gets abused. That habit is a discipline, not a personality trait, and it is exactly what the QA function is made of.

Moving quality work left means the people who are best at this stop reviewing what was built and start defining what “built” means. It is more leverage than testing ever had, because a criterion applies before the work rather than after it, and because it is now enforced automatically rather than depending on someone remembering to check.

Up: into the system that does the verifying

The second relocation is less obvious and it is where the durable senior roles are.

When verification is automated at volume, the verification system becomes a piece of production infrastructure with all the properties that implies. It can be wrong. It can be miscalibrated. It can pass things it should fail, which is the dangerous direction, or fail things it should pass, which is merely expensive and which teams will route around until it may as well not exist.

Somebody has to own the question: is our verification actually detecting anything?

This is a real engineering discipline and almost nobody staffs it. It involves things like deliberately introducing defects to confirm the system catches them, tracking what escaped to production and working backwards to which check should have caught it, watching for criteria that always pass because they are trivially satisfiable, and noticing when a suite has drifted into asserting the implementation rather than the requirement.

The false-pass rate is the number that matters and the one nobody has. Teams track coverage, which measures how much code was executed, not whether execution would have noticed anything wrong. A suite with ninety percent coverage and no assertions worth the name has excellent coverage and zero detection. Everyone knows this and almost no one measures the thing that would reveal it.

The exploratory work that never automated

There is a third piece, smaller in headcount and disproportionate in value: someone using the product adversarially, with intent, looking for the failures that were never specified.

This has never automated and there is no sign that it is about to. It depends on a model of what a user is trying to achieve and what would make them angry, applied by someone who has decided to be difficult on purpose. Agents do not get annoyed. They do not have the experience of a workflow being subtly humiliating. They will not notice that the error message is technically accurate and makes the user feel stupid.

If anything this work becomes more valuable, because the volume of change going out is higher and the proportion of it that a human has consciously experienced is lower. Somebody has to actually use the thing.

Where this breaks down

The relocation assumes the people transfer, and many will not. Moving from writing tests to defining criteria and owning a verification system is a substantial change in skill and seniority. Some testers make that move easily; they were doing the thinking already and the test code was incidental. Others were hired for throughput and will find the new role unrecognisable. Organisations that announce the transition without funding retraining are announcing a layoff with extra steps.

Criteria authorship has an ownership fight built into it. Product managers believe criteria are theirs. Quality people believe criteria are theirs. Engineers believe both groups write criteria that are unimplementable. All three are partly right, and the resulting turf war is the most common reason criteria quality stays bad. Someone senior has to name a single owner and let the others contribute, and it needs to be said out loud.

Verification-of-the-verification is the first thing cut. It is meta-work. It has no visible output when it is going well. Under deadline pressure it disappears, and its absence is undetectable until an escape that should have been caught reaches a customer. I do not have a good structural answer to this beyond naming it and putting the false-pass rate on a dashboard someone senior looks at.

Some domains cannot express correctness as criteria at all. Anything where the requirement is aesthetic, or a matter of feel, or dependent on a distribution of real-world inputs you do not have, resists this entirely. Recommendation quality, latency under real traffic shapes, whether an interface is pleasant: these need human evaluation and sampling, and no amount of criteria writing substitutes.

The takeaway

Quality assurance is not being automated away. It is being relieved of the one part of its work that was mechanical, and pushed into the two parts that were always the point: deciding what correct means before anything is built, and owning the system that decides whether correctness was achieved.

Both of those are more senior than the job that is disappearing. Both are badly understaffed almost everywhere. The organisations that come out of this well will be the ones that saw the QA function as a source of the thinking rather than a source of the test code.

If you take one thing into next week: ask what your false-pass rate is. Not coverage. The rate at which your verification says yes to something it should have rejected. If nobody knows, that is the answer, and it is the first thing worth fixing.

The next piece steps up a level and asks what team shapes make sense when throughput stops being a function of headcount, which breaks most of the planning assumptions organisations have built over the last decade.