A few years ago, generating working code in minutes would have sounded unrealistic.
Today, a developer can explain what they want, use an AI coding assistant to generate an implementation, create unit tests, fix errors and get a pull request ready surprisingly quickly.
That is impressive, and I think we should acknowledge that.
But from a Quality Engineering point of view, I am more interested in what happens next.
How do we know the software is actually right?
Not whether the build passed.
Not whether the unit tests are green.
Not whether the AI says it is confident.
How do we know we have enough evidence to trust the change?
For me, that is becoming one of the more interesting questions in QA.
The bottleneck may be moving
Software teams have spent years trying to improve delivery speed.
We moved to Agile ways of working, introduced CI/CD, invested heavily in automation, adopted cloud platforms and improved developer tooling.
Now AI is accelerating development again.
Developers can generate code, documentation, tests, refactoring suggestions and even fixes much faster than before.
That is a real productivity gain.
But it also creates a new challenge.
If the amount of software being produced increases significantly, the amount of change that needs to be understood and validated increases with it.
The QA team does not suddenly get three times more capacity.
Neither does the product team.
Neither do security teams, architects or the people making release decisions.
So I don't think the answer can simply be, “QA also needs to test faster.”
At some point, we have to rethink what good QA looks like when development itself becomes much faster.
More tests do not automatically create more confidence
The obvious response is to use AI in testing as well.
I think we absolutely should.
AI can help identify test scenarios, generate test data, suggest automation, analyse failures, review requirements and summarise defects.
There is huge potential there.
But I would be careful about assuming that more AI-generated testing automatically means better quality.
Think about this situation.
AI helps generate the application code.
The same or another AI generates the tests.
The tests pass.
AI then analyses the results and tells us everything looks good.
It sounds efficient.
But what happens if the code and the tests both misunderstood the requirement in exactly the same way?
That is the part we cannot ignore.
A test proves that something behaved according to an expectation.
It does not automatically prove that the expectation was correct in the first place.
That problem is not new. We have had it in software testing for years.
AI just makes it possible to make the same mistake much faster.
A green test suite is evidence, not proof
Most experienced testers have seen this happen.
Regression is green.
API tests are green.
Performance looks fine.
Deployment succeeds.
Then a real user finds something that nobody expected.
That doesn't necessarily mean the testing was poor.
It means software quality is bigger than test execution.
A passing regression suite tells us something useful. It tells us that the behaviours covered by those tests worked as expected under those test conditions.
But it does not automatically tell us whether:
we tested the biggest business risk
the requirement itself was understood correctly
our test data was realistic enough
an unusual customer journey was missed
an integration behaves differently under real conditions
the change introduced a risk nobody had considered
the tests themselves were based on a wrong assumption
This is why I don't think the future of QA is simply about achieving a higher automation percentage.
For me, the more useful question is:
How much reliable evidence do we have about the risk of this change?
That is a very different conversation.
QA should focus more on risk and evidence
A lot of traditional QA reporting is still based around questions such as:
How many test cases have we executed?
What percentage passed?
How much regression is automated?
How many defects are still open?
Those measures are useful, but they can also create a false sense of certainty.
Two hundred passing tests around a low-risk area may tell us less than five well-designed tests around a critical business workflow.
So instead of applying the same testing process to every change, I think we need to become better at asking:
What could actually go wrong here, and what evidence would make us comfortable releasing it?
A small cosmetic change obviously does not need the same level of assurance as a change affecting payments, identity, pricing, financial calculations, customer data or a critical integration.
That sounds obvious when written down.
In practice, though, QA processes sometimes treat changes surprisingly similarly.
Risk-based testing becomes much more important when the volume of change increases.
The aim should not be to test everything equally.
The aim should be to test the right things deeply enough.
AI can help us think earlier
One area where I personally see a lot of value is using AI before test execution starts.
Give an AI system a requirement or user story and it can quickly suggest:
boundary conditions
negative scenarios
unusual data combinations
integration risks
unclear acceptance criteria
missing scenarios
potential regression areas
That can be extremely useful.
It can give a tester a starting point in seconds.
But generating fifty test scenarios is not really the impressive part.
The important part is knowing which of those fifty actually matter.
Which scenario could create a serious customer impact?
Which one carries financial risk?
Which one could break a critical downstream process?
Which one looks unlikely but would be very expensive if it happened?
That still requires context and judgement.
You need to understand the business process, the architecture, the data, the integrations and how people actually use the system.
That is where experienced QA professionals continue to add real value.
Exploratory testing becomes more important, not less
There is also an interesting effect when more predictable testing becomes automated.
Human testers get more opportunity to spend time on uncertainty.
That is where exploratory testing becomes powerful.
Automation is excellent at answering:
“Does the thing we already know to check still work?”
A good tester is often trying to answer a different question:
“What have we not thought about?”
What assumption did we make without realising it?
What happens if the user does things in the wrong order?
What if data is missing?
What if an integration is slow?
What if the user leaves halfway through the workflow and comes back later?
What if technically valid input produces a strange business outcome?
AI can suggest many of these scenarios too, and that will continue to improve.
But there is still real value in someone looking at the product with curiosity rather than simply following a predefined test script.
I don't see that disappearing.
Be careful with confidence scores
Another area I think we need to be careful with is AI-generated confidence.
You may see a system say something like:
Confidence: 94%
It looks scientific.
But I would immediately ask: 94% based on what?
Test coverage?
Requirement coverage?
Historical defect data?
Code change analysis?
Model confidence?
Production behaviour?
Something else?
If we cannot explain where the number comes from, it does not really tell us very much.
I like the idea of confidence scoring in AI-assisted QA, but only when the score is connected to evidence that people can understand.
If an AI recommends more testing, identifies a risky scenario or suggests that a release is safe, we should be able to understand why.
And people should be able to challenge it.
Otherwise we risk replacing old vanity metrics with new AI-generated ones.
Human-in-the-loop still matters
There is a view that human approval is just a temporary stage until AI becomes good enough to make decisions on its own.
For some low-risk activities, maybe that will happen.
But I don't think every important engineering decision should automatically move in that direction.
Human oversight is not there because humans are perfect.
We are not.
It is there because accountability, context and business impact matter.
AI can analyse.
Automation can validate.
Monitoring can provide production signals.
But when the change is important, someone still needs to decide whether the remaining risk is acceptable.
That decision depends on much more than a model response.
It may depend on business timing, customer impact, operational readiness, known limitations or the organisation's appetite for risk at that particular moment.
That is why I think human-in-the-loop will remain relevant in Quality Engineering for a long time.
QA should not become the department that says no to AI
There is another side to this as well.
QA should not respond to AI adoption by becoming the AI police.
That would be a mistake.
AI-assisted development is not going away, and trying to stop teams using useful productivity tools is not a sensible quality strategy.
I think QA has a much more useful role to play.
Ask better questions.
How was the change generated?
How was it reviewed?
What assumptions were made?
What automated feedback exists?
Which part of the change carries the most risk?
What happens if our assumption is wrong?
What evidence do we have beyond “the tests passed”?
That is constructive quality engineering.
We should not blindly trust AI.
But we should not be frightened of it either.
The QA role will change
I don't believe AI means we no longer need QA professionals.
But I do believe some QA activities will become less valuable.
If AI can generate basic test scenarios in seconds, spending hours manually documenting obvious happy-path tests makes less sense.
If AI can assist with automation generation, simply knowing how to write automation scripts will not differentiate someone as much as it once did.
If pipelines can continuously execute thousands of predictable checks, manually running the same regression repeatedly becomes difficult to justify.
The value starts moving towards different skills.
Understanding risk.
Understanding architecture.
Challenging requirements.
Thinking about testability.
Understanding integrations and data.
Finding gaps.
Recognising weak evidence.
Knowing where automation makes sense and where investigation is still required.
And helping the team answer one important question:
Do we have enough evidence to trust this change?
My view
I am very positive about where AI can take software engineering and Quality Engineering.
It can remove repetitive work.
It can help us find scenarios faster.
It can make automation easier.
It can analyse information that would take a human much longer to process.
We should use those capabilities.
But faster development does not remove the responsibility to understand what we are releasing.
If anything, when software change becomes faster and easier to create, understanding risk becomes even more important.
So I don't think the future QA practice should be measured mainly by the number of tests executed or the percentage of automation achieved.
A stronger measure is whether QA helps the team make better decisions about quality and risk.
AI can help write the code.
AI can help generate the tests.
AI can help analyse the results.
But somebody still has to ask whether we tested the right thing.
For me, that is where Quality Engineering becomes even more relevant in an AI-driven world.