Between AI Euphoria and Quality Engineering: Why We Are in Danger of Unlearning Software Quality

I keep hearing success stories that all sound remarkably similar:

The AI reads all the tickets, generates automated tests, heals failing tests, reviews the code, plans the next tasks, and in the end everything is green. Developers are relieved. QA is no longer needed. Everything just works.

The audience applauds.

Meanwhile, I find myself asking very different questions:

• What does this system actually cost?
• How many millions of tokens does it consume every day?
• What happens to the business model when LLM prices increase?
• Which token optimization strategies are in place?
• What architectural decisions have been made?
• How resilient is this system?
• How sustainable is it?

Hardly anyone talks about these questions.

Agentic coding enables something truly impressive today:

A working prototype can be created within just a few hours.

That is fascinating.

But that is also exactly where the problem begins.

A prototype is not a product.

Many conference demos showcase impressive workflows. However, they rarely answer the questions that determine whether software will succeed in the long run:

• Is the solution maintainable?
• Is it scalable?
• Is it understandable?
• Is it testable?
• Is it economically viable?
• Can it be operated sustainably over time?

Software quality is not achieved by generating code quickly.

It is the result of thousands of small engineering decisions.

One area that concerns me in particular is the growing automation of test generation and self-healing.

On presentation slides, it always looks impressive:
“The AI detects the failure and automatically repairs the test.”

My first reaction is always the same:
How do we know that the test is still verifying the same behavior?
Did the self-healing mechanism simply update a locator?
Or did it silently change the expected business behavior?
Was the assertion modified?
Did a critical test quietly turn into a test that always passes?
Who reviews those changes?
Who visualizes which requirements are actually covered by the generated tests?
Who notices when test coverage deteriorates?
Who prevents the gradual erosion of quality?

A green build does not automatically mean you have a good product.
It only means one thing:
The existing tests passed.

Whether those tests are still validating the right things is an entirely different question.

Only a few years ago, developers were able to explain the code they had written.

Today, I increasingly hear statements like:
“Copilot generated that code.”
“Claude wrote that.”
“The agent handled the refactoring.”
“We’ll let the AI fix the bug.”
The consequence?

People gradually lose their understanding of their own systems.
Code reviews become increasingly difficult because thousands of lines of code appear all at once.
Refactorings become larger.
Complexity grows faster.

When defects eventually occur, nobody really knows where to begin investigating.

We are handing over more and more responsibility to AI.
Yet the responsibility toward our customers remains entirely ours.

Architectural decisions often seem insignificant.
At one point, you make a subtle decision to turn left instead of right.
The consequences may not become visible until months later.
Then the large-scale refactoring begins.

New agents are launched.
More code is generated.
More tokens are consumed.
More complexity is introduced.
Speed is not a quality attribute.

In fact, it can become the most expensive detour.

Over the past few months, I have been receiving a new kind of request.

It usually sounds something like this:
“We have built an agentic software system. Could you tell us where we should add quality checks into the code?”

This question reveals a fundamental misunderstanding.
Quality does not emerge at specific points in the code.
Quality is not created by adding a few additional checks.
Quality is built throughout the entire Software Development Lifecycle.
From the initial idea.
Requirements.
Architecture.
Design.
Implementation.
Reviews.
Testing.
Monitoring.
Operations.
Continuous improvement.

There is no single quality switch.

Even more concerning are conversations like these:
“Do you have requirements?”
“No.”
“User stories?”
“No.”
“Tickets?”
“No.”
“Why?”
“They would become a bottleneck.”
“What do you use instead?”
“The AI generates the specifications.”
“How do you validate them?”
“… ”

Or:
“We don’t really need QA anymore.”
“Why?”
“Because the AI generates the tests.”

At that point, I ask:
What exactly are you testing against?
What is the expected outcome?
Which user problems are you trying to solve?
Which user journeys are business-critical?
Which risks need to be mitigated?
What quality objectives are you pursuing?

The answer is often silence.

Another recurring pattern sounds like this:
“We have an enormous number of test cases.”
My response is simple:
Which requirements do they cover?
“We don’t know.”
What is your test coverage?
“No idea.”
Which risks are covered?
“Not defined.”
Which defect classes are being addressed?
“Unknown.”

The number of test cases is not a quality metric.
Just as thousands of lines of AI-generated code are not proof of quality.

One type of request always makes me smile:
“Could you generate the knowledge from ISTQB®, IREB®, and iSAQB® as skills so that our agentic system can automatically build quality?”

Not because it is a bad idea.
But because it reveals how engineering is sometimes perceived.
Requirements Engineering.
Software Architecture.
Quality Engineering.
Testing.

These are not checklists.
They are not prompts.
They are not individual skills.
They are disciplines that have evolved over decades.
They are built on experience.
Judgment.
Conflicting constraints.
Trade-offs.
Communication.
Domain knowledge.
Risk analysis.
Context.

There is rarely one single correct decision.
Most situations offer multiple possible solutions.
And that is exactly what engineering is about.

Whether we are building conventional software or AI-based systems, the fundamental principles of software quality do not change.

The quality characteristics defined in ISO/IEC 25010 remain fully applicable.
If AI becomes part of the system, additional quality characteristics must also be considered—for example, transparency, explainability, robustness, or fairness—as described in ISO/IEC 25059.

AI does not replace these quality requirements.
It extends them.

I consider artificial intelligence one of the most significant technological developments of our time.

I use it every day.
It makes me more productive.
It helps me write.
Research.
Analyze.
Structure ideas.
Challenge my thinking.
Learn.

That is exactly where its strength lies.
Not in blindly replacing engineering.

I want AI that:

• reviews my work,
• suggests improvements,
• identifies risks,
• proposes alternatives,
• detects inconsistencies,
• highlights missing requirements,
• challenges my tests,
• visualizes coverage,
• makes architectural decisions transparent,
• and helps me make better decisions.

Not AI that makes decisions on my behalf without me understanding their consequences.

The current AI hype risks overshadowing the very essence of Software Engineering.

Engineering has never been about writing code.
Engineering is about solving complex problems responsibly under uncertainty.

That responsibility remains with people.
AI is an extraordinarily powerful assistant.
But it is not a substitute for critical thinking, architectural competence, Requirements Engineering, Quality Engineering, or professional testing.

Perhaps we should start asking a different question at conferences.
Instead of asking:”What can your AI do?”
We should ask:
“How is quality demonstrably built into your system?”

Because in the end, it is never the AI that is held accountable for the product.
It is always the people who designed it, approved it, and delivered it.