I'll give you the takeaway from this blog right now: the part of a test worth keeping is what it's meant to prove, not the script that proves it. Scripts have become cheap to generate, so we should stop treating them as something precious to maintain. Keep the intent. Throw away the script.
Last time I wrote that the first time an AI agent runs a manual test case, it can leave an automated test behind, and every later run can use that script instead of the natural-language steps. That's where this starts, not where it ends. The obvious next question is what happens when the application changes and the script stops working.
The traditional answer is that someone fixes it. I think that answer is about to change, and the reason it's changing says a lot about where testing is heading.
The short answer
Why the intent behind a test is the asset worth keeping, at a glance:
Keep the intent. Throw away the script.
For most of the last twenty-five years, a test script was something you built and then protected. You invested in a framework, wrote the scripts carefully, and maintained them for years. The whole argument for that investment was amortization: build it once, run it a thousand times, and the cost per run falls toward zero.
That argument was always shakier than it looked, because maintenance kept eating the savings. AI finished it off. A QA manager we spoke with recently described both eras about his own team, almost in one breath. A few years ago they built a proper framework and everyone worked inside it. Today, he said, everybody kind of sets up their own. One of his engineers pointed an AI coding assistant at an old test suite and had dozens of new tests back within a day.
That isn't sloppiness. It's a rational response to a new cost curve. When a script can be generated in minutes, the case for spending years maintaining it gets a lot weaker. A test used to be an asset you built. It's becoming output you generate.
It helps to pull a test apart. Every test is really two things stacked on top of each other.
The top layer is intent: what has to be true for the software to be working. "A returning customer can apply a promo code at checkout and the order total reflects the discount." That sentence changes when the business changes, which isn't often.
The bottom layer is implementation: which field to click, which selector to use, how long to wait for the page, which button says "Apply." That layer changes whenever someone touches the interface, which is constantly.
Now this gets delicate. For over two decades we've stored, versioned, reviewed and maintained the bottom layer, and mostly let the top layer live in people's heads or in a test case nobody reads anymore. We've been carefully looking after the part that breaks every sprint, and neglecting the part that actually matters.
Once you see the two layers, maintenance looks different. Today, when a script breaks, the instinct is to repair it: find the element that moved, patch the locator, rerun. Even most "self-healing" approaches work this way. They're smarter at patching, but they're still patching the implementation.
The alternative is to go back up a layer. The script failed, but the intent hasn't changed. So hand the intent back to an AI agent, let it work through the application as it is today, and have it produce a fresh script. You don't repair the old one. You regenerate a new one from the thing that never moved.
This only works with one firm rule: the agent can change how the test gets there, but never what the test proves. It can find a new path to the promo code field. It can't decide the discount no longer needs to be checked. And when it regenerates, a person should be able to see what changed and approve it. That's what keeps a test trustworthy when the script underneath it is disposable.
A fair question at this point: if an agent can work through the application from the intent, why keep scripts at all? Why not let the agent run every test, every time?
Because it's slow and expensive, and it doesn't need to be. An agent reasoning its way through a stable checkout flow for the thousandth time is doing work that was already done. A script runs the same flow in seconds, for next to nothing, and gives the same result every time. For a regression suite that runs frequently, that difference adds up fast.
So the model I believe in is simple: agentic when needed, deterministic by default. The script handles the repetition. The agent steps in when something changes, understands what the test was meant to prove, and leaves a new script behind. If that sounds like the fast-and-slow thinking I wrote about a few weeks ago, it is. Save the expensive thinking for the moments that need it.
If the intent is the asset, it deserves to be treated like one. That means writing it clearly enough that someone, or something, new to the product could follow it. It means reviewing it the way you'd review a requirement, not the way you'd skim a script. And it means versioning it and linking it to the features it protects.
It also changes which skills matter most. The most valuable person on a testing team used to be the one who could build and nurse a framework. Increasingly, it's the one who can describe precisely what "working" means, and tell whether a result is actually right. That was always the heart of testing. For a while it just got buried under a lot of selectors.
So here's my suggestion for your next sprint review. Next time a pile of scripts goes red after a UI change, don't ask who's going to fix them. Ask whether the intent behind them is written down well enough that nobody should have to.