Testing got promoted and demoted at the same time. Promoted, because when code is cheap, checking it is the part that still costs something. Demoted, because testing the way we did it before AI, at the pace it used to take, no longer has the right to exist. I'm a QA Engineer and I watch both happen on the same teams. If you're reading this, chances are you've run into it too.
What changed
Writing code became an order of magnitude cheaper. Not a bit faster. An order of magnitude. A feature that filled a sprint lands in an afternoon, and a good share of it wasn't typed by a person.
Quality didn't come along. It was never a property of speed. It's a property of someone knowing what the product is supposed to do, checking that it does, and keeping a record of what was checked so the next person doesn't start from zero. Done the way we've always done it, that work takes the time it takes, and the time is tied to the size of what changed, not to how fast it was written.
The size didn't shrink. The same feature, the same surface, the same number of ways to break it. What shrank is the time anyone is willing to give it. When a feature arrives in an afternoon, a week of checking looks absurd next to it, so the old QA process gets squeezed to match. A process squeezed below the time its work needs doesn't get faster. Its efficiency drops toward zero, and the team keeps the ritual while losing the result. The old process isn't wrong. It's just built for a world where code was the expensive part.
There's a quieter loss underneath. When a person writes a feature, they come out the other side understanding it: the edge cases they hit, the assumptions they made, the thing they decided not to handle. When an agent writes it, the feature ships and that understanding ships nowhere. Comprehension depth across the team drops with every release, and testing was the place where it used to be rebuilt.
Nobody chose this. The math of building software changed, and the process around the old math simply has no place for testing at the new pace.
Why it won't correct itself
When speed and quality compete, the room picks speed. It always has. A team that ships in a day isn't going back to a week so that testing can catch its breath, and arguing for that is a waste of everyone's time.
So the quality process is the side that adapts. Not by vanishing, and not by squeezing the old process into a smaller box until nothing inside it works. The time budget is what it is now. The question is what a QA Engineer should spend it on, and what should stop costing them time at all. The end state I expect is a middle ground: speed and quality both at a level you can defend, with a testing process built for the budget it actually has.
That process doesn't exist yet. Anyone selling you a finished one is early.
"The agent will cover it" is half right
The obvious move is to hand testing to the agent as well. Give it a skill, let it write the cases, let it run them. It works for volume, and volume was never the problem.
What it doesn't do is judge. An agent that starts from a prompt doesn't know which of the two hundred cases it just wrote matters, which risk this release actually carries, or that the same scenario already exists under a different title. It duplicates. It reports coverage that isn't there and can't tell you what it doesn't know. Every one of these is a mistake a QA Engineer is trained to catch, and none of them go away with a better model.
Priorities and critical judgment still need a person. That's not a gap to engineer around. It's the part worth building on.
What QA Vault is for
QA Vault isn't AI magic that promises full coverage. It's a tool for the quality process, and it changes one thing: what your agent knows when it starts working.
The agent gets the project's testing artefacts the way a colleague would have them. Cases, suites, runs, defects, and the reasons behind them, found by meaning rather than by exact wording. Together with the official skills, it also gets the working habits of a QA Engineer, so it stops improvising a process and starts following one. The result is an assistant that's useful on day one and a reliable source of truth about what the product is supposed to do.
What actually shifts is where the time goes. The agent becomes the colleague who takes the monotonous part that still can't be removed: retrieval, analysis, authoring, maintenance, reporting. That's most of what the old process spent its hours on, and it's the part that fits the new budget once it's no longer done by hand. You become the lead. You decide what matters, approve what changes, and carry the responsibility, and the same expertise reaches far more of the product than one person could before.
A beginning, not an answer
I don't know the final shape of a quality process that runs at the speed development runs now. Nobody does, and I'm suspicious of anyone who says otherwise. QA Vault is my attempt to start the adaptation instead of watching the process erode.
If you work anywhere near a delivery process and have felt the same pressure, or noticed what quietly disappeared from it once code got cheap, I'd like to hear how you see it. Disagreement counts.