approx. 10 min. reading time

Quality Impact Logo

Faster, bigger, smarter! But is it better?

Written by Prof. Dr.-Ing. Ina Schieferdecker /

 May 2026

Prof. Dr. Ina Schieferdecker

Table of Contents:

AI is picking up speed – but who takes responsibility?

Generative and agent-based AI systems have triggered a historic leap in productivity in software development: Code, tests, architecture proposals, and refactorings are now generated in minutes instead of days or weeks. But this gain in speed comes at a price: We are producing software in unprecedented quantities—without being sure whether we truly have its quality, security, and long-term maintainability under control [1].

Furthermore, AI-assisted coding is often integrated into existing, frequently fragile landscapes. In such legacy environments, every new “quick” solution can not only perpetuate existing technical debt but even multiply its complexity.

The central question is therefore no longer whether we can become faster with AI, but whether we can afford to make bad decisions at this speed [2].

Prof. Dr. Ina Schieferdecker

Prof. Dr.-Ing. Ina Schieferdecker

Prof. Dr.-Ing. Ina Schieferdecker, an honorary professor at TU Berlin, previously served as head of the BMBF’s Department of Technological Sovereignty, director of Fraunhofer FOKUS, and director of the Weizenbaum Institute.

Published: 05.2026

Technical Debt on AI Turbo – Innovation on Credit

For decades, the concept of technical debt has described the conflict between rapid delivery and sustainable quality: We make compromises in design, testing, or architectural decisions to gain “time to market”—and later pay the price in the form of bugs, maintenance costs, and barriers to innovation. Generative AI [EW1.1]aggravate this dynamic because it can boost productivity in the short term but generate additional, hard-to-see debt in the long term: undocumented solutions, design decisions that are difficult to trace, and opaque dependencies [3].

Technical debt has always been the price of speed: conscious or unconscious shortcuts in architecture, design, and testing that must later be “repaid” as maintenance costs, [EW2.1] delays, failures and/or outages. With generative and agent-based AI, this dynamic does not merely shift – it accelerates. Studies and case reports paint a consistent picture: GenAI increases development productivity but allows technical debt to grow faster and more diffusely,[EW3.1][IS3.2] especially in grown legacy system landscapes.

An analysis in the MIT Sloan Management Review [2] concludes that while AI coding tools can boost productivity by up to about 50%, they simultaneously create dangerous technical debt—especially when AI-generated code is deployed in legacy environments and taken over by less experienced developers. The result is nested dependencies, duplicates, hard-to-trace workarounds, and architectures that work in the short term but are difficult to scale or maintain securely in the long term.
Recent studies on “GenAI-Induced Self-admitted Technical Debt” [4] also show that the structure of technical debt is shifting: while design debt remains present, requirements and test debt are increasing in particular because AI-generated code is adopted without sufficient understanding on the part of developers, and quality assurance is systematically postponed. Surveys of developers confirm this trend: A large majority report negative impacts of AI on technical debt and a growing effort required to subsequently correct or rewrite generated code [2][5].

At the same time, industry analysts warn that rapid, uncontrolled AI adoption is giving rise to a new form of “AI debt” [5]: Anyone scaling GenAI and agent-based systems without considering governance, maintainability, and evaluation mechanisms risks falling into a vicious cycle of upgrades and operations, in which every new AI feature generates additional debt and operational risks. In other words: AI not only accelerates feature delivery, it also accelerates the compounding of our technical debt – especially where software quality and testing do not consistently keep pace.

This is precisely the crux of point of this article: If technical debt grows structurally faster in the AI era, software quality becomes the critical counterforce – and testing becomes the central strategy for keeping this debt tsunami manageable at all. This ties directly into the argumentation in the subsequent sections on quality as a key resource and on how to rethink testing.

Code in Schlüsselform

Why Software Quality Is the Underrated Key Resource

The public debate is often dominated by the question of what AI can do—rather than what it should be allowed to do and what we, as a society and as organizations, want to rely on. In these debates, software quality is often treated as a “minor detail,” a technical component relegated to the background beneath the grand narratives of transformation. In actual fact, however, it is quality that determines whether software systems deserve trust: Are they robust against unexpected inputs, transparent in their behaviour, secure in their handling of data, and maintainable in the long term? [6]

With the shift of business processes, decision-making logic, and critical infrastructure to AI-supported and/or AI-generated systems, software quality becomes a core resource of digital sovereignty: Those who master quality can scale innovation in a controlled manner, consciously manage risks, and proactively address regulatory requirements. Those who ignore quality are dependent on short-term efficiency gains – and later pay the price with a loss of trust, security incidents, and a stagnation of innovation [7].

Rethinking Testing: From Control Tool to Creative Force

Traditional software testing is based on a seemingly simple idea: we know the requirements, we define the expected results, and we check whether the system behaves as intended – often assuming deterministic system behavior. Even though this assumption is not necessary and already fails in open, distributed, parallel, and/or real-time systems, it breaks down particularly in generative and agent-based AI systems: Their responses are probabilistic, outputs vary despite identical inputs, and systems develop emergent behaviour in multi-agent settings [8]. This requires new testing dimensions: instead of individual “correct” software reactions, properties such as robustness, consistency, potential for harm, alignment with guidelines, or resistance to prompt injection must be systematically evaluated. Test oracles thus become less “yes/no” instances in the evaluation of (dynamic) software reactions and more multi-layered evaluation mechanisms that combine statistical methods, property-based testing, and AI-supported evaluation. The arbitration concept in the UML Testing Profile had already outlined how this can be done [9].

