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

For months, I have been traveling as a speaker to national and international conferences. Hardly a keynote, tool, or product is presented today without labels such as AI-powered, Agentic, or Autonomous. It almost feels as though artificial intelligence is no longer just a tool, but has become an end in itself. If you’re not talking about AI today, you’re quickly perceived as being behind the curve.

Yet one question keeps occupying my mind: Are we still talking about Software Engineering—or are we only talking about AI?

The New Reality: Everything Is Suddenly “Agentic”

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, and how sustainable is it?

Hardly anyone talks about these questions.

Speed Does Not Replace Quality

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, scalable, understandable, and 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.

False Confidence Is the New Technical Debt

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, visualizes which requirements are actually covered by the generated tests, and 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.

Code Is Becoming a Black Box

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,” or “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, and 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.

Architecture Makes Decisions Long Before the First Test Is Written

Architectural decisions often seem insignificant. At one point, you make a subtle decision to turn left instead of right, and 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, and more complexity is introduced.

Speed is not a quality attribute. In fact, it can become the most expensive detour.

“Where Should We Add Quality?”

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, nor is it created by adding a few additional checks. Quality is built throughout the entire Software Development Lifecycle, from the initial idea and requirements through architecture, design, implementation, reviews, testing, monitoring, and operations to continuous improvement.

There is no single quality switch.

No Requirements. No Tickets. No Problem?

Even more concerning are conversations where the absence of requirements, user stories, and tickets is presented as a benefit rather than a problem. When I ask why they don’t have them, the answer is often that they would become a bottleneck. Instead, the AI generates the specifications. But when I ask how those specifications are validated, the conversation usually comes to a halt.

I hear similar arguments when it comes to QA: “We don’t really need QA anymore 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, and what quality objectives are you pursuing?

The answer is often silence.

A Large Number of Tests Is Not a Test Strategy

Another recurring pattern is the claim that a system has an enormous number of test cases. But when I ask which requirements they cover, the answer is often that nobody knows. Ask about test coverage, and there’s no clear answer. 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.

Engineering Cannot Be Compressed into a Prompt

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, and Testing are not checklists, prompts, or individual skills. They are disciplines that have evolved over decades and are built on experience, judgment, conflicting constraints, trade-offs, communication, domain knowledge, risk analysis, and context.

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

Quality Remains Quality

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, functional adaptability, robustness, or Intervenability—as described in ISO/IEC 25059.

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

AI Should Support Us—Not Replace Us

I consider artificial intelligence one of the most significant technological developments of our time. I use it every day. It makes me more productive and helps me write, research, analyze, structure ideas, challenge my thinking, and 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.

Conclusion

The current AI hype risks overshadowing the very essence of Software Engineering. Engineering has never been about writing code; it 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.