Last Updated on 28. August 2026
For months, I’ve been traveling as a speaker to conferences, both national and international. Hardly a keynote, a tool, or a product comes without the label AI-powered, Agentic, or Autonomous anymore. Artificial intelligence no longer seems to be just a tool, it seems to have become an end in itself. Anyone who doesn’t talk about AI today is quickly seen as behind the times.
But a different question is on my mind: Are we still talking about software engineering, or only about AI?
The New Reality: Suddenly Everything Is “Agentic”
I keep hearing success stories that go something like this: The AI reads all the tickets, generates automated tests from them, self-heals failing tests, reviews the code, plans the next tasks, and in the end everything is green. Developers are relieved of work, QA is no longer needed, everything just works. The audience applauds.
I sit there and wonder: What does this system actually cost? How many million tokens does it consume every day? How does the business model hold up as LLM prices rise? What strategies exist for token optimization? What architectural decisions were made? How resilient is this system, how sustainable is it? Hardly anyone talks about that.
Speed Is No Substitute for Quality
Agentic coding makes something impressive possible today: a working prototype emerges within a few hours. That’s fascinating. But this is exactly where the problem begins: A prototype is not a product.
Many demos at conferences show impressive workflows. But they don’t answer the questions that make software successful in the long run: Is the solution maintainable, scalable, traceable, testable, economically viable, operable in the long term? Software quality doesn’t come from generating code quickly. It comes from thousands of small engineering decisions.
False Confidence Is the New Technical Debt
I’m especially critical of the growing automation of test generation and self-healing. On slides, it looks great: “The AI detects the failure and repairs the test automatically.” My first reaction is: How do we know the test still checks the same thing?
Did the healer merely adjust the locator, or was the expected business logic silently changed? Did the assertion change? Did a critical test quietly turn into a test that always passes? Who checks that? Who visualizes which requirements are actually still covered by tests? Who notices when test coverage degrades? Who prevents a creeping erosion of quality?
A green build doesn’t automatically mean a good product. All it means, at first, is that all existing tests passed. Whether those tests still check the right things is an entirely different question.
The Code Becomes a Black Box
Just a few years ago, developers could explain their own code. Today, I increasingly hear statements like: “Copilot generated that code.” “Claude wrote that.” “The agent handled the refactoring.” “The AI is supposed to fix the bug.”
The consequence: humans gradually lose their understanding of their own system. Code reviews become harder because thousands of lines are suddenly created at once. Refactorings grow larger, complexity grows faster. When a bug shows up afterward, no one really knows anymore where to even start looking.
We’re handing more and more responsibility to AI. But the responsibility toward our customers stays with us.
Architecture Decides Long Before the First Test Is Written
An architectural decision is often unremarkable. At one point, you turn left instead of right, and the consequences show up months later. Then extensive refactorings begin, new agents get spun up, even more code is generated, even more tokens are consumed, even more complexity builds up. Speed is not a quality trait. It can even be the most expensive detour.
“Where Do We Need to Build in Quality?”
Over the past few months, I’ve been getting a new kind of request. They go something like this: “We’ve built an agentic software system. Can you tell us where in the code we need to integrate quality checks?”
This question reveals a fundamental misunderstanding. Quality doesn’t come from specific spots in the code, and it doesn’t come from a few extra checks. Quality is built throughout the entire software development lifecycle: from the first idea through requirements, architecture, design, implementation, reviews, and tests, all the way to monitoring, operations, and continuous improvement. There’s no single quality switch.
No Requirements. No Tickets. No Problem?
Even more unsettling are conversations like this:
“Do you have requirements?” — “No.” “User stories?” — “No.” “Tickets?” — “No.” “Why not?” — “That would be a bottleneck.” “What do you use instead?” — “The AI generates specifications.” “How do you validate those?” — “…”
Or: “We don’t really need QA anymore, either.” — “Why not?” — “The AI generates the tests too, after all.”
Then I ask: What are you actually testing against? What’s the target state? What user problems are you trying to solve? What critical user journeys exist? What risks need to be minimized? What quality goals are you pursuing? What usually follows is silence.
Lots of Tests Are Not a Test Strategy
Another pattern I run into regularly: “We have an incredible number of test cases.” My follow-up question is: Which requirements do they cover? “We don’t know.” How high is the test coverage? “No idea.” What risks are covered? “Not defined.” What error classes are addressed? “Unknown.”
The number of test cases is not a quality metric, just as thousands of lines of generated code are not proof of quality.
Engineering Can’t Be Compressed Into a Prompt
Requests like this make me especially thoughtful: “Can you generate the knowledge from ISTQB®, IREB®, and iSAQB® as skills so our agentic system automatically produces quality?”
I often can’t help but smile at that. Not because the idea is bad, but because it shows how engineering is sometimes perceived. Requirements engineering, software architecture, quality engineering, testing: these aren’t checklists, prompts, or individual skills. They’re disciplines that have developed over decades. They consist of experience, trade-offs, conflicts, communication, domain knowledge, risk analysis, and context. There’s rarely a single right decision; usually there are many possible ones. And that’s exactly what engineering is.
Where Do We Need to Build in Quality?
Whether it’s classic software or AI-based systems: the fundamental quality principles don’t change. The quality characteristics defined in ISO/IEC 25010 still apply. When AI is part of the system, additional quality aspects come into play, for example around transparency, controllability, robustness, or the ability to intervene, as described in ISO/IEC 25059. AI doesn’t replace these requirements. It extends them.
AI Should Support Us, Not Replace Us
I consider artificial intelligence one of the greatest technological developments of our time. I use it every day: it boosts my productivity, it helps me write, research, analyze, structure, question, and learn. That’s exactly where its strength lies, not in blindly replacing engineering.
I want an AI that reviews my work, suggests improvements, spots risks, points out alternatives, finds inconsistencies, flags missing requirements, critically questions my tests, visualizes coverage, makes architectural decisions transparent, and helps me make better decisions. Not an AI that makes decisions for me without my understanding their consequences.
Conclusion: The Responsibility for Software Quality Stays With Humans
The current AI hype threatens to overshadow the actual core of software engineering. Engineering was never about writing code. Engineering means responsibly solving complex problems under uncertainty. That responsibility stays with humans.
AI is an extraordinarily powerful assistant in this. But it’s no substitute for critical thinking, architectural expertise, requirements engineering, quality engineering, or professional testing. Maybe we should start asking a simple question again more often at conferences. Not: “What can your AI do?” But rather: “How does your system demonstrably produce quality?” Because in the end, it’s not the AI that gets held accountable for the product. It’s always the person who built it, approved it, and shipped it.
Are you also working on quality engineering in the age of agentic systems? Lilia Gargouri would love to connect.