At the same time, it is becoming clear that organizations are already prioritizing testing as a key tool for ensuring the quality of AI-powered software: Surveys of large companies show that expanded testing and validation protocols are among the most important measures for addressing quality risks in GenAI development [10]. Testing is thus shifting from mere bug detection to a strategic governance function: It defines which forms of behaviour are acceptable – technically, ethically, and regulatorily [10].

Humans and Machines in Testing: Collaboration Instead of Replacement

Another important point is coming into focus: It is often claimed that AI will largely automate testing and render human testers obsolete. The reality is more complex: AI can accelerate repetitive tasks, generate test cases, analyse code, and detect anomalies – but it does not take responsibility for what we define as “high quality” and “socially acceptable.”

Even though test agents assist with testing tasks, testers still grapple with issues such as scalability, alignment, misinformation, and integration efforts. AI-assisted quality assurance therefore requires human expertise to define testing objectives, prioritize risks, interpret results, and establish the framework for what we consider trustworthy. In this co-production, testing is becoming the “intelligence layer” between AI-generated code and real-world impact: it filters, corrects, and limits – and precisely through this, enables bolder innovation [8].

A Plea: Innovation Only with Quality Engineering – and Strong Software Testing

The AI era is not a free pass to ignore technical debt and postpone quality issues. On the contrary: the more we allow generative and agentic systems into critical areas, the more expensive quality deficits become, the more severe the impact of technical debt, and the harder the loss of trust hits us. [2][11]

If we continue to treat software quality and testing as secondary, they will remain “the underestimated key resource” of our time: important, but underfunded, misunderstood, and brought in too late. If, on the other hand, we view them as a strategic lever, they become a central enabler – they make the difference between fleeting hype and sustainable digital transformation.

That is why now is the right time to talk about software excellence amid the AI hype – and to rethink testing: not as a hindrance, but as a tool for shaping the future that translates speed into value, complexity into accountability, and innovation into trust.

For the German Testing Board (GTB), one thing is clear: software quality is not an optional “add-on” or even an obstacle to progress – it is the compass that guides us safely through the complexity of digitalization and AI. In this context, quality assurance and proven professionalism are once again the strategic levers for sustainable software-based innovations with AI.

The GTB will actively contribute to this discourse on our new blog. We invite you to join this debate: How can we actively shape the new software era with AI? How do we develop the necessary skills and offerings? How do we protect our digital solutions and infrastructures from a potential AI-induced “software collapse”?

With this blog, we aim to discuss and contextualize current insights and new solutions for software engineering involving AI and its quality assurance, and to exchange best practices. Join us as we embark on this journey of exploration together.

References

[1] Arya, D. (2025). GenAI for Technical Debt Management – Using Generative AI to Handle Technical Debt in Software Development (Dissertation). Abgerufen von https://urn.kb.se/resolve?urn=urn:nbn:se:su:diva-251544
[2] Anderson, E., Parker, G., & Tan, B. (2025). The Hidden Costs of Coding With Generative AI. MIT Sloan Management Review, 67(1), 12-14.
[3] Moreschini, S. et al (2026). The Evolution of Technical Debt from DevOps to Generative AI: A multivocal literature review, Journal of Systems and Software, Volume 231, 2026, https://doi.org/10.1016/j.jss.2025.112599.
[4] Mujahid, A. A., & Imran, M. M. (2026). TODO: Fix the Mess Gemini Created: Towards Understanding GenAI-Induced Self-Admitted Technical Debt. arXiv preprint arXiv:2601.07786.
[5] Skamser, C. (2026). The Evolution of Technical Debt in the Era of AI.  Abgerufen von https://www.linkedin.com/pulse/evolution-technical-debt-era-ai-charles-skamser-oyygc/
[6] Chatterjee, A. (2025). Quality assurance in the AI era: a leadership imperative, according to S&P Global Market Intelligence. Sonar Blog, Abgerufen von https://www.sonarsource.com/blog/quality-assurance-in-the-ai-era/.
[7] Crisóstomo, J. (2025), Software Quality in the AI Era. The AI Journal. Abgerufen von https://aijourn.com/software-quality-in-the-ai-era/.
[8] Dobslaw, F., Feldt, R., Yoon, J., & Yoo, S. (2025). Challenges in Testing Large Language Model Based Software: A Faceted Taxonomy. arXiv e-prints, arXiv-2503.
[9] Baker, P., et al. (2007). Model-driven testing: Using the UML testing profile. Springer Science & Business Media.
[10] Muratovic, F., et al. (2024). How can organizations engineer quality software in the age of generative AI? Deloitte Insights, Abgerufen von https://www.deloitte.com/us/en/insights/industry/technology/how-can-organizations-develop-quality-software-in-age-of-gen-ai.html.
[11] Sonar 2026). State of Code Developer Survey report, Abgerufen von https://www.sonarsource.com/state-of-code-developer-survey-report.pdf

Leave A Comment