Quality at the Speed of AI: How QA is Keeping Up and Getting Smarter

Why does QA need to change when AI writes code faster?

AI is writing code faster than ever. That is a good thing for delivery. But it creates a question that does not get asked often enough: if the code is coming faster, how does quality keep up?

As QA Team Lead, that is a challenge I have had to get ahead of. More code in less time means more surface area to test, more edge cases to explore, and more risk to manage, with the same number of hours in the working week.

If QA simply runs at the same pace it always has, we become the bottleneck. The pipeline backs up. Release confidence drops. The time saved in development gets lost in testing.

The good news is that AI is not just the source of the pressure. It is also the solution to it. Here is how we are using it.

How can AI write test cases and automation?

Every user story needs test cases. Writing them, structuring them, and getting them into a test management tool has always been one of the more time-consuming parts of QA. It is work that has to happen before any meaningful testing can even begin.

Now, we take the acceptance criteria and feed them straight into our preferred AI tool, currently Claude. The output is not perfect, but it is a solid starting point. It covers the expected behaviour, explores edge cases, and often highlights scenarios that would otherwise take time to think through.

We do not take it as-is. We review it, challenge it, and refine it based on how the system actually works and what matters most for the client. Once it is in a good place, Claude formats everything into the CSV structure that our test management tool expects and imports the full set in one go.

What used to be a manual, front-loaded task becomes a quick iteration. Less time preparing. More time testing.

It carries through into automation as well. Instead of building tests from scratch after development, AI can generate a first pass using both the acceptance criteria and the codebase. Because both come from the same source, they stay aligned by default. The result is faster coverage, more consistency, and tests that stay closely tied to what was actually agreed.

For the step-by-step version, see how to generate test cases from acceptance criteria with AI.

How do you write better bug reports with AI?

A well-written bug report is not quick. Clear reproduction steps, precise expected and actual behaviour, and enough context for a developer to act without back-and-forth all take time. When you are logging multiple bugs in a day, that effort adds up.

We have tackled this by creating a dedicated skill in Claude that knows our exact bug ticket format and has access to the source code. That combination matters. Because it understands the system, I can give it a minimal amount of context, a description of what went wrong and what I expected to see, and it fills in the rest. The result is a detailed, well-structured ticket that is ready to log.

But the real value comes from what it does beyond writing the report. With access to the codebase, Claude can troubleshoot the issue, reason about where the problem likely originates, and suggest what the fix might look like. That analysis goes straight into the ticket, so developers are not starting from scratch when they pick it up.

The whole cycle speeds up. Faster to log, faster to understand, faster to fix.

Read more about building a Claude skill for codebase-aware bug reports.

How does AI support release risk analysis?

Not all releases to production are equal. Some touch core infrastructure. Some affect critical user journeys. Some change a single low-risk configuration value. The mistake is treating them the same.

We can see what is in a release from Jira, but tickets describe intent, not always reality. Running AI directly against the code and release branches gives us something more reliable: an accurate picture of what has actually changed, how significant those changes are, and where the risk is concentrated. That analysis shapes where we focus our testing effort.

Rather than spreading testing time evenly across everything, we can concentrate on the areas of highest risk and move faster through the areas that need less scrutiny. It is not about cutting corners. It is about making informed decisions about where human attention is most needed.

Read more about AI release risk analysis.

AI acceptance-criteria checks in the pipeline

Even in high-performing development teams, requirements can sometimes get missed and obvious issues slip through. It is not a reflection of quality or care. It is just the reality of complex software and tight deadlines. QA picking up the occasional miss is a normal and expected part of the process.

But every time that happens, time gets spent on both sides. Raising it, fixing it, retesting it. That is time that is not being spent on the testing that genuinely requires expertise.

We have addressed this by building AI into our CI/CD (continuous integration and continuous delivery) pipeline. Before a piece of work reaches QA, an automated check runs that reads the acceptance criteria and evaluates whether the code meets them. It does not catch everything, and it is not designed to. But it catches the obvious misses.

When work arrives in testing, the basic acceptance criteria have already been validated. I am not writing defects about missing functionality that was clearly specified. I am testing the things that require judgement: edge cases, user experience, performance under load, and interactions between features. That is the work that actually needs a QA engineer. It is also why we never let AI ship code unsupervised.

Read more about checking code against acceptance criteria in CI/CD with AI.

What does AI-augmented QA mean for clients?

Quality assurance has always been about confidence. It gives clients the confidence to release software, and gives end users the confidence to rely on it. That has not changed.

What has changed is the toolkit available to build that confidence, and the pace at which we need to build it.

AI does not replace the QA function. It does not replace the expertise required to understand what a system is supposed to do, anticipate how it might fail, and make a considered judgement about whether it is ready to release. Those things still require a person.

What AI does is take the heavy, repetitive, time-consuming parts of QA, such as writing test cases, automation scripts, and bug reports, and handle them faster and more consistently than any manual process can. It gives QA engineers time back, and that time is what allows us to keep pace with the speed at which AI is helping developers build.

As AI continues to accelerate development, the teams who will deliver the best quality outcomes are the ones who use AI just as deliberately on the testing side as on the build side. At Talk Think Do, that’s what we’re doing, and our clients get software they can rely on as a result.

Interested in how we approach quality and delivery? Get in touch with the Talk Think Do team.

We’ve also written about using AI to validate requirements before engineering begins, covering how AI is reshaping the front end of the delivery process too.