For most of software's history, Testing happened near the end. Developers built, QA tested, defects were logged, fixes landed, the release went out. That model held up while releases were measured in weeks.
It holds up much less well when a team can generate a feature in an afternoon and deploy on merge. The question stopped being whether the product was tested. It is now whether quality can be engineered continuously while the product changes underneath you.
Key Takeaways
- AI raised Development throughput without raising the review and Testing capacity beside it, so the proportion of shipped code nobody examined goes up quietly.
- An AI feature can fail while appearing to work, which removes the signal every traditional suite depends on.
- Evaluating an AI system means measuring behaviour across a dataset, not asserting an output, because the same input can legitimately produce different text.
- Quality has moved in both directions: earlier into design and API contracts, and later into production observability.
AI Raised Velocity. It Did Not Raise the Risk Budget.
AI-assisted Development changed the economics of writing code. More gets produced per sprint, prototypes arrive sooner, and the bottleneck moves elsewhere. That is a genuine gain and worth having.
The problem is arithmetic. If throughput doubles and review and Testing capacity does not, the share of code that ships without anyone really looking at it rises. Nothing announces this. It shows up later, in production, as a defect class nobody recognises.
- More code per sprint against the same review capacity means a smaller proportion is actually read.
- Generated code tends to be plausible, which makes it harder to skim-review than code someone struggled to write.
- The failure is not usually a bug in one function; it is coverage quietly falling behind the surface area.
- Adding Manual Testing does not scale here, because the input rate is what changed.
An AI System Can Fail While Appearing to Work
This is the part that breaks existing suites. Traditional software gives you a signal when it fails: an exception, a wrong status code, a value you can assert against. Something is there to catch.
An LLM-backed feature can return a fluent, well-formed, confidently wrong answer. The request succeeded. The schema validated. Nothing crashed. There is no stack trace, because from the system's point of view nothing went wrong.
| Traditional application | AI-backed feature | |
|---|---|---|
| How it fails | Loudly: exception, error code, wrong value | Silently: a plausible answer that happens to be wrong |
| Reproducible? | Usually, from the same input | Often not, the same input can vary between runs |
| What you assert | An expected output | A rate measured across a dataset |
| What a green run proves | That path works | Very little on its own |
| Where defects surface | In the suite, before release | In production, reported by a user |
What Evaluating an AI Feature Actually Involves
Because the output is non-deterministic, exact-match assertions are the wrong instrument. You build a golden dataset from real inputs, pair each with what a correct response looks like, and score it repeatedly. Non-determinism makes assertions useless; it does not make quality unmeasurable.
That turns opinion into evidence. A prompt change stops being something a team argues about in review and becomes a number that moved, or did not.
- Accuracy and relevance against a reviewed dataset, tracked as a rate rather than a verdict.
- Grounding: whether an answer is supported by the retrieved document, and whether the right document was retrieved at all.
- Refusal behaviour in both directions, refusing what it should and not refusing what it should not.
- Prompt robustness, because a small rewording should not change the answer's substance.
- Tool selection, planning and recovery for anything agentic, judged on the steps taken, not only the final output.
Automation That Adapts Instead of Breaking
Conventional Automation follows fixed steps, and that remains valuable. What it is not is cheap to keep alive. One redesign invalidates dozens of selectors, and maintenance quietly consumes the capacity the suite was bought to free up.
The useful application of AI here is unglamorous: proposing test candidates, repairing locators after a UI change, clustering failures so a person reads one root cause rather than forty reports.
- The goal is not more Automation. It is Automation that survives a redesign.
- AI proposes; an Engineer decides. A generated test nobody reviewed is coverage theatre.
- Flake is a defect class with a root cause, never something to bury under a retry count.
- Time saved on maintenance should be spent on the risks a script was never going to find.
Quality Moved Left, and Also Right
Shifting left is well understood by now: testability considered at design, acceptance criteria agreed before implementation, API contracts validated independently of the UI, Automation gating every merge.
The half that gets less attention is what happens after release. Production behaviour, incidents and real usage are the only evidence of how the product actually behaves for people who did not write it. Quality is not left or right. It is continuous.
The QA Role Is Becoming a Quality Engineering Role
The remit has widened. A quality Engineer now works across Automation, APIs, CI/CD, cloud environments, accessibility, security awareness, data validation and increasingly the evaluation of systems that do not behave deterministically.
That does not mean everyone becomes an expert in everything. It means the central question changed, from what should I test to what could go wrong, how would we detect it, and how do we reduce that risk.
- From writing test cases to designing how a system reports its own failures.
- From counting coverage to arguing about which risks are worth covering.
- From owning a phase to owning a property of the product.
Five Things Worth Doing This Quarter
None of this has to happen at once, and none of it needs a reorganisation. Each is a question a team can answer this quarter with what it already has.
- Compare what reaches production per sprint now against a year ago, and ask honestly how much of it was examined.
- Treat every AI feature as its own Testing problem with written evaluation criteria, agreed before release rather than after an incident.
- Audit where Automation time actually goes. If most of it is repair, the framework is the problem, not the team.
- Move quality checks into CI/CD so they run continuously, instead of starting a few days before a release date.
- Pair test results with production signals. A green suite and an unhappy user are not a contradiction; they are a measurement gap.
None of this requires building every capability in-house on day one. We work with product teams across Automation, AI Quality Engineering, API and database Testing, accessibility and CI/CD, and the shape of the engagement follows what the product actually needs.
Quality is not the gate you pass before shipping. It is what makes shipping repeatable. Tell us what you are building and we will tell you where we would look first.
Want us to run this on your product?
A free 30-minute assessment. We'll tell you what's working, what's costing you time, and where to start. Findings delivered within days.
Get a Free QA Assessment