Agentic QA: What Actually Changes When an AI Agent Has Write Access to Your Tests

A chatbot that suggests a test case is a search engine with extra steps. An agent that opens a pull request adding that test, and another one fixing the three tests your last redesign broke, is doing something structurally different: it's committing to your repo.

That distinction is the whole definition of agentic QA. Not "AI helps write tests." An agent has write access to your suite, and a person reviews what it did instead of doing it themselves.

What the agent should actually own

Two jobs make sense to hand over, and they're not the same job.

Test authoring works when the agent follows conventions that already exist. It reads your existing suite, matches your selector strategy and naming, and drafts coverage for a new flow the same way a new hire would after reading the codebase for a week. It doesn't invent a testing philosophy from scratch.

Suite maintenance is the bigger win in practice. A UI change breaks a selector, a flow shifts by one screen, and instead of that test going red and staying red for two sprints, the agent updates it and opens a PR the same day. This is the version of "AI test maintenance" we've written about before: the value isn't in writing tests faster, it's in keeping the ones you have from rotting.

What still needs a human, every time

Every agent-written or agent-modified test goes through a pull request, reviewed the same way as any other change to the codebase. No exceptions, because the agent doesn't know what "correct" means for your business logic, only what "matches the existing pattern" means.

That review has to catch a specific failure mode: an agent asserting on behavior that happens to be true right now, not behavior that's actually required. A test that passes because it copied what the UI currently does, rather than what the UI is supposed to do, is worse than no test. It gives you false confidence the next time someone breaks the feature correctly.

Where it breaks down

An agent can't fix a suite that has no conventions to follow. If your tests are inconsistent about selectors, fixtures, and structure, the agent inherits that inconsistency and reproduces it faster. The audit has to come before the agent, not after.

It also isn't a replacement for deciding what to test. Coverage priorities, which flows matter most to the business, which edge cases are worth an automated check versus a manual one, that's still a judgment call a person makes. The agent executes the pattern; it doesn't set the strategy.

And it doesn't replace exploratory testing. An agent that only knows your existing suite will never find the bug a tester finds by doing something a user would actually do but nobody thought to write a test for.

The actual question to ask

Not "should we use an AI agent for testing," but "does our suite have conventions solid enough for an agent to extend without a person rewriting half of what it produces." If the answer is no, that's the first project. If the answer is yes, the agent's real job is keeping your regression suite from falling behind your product, which is the maintenance work most teams already don't have time for.

We run this as part of our agentic QA service: an audit of your suite first, then the agent connected to real pull requests, reviewed alongside your team until you're comfortable taking it over yourselves.