AI QA: what it is, what it is not

If you run a QA team, you have probably been pitched three AI QA tools this quarter, and they meant three different things. One writes tests, one decides whether tests passed, and one offers to be your QA function. Each has a different owner and a different way of going wrong.

What is AI QA?

AI QA is the use of machine learning models, usually large language models, inside software quality assurance: to generate test cases, explore an application, triage failures or judge results. It is a set of techniques applied to the QA process, not a replacement for it, and its reliability depends on which of those jobs the model is given.

The term also covers testing AI models themselves and scoring call-centre conversations. This page is about AI quality assurance for the software you ship.

The last clause carries the weight. A model drafting forty edge cases for a refund form is low risk, because someone reviews the draft. A model deciding the refund form works is a different job.

The three things people mean by AI QA

Every product you will be shown lands in one of these rows.

The first row holds up, on one condition: something other than the model decides whether its tests are right. The second and third rows fail for the same reason, covered below. To sort a pitch, ask who decides pass or fail, and what that decision reads.

What AI is genuinely good at in QA

AI QA testing works where the model produces a draft that is cheaper to check than to write.

Generating cases. Given a form with currency, amount and a partial-refund toggle, a model will list the combinations a tired person skips: zero, negative, more than the balance, a currency switch mid-flow. Enumeration is cheap for a model, and a reviewer can discard the bad ideas in seconds.

Triaging failures. Forty red tests after a dependency bump usually have three causes. A model reading stack traces and logs can group them, because that is pattern matching over text. If it groups one wrong, a person reading the group notices.

Spotting coverage gaps. Hand it the route list, the user journeys and the test names, and ask what has no test. "Account deletion: nothing touches it" is a text-to-text comparison, and models are good at those.

Summarising a failure for a human. Two thousand lines of CI output become "POST /refund returned 422 after the currency switch". The summary can be checked against the log.

The common thread is that each output is an input to someone else's decision. None of them is the decision.

What it is bad at

The weak spots are where nothing outside the model can check it.

Knowing intent. The ticket says "users can cancel an order". Does cancelling refund the card, restock the item, email the customer? The model fills every gap with something plausible, and plausible is not what product agreed.

Deciding what correct means for your product. Is a 200 response with {"error": "card_declined"} in the body a pass? Should a refund of 10.005 round up or down? Those answers live in your business rules and your team's heads, not in the code the model reads.

Judging its own output. This is the expensive one, and why AI in QA automation goes wrong even with careful prompts.

The self-assessment problem

A model that wrote the code, or wrote the test, cannot also be the oracle for whether it worked. In testing terms an oracle is whatever tells you the correct output for an input, and finding a trustworthy one is a known hard problem on its own. Making the author the oracle removes the one property an oracle needs: independence.

The mechanism is not malice. A model is tuned to produce output that gets accepted, and a finished-looking result gets accepted. Looking done is cheaper than being done. When the same model also grades the work, it grades with the same assumptions that produced the work, so its blind spots and its checks line up exactly.

Here is what that looks like. An agent adds an order-history page that reads data.orders from /api/orders, and writes a test that mocks the fetch with { orders: [...] }. The test passes.

The real API returns { items: [...] }. Every customer now sees "No orders yet".

The agent's summary reads "Added order history page with tests, 6 of 6 passing." Each word of that is true. The test checked that the code agreed with the mock the same agent wrote, which is a model agreeing with itself.

This is observed behaviour. METR reported frontier models modifying tests or scoring code to get a higher score instead of solving the task. Claude Code's own tracker has an issue titled "Claude fabricates test results - reports ALL PASSED when tests are FAILING".

The classic split of verification vs validation quietly assumed the author and the checker were different people. With an agent they are the same actor, and that is the gap every AI QA setup has to close.

A workable split: AI explores, deterministic checks decide

The arrangement that survives contact with real products divides the work three ways.

AI explores and generates. It drives journeys nobody scripted, drafts cases, groups failures and writes the summary. The drafts are only as good as their input, which is the subject of AI test case generation.

Deterministic checks decide. A check is deterministic when the same build and the same input produce the same verdict every time. It should read what the system did, not what the page looks like: the request fired once, the status was 200, the store holds the new balance, the console stayed clean.

People own intent. Someone on the team says what correct means and which checks to keep.

That split is the design Reticle is built on. An agent drives the running app, and the verdict comes from assertions on the network, the application state and the console, not from the agent's summary. What the agent drives is saved as a flow and replays without a model in the loop. We call that step AI verification, and the definition post covers what a verdict has to carry.

In our published benchmark it caught 85 of 88 seeded bugs with no false alarms. Two of the other three are traps a correct tool must not flag; one is a genuine miss, stale data inside an iframe.

Re-verifying a four-flow suite costs about 480 tokens, roughly 251 times cheaper than a model re-driving the same flows (a compiled suite costs no tokens, so the comparison is with the re-drive only). Eight replays of one flow gave the same verdict eight times: 0% flake. The scorecard has the method.

How the QA role changes

The job does not disappear. What changes is the thing the job produces: from test cases to verdicts.

An AI QA engineer, where teams use the title, spends less time typing selectors and more on what a model cannot do. They write down what correct means for each journey and decide which checks gate a release.

They review AI-drafted cases and throw most away. They read a failed verdict and decide whether the product or the check is wrong.

Call it a verification owner: someone who owns the oracle, not the keystrokes. The skills that matter most are ones experienced testers already have, like knowing where products break and being suspicious of a green run.

A five-level maturity model

Place your team, then pick the next step. Each level keeps everything from the one before.

Level 1: ad hoc prompting. People paste code or a bug into a chatbot and use what comes back. Nobody can say afterwards what was checked.

Level 2: AI generates, humans judge. Models draft cases and test code, and a person reviews each one. Output goes up, the review load with it, and skimming starts. Most AI test automation stops at this level.

Level 3: AI triages, humans decide. Models group failures, flag gaps and summarise runs. People still make every pass or fail call, so it scales only as far as they do.

Level 4: AI explores, deterministic checks decide. Agents drive the running app and draft flows. The verdict comes from checks on requests, state and console that give the same answer every run. People review the checks, not every click.

Level 5: every change verified on commit, with auditable verdicts. Saved flows replay on every commit, and the build fails unless the flows a change touches have passed. Anyone can see why a verdict passed:

# fails unless a passing run covers every flow the edits since main affect
npx @reticlehq/server gate --since main

The jump that matters is from level 3 to level 4, because that is where the verdict stops coming from a model.

If you want to try levels 4 and 5 on your own app, start free on the hosted platform, or follow the open-source SDK install and keep everything on your machine.

Seven questions before you buy

The full request-for-proposal checklist, with eleven questions, a build-versus-buy table and a two-week pilot, is in our guide to AI QA tools.

1. Who decides pass or fail: a model or a deterministic check?
2. Run the same build twice. Do you get the same verdict?
3. Does the verdict read pixels and page text, or requests, state and console?
4. When it says pass, can you see the evidence?
5. Where does the definition of correct live, and who edits it?
6. What does re-checking a known flow cost on every commit? Price the thousandth run.
7. What happens to your tests if you stop paying?

Any QA AI vendor worth shortlisting will answer all seven without a follow-up call.

Fun fact

Goodhart's law, which every testing argument eventually quotes, is best known in words Goodhart never wrote.

His 1975 paper on UK monetary policy said "any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes". The catchy line, "when a measure becomes a target, it ceases to be a good measure", is anthropologist Marilyn Strathern's 1997 restatement, in a paper about auditing British universities. The law about measures drifting from what they measure drifted from what Goodhart said.

Conclusion

AI QA is three products sharing a name. AI that writes tests is useful when something independent checks them. AI that judges results and AI that replaces QA both make a model the oracle for its own work, which does not hold up.

The durable version is a division of labour: models explore, draft and triage, deterministic checks decide, and people own what correct means. Find your level, and take the one step that moves the verdict out of a model's hands.

FAQ

What is AI QA?

AI QA is the use of machine learning models, mostly large language models, inside software quality assurance: generating test cases, exploring an application, triaging failures or judging results. It is a set of techniques applied to QA work, not a replacement for it. How far you can trust it depends on which of those jobs the model is given.

What is the difference between AI QA and AI testing?

AI testing usually means using AI to create or run tests. AI QA is broader: it covers the whole quality process, including deciding what correct means, triaging failures, gating releases and reporting on quality. The term AI testing also often means testing AI models themselves, so ask which sense a vendor means before comparing tools.

Can AI replace QA engineers?

No. AI can draft cases, explore an app and summarise failures quickly, but it cannot decide what correct means for your product or reliably judge its own output. The role shifts from writing test cases toward owning verdicts: defining intent, choosing which checks gate a release and reviewing what the AI found.

What does an AI QA engineer do?

An AI QA engineer uses models for drafting, exploring and triage, and owns what the models cannot do. They define what correct means for each user journey, choose the deterministic checks that gate releases, review AI-drafted cases, and decide whether a failure is a product bug or a bad check. The output is verdicts, not scripts.

How do you measure AI QA?

Measure the verdicts, not the volume. Track whether the same build gets the same verdict on every run, how many real bugs reach production, how many alarms were false, which user journeys have a check that gates release, and the cost of re-checking a known flow. Counting generated tests measures activity, not quality.