Hardly any other development has transformed the software industry over the past two years as much as the productive use of AI. Code generation has become faster, more affordable, and more widely available. Less often discussed is the other side of this equation: speed in development says little about the costs of operation. For companies that maintain and further develop software over the course of years and are accountable to customers and regulatory authorities, the value of AI is not determined on the day of delivery, but rather at the very next update.
The technical term for the difference between the two is “technical debt.” This refers to the additional effort that arises when a faster solution is prioritized over a more sustainable one during development—and which subsequently accumulates, like interest, with every subsequent change made at that point. According to research by McKinsey, technical debt accounts for an average of about 40 percent of a company’s IT balance sheet. It is therefore not a marginal item in development work, but rather one of its largest cost centers.
Why AI-Driven Development Is Accelerating the Rise in Debt
Three factors are intertwined here. None of them argues against the use of AI. Together, however, they explain why, without a methodological framework, the outcome can backfire.
Generation and testing are becoming decoupled
As long as developers wrote every line of code themselves, understanding the codebase was a byproduct of its creation. This coupling breaks down as soon as a significant portion of the implementation is done by machine. The software works, but the rationale behind its structure exists only within the context of the model and no longer within the team. In our projects, this rarely becomes immediately apparent; rather, it typically comes to light during the first major change initiative, when no one can provide a convincing explanation for why a component was designed one way and not another.
Plausibility Takes Precedence Over Correctness
Language models do not signal uncertainty. They continue to generate output consistently even when the underlying information is missing. This is particularly evident with integrated third-party components: In a study presented at USENIX Security 2025, 19.7 percent of the program libraries recommended by code models did not exist at all. The practically relevant point here is not so much the error rate as the fact that the error goes unnoticed. A result that is not recognizable as erroneous passes through review processes designed to detect human error patterns.
Reliability declines significantly in the existing fleet
For new developments without legacy issues, the results of AI-supported development are reliable. In brownfield scenarios, however—that is, in mature systems with business logic that has evolved over time—the accuracy rate drops significantly: benchmarks that test long-running tasks in real enterprise codebases show a decline of more than half compared to standard tests. The cause is not technical. Decades-old systems contain constraints, exceptions, and business decisions that were never documented. A model lacking architectural context violates these and thus accelerates the very problem it was intended to fix.
Where technical debt arises and what changes as a result of AI-driven development:
| Level | Classic Development Pattern | Shift Driven by AI-Powered Development |
| Implementation | Intentional omissions made under time pressure, the correction of which is postponed | High output volumes that structurally exceed the capacity for visual inspection |
| Architecture | Rules exist as conventions and are embodied in the knowledge of individuals | Posts without an architectural context violate boundaries that are not automatically enforced anywhere |
| Dependencies | Outdated libraries, delayed update cycles | Proposals that do not exist or originate from other ecosystems |
| Expertise | Documentation is out of date; responsibilities are changing | The technical intent was never documented in a specification |
| Record-keeping | Test steps are run manually and at varying levels of depth | The volume of changes and testing capacity are becoming measurably decoupled |
The turning point lies in the specification
A widely cited example from the financial sector demonstrates that the same toolkit can also be applied in the opposite direction. Morgan Stanley developed DevGen.AI, an internal tool designed to address a common challenge faced by banks, insurance companies, and industrial firms alike: business-critical core systems written in languages such as COBOL and PL/I, for which there is hardly any staff available anymore. According to the company, since January 2025, the tool has processed approximately nine million lines of legacy code and saved about 280,000 developer hours.
More revealing than the scope is the chosen methodology. The tool does not directly convert legacy code into a modern target language, but first translates it into domain-specific specifications in natural language. The development teams then handle the reimplementation. Here, AI is not used to increase output volume, but rather to reconstruct lost domain knowledge.
Four control levers that determine the direction
The most reliable figures supporting the opposite view also come from McKinsey. Based on an analysis of its own modernization projects, the use of artificial intelligence shortens project durations by 40 to 50 percent and reduces costs resulting from technical debt by about 40 percent, while simultaneously improving the quality of earnings. The difference between this result and an accelerated accumulation of debt lies not in the model used, but in the methodological framework. In our consulting projects, it is consistently the same four elements that determine the direction:
- Specification before implementation. A machine-readable description of the technical requirement establishes the benchmark against which a result can be evaluated at all. Without it, one can only determine whether the code is executable, not whether it meets the requirement. Under the term “Spec-Driven Development,” this approach has now been given its own methodological framework.
- Validation outside the system that generated the data. Test scenarios created by the same entity that implements them are self-validating. Only strictly separated holdout scenarios—which remain inaccessible to the model—make a positive test result meaningful. Without them, humans cannot be removed from the review loop without losing control.
- Architectural constraints imposed by machines. Architectural rules that exist solely in code reviews are bound to erode under delivery pressure. When implemented as an automated check in the build process, a violation causes the build to fail immediately, rather than going unnoticed for months. This shifts architectural work from relying on reminders to being embedded in the process.
- End-to-end traceability. If every change can be traced back to the underlying requirement, domain expertise will endure even through personnel changes. At the same time, this serves as the foundation for any subsequent documentation required by internal audits and external auditors.
Regulatory Framework: Postponed Deadlines, Unchanged Requirements
The regulatory framework underwent changes in the summer of 2026, though not in substance. With the Digital Omnibus, which the Council of the EU finally adopted on June 29, 2026, the obligations for autonomous high-risk systems under Annex III of the AI Regulation will no longer apply starting in August 2026, but only starting in December 2027. Only the effective date has been postponed. The substantive requirements for risk management, data governance, technical documentation, human oversight, and automated logging remain unchanged.
Regardless of this, a second deadline is approaching: Starting December 9, 2026, the amended EU Product Liability Directive will, for the first time, explicitly classify software as a product subject to liability. We have outlined the implications of this for the development process in our article on the five maturity levels of AI software development.
When it comes to technical debt, one consequence is particularly relevant: traceability can only be retrofitted at considerable expense. Anyone who waits to establish it until a deadline is approaching must incorporate it into a system that they can no longer fully oversee at that point. This is the most expensive form of repayment imaginable, and in our experience, it is the item that most reliably blows modernization budgets.
From Individual Projects to Institutional Capability to Deliver
The four levers mentioned above can be implemented within a single project. They only achieve their full impact when they are no longer dependent on the discipline of individual teams but are structurally embedded in the delivery process. The Software Factory operating model describes precisely this transition: specialized AI agents operating within a binding governance framework, in which reviews, tests, and audits run automatically with every change, while humans retain responsibility at defined approval stages.
The economic leverage behind this lies less in the effort saved than in the capacity freed up. According to the Bitkom study on the labor market for IT professionals, there are approximately 109,000 unfilled IT positions in Germany. Under these circumstances, every hour a senior developer spends reconstructing incomprehensible code is doubly costly. This is particularly true in sectors where software is developed under regulatory conditions: in the insurance industry, at banks, in logistics, and in the fields of life sciences and medical technology.
Outlook: From the Question of Production to the Question of Stock
The discussion over the past two years has largely centered on code generation: which models produce better code, which tools are gaining traction, and how significant the productivity gains are. This phase is coming to an end. Since nearly all major development organizations are now using AI in production, the focus is shifting to the question of what already exists: What has been created in recent months, who understands it, and under what conditions can it be further developed?
Technical debt does not disappear simply because code is written faster. It disappears when every change remains justifiable. Both paths are possible: AI can accelerate the accumulation of technical debt just as much as it can help reduce it. Which of the two occurs is determined not by the model itself, but by the methodological framework in which it is embedded.
Schedule a consultation about Software Factory. We’ll discuss your current situation, how to address existing legacy issues, and specific next steps.
Frequently asked questions (FAQs)
What is technical debt in software development?
Technical debt refers to the additional effort that arises when a faster solution is prioritized over a more sustainable one during development, and which subsequently occurs with every further change made at that point. The term originates from a credit metaphor: it is not the loan itself that is problematic, but the interest. According to research by McKinsey, technical debt accounts for an average of about 40 percent of a company’s IT balance sheet.
Does AI-driven development create more technical debt?
Not necessarily, but faster and more discreet. As soon as a significant portion of the implementation is automated, the generation and verification processes become decoupled. In addition, erroneous results appear plausible and thus pass through review processes designed to detect human error patterns. Without independent validation, this creates liabilities that no one has consciously incurred.
How can technical debt be minimized in AI-driven development?
Four key elements: a machine-readable specification prior to implementation; holdout validation scenarios outside the system that generates the code; machine-enforced architectural constraints during the build; and end-to-end traceability of every change back to the underlying requirement. McKinsey estimates that this approach results in modernization timelines that are 40 to 50 percent shorter and a reduction in technical debt costs of approximately 40 percent.
What does the postponement of the EU AI Act deadlines mean for ongoing projects?
Under the Digital Omnibus, the obligations for standalone high-risk systems set forth in Annex III will no longer take effect in August 2026, but rather in December 2027. Only the effective date has been postponed; the scope of the requirements remains unchanged. In practice, this means more time for implementation while the objectives remain unchanged, particularly with regard to logging and traceability.
Short Glossary
- Technical debt: Additional effort that arises when a faster solution is preferred over a more robust one during development, and that is incurred with every subsequent change made at that point.
- Brownfield: Working within established legacy systems with business logic that has evolved over time, as opposed to new development without legacy issues (Greenfield).
- Holdout scenario: A validation test that is strictly separated from the production code and remains inaccessible to the AI, so that it does not optimize itself based on its own tests.
- Architectural boundary: A binding rule specifying which system components are allowed to access one another. Implemented as an automated check during the build process; a violation causes the build to fail.
- Traceability: Consistent mapping of every code change to the requirement from which it originated. The foundation for maintainability and regulatory compliance.
- Spec-Driven Development (SDD): A development approach in which a machine-readable specification replaces the code. The AI implements it, and a validation system checks it.
List of Sources
¹ McKinsey (2023): Breaking technical debt’s vicious cycle to modernize your business – technical debt accounts for about 40 percent of the IT balance sheet; an additional 10 to 20 percent project premium is required to address existing legacy issues. Available at: mckinsey.com/capabilities/tech-and-ai/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business
² Spracklen et al. (2025): We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code-Generating LLMs. USENIX Security 2025 – 19.7 percent of program libraries were hallucinated across 576,000 code examples from 16 models. Available at: arxiv.org/abs/2406.10279
³ Scale AI / Deng et al. (2025): SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? – Performance degradation in long-running tasks in real enterprise codebases compared to standard benchmarks. Available at: scale.com/blog/swe-bench-pro
⁴ Wall Street Journal (2025): “How Morgan Stanley Tackled One of Coding’s Toughest Problems” – DevGen.AI, approximately nine million lines of existing code and about 280,000 developer hours saved since January 2025. 04.06.2025.
⁵ McKinsey (QuantumBlack) (2024): AI for IT Modernization: Faster, Cheaper, Better – Modernization timelines 40 to 50 percent shorter, costs associated with technical debt reduced by about 40 percent. 02.12.2024. Available at: mckinsey.com/capabilities/quantumblack/our-insights/ai-for-it-modernization-faster-cheaper-and-better
⁶ Regulation (EU) 2024/1689 (AI Regulation), as amended by the Digital Omnibus—finally adopted by the Council of the EU on June 29, 2026: High-risk obligations under Annex III effective December 2, 2027, instead of August 2, 2026; under Annex I effective August 2, 2028. Available at: eur-lex.europa.eu/eli/reg/2024/1689/oj
⁷ Directive (EU) 2024/2853 (EU Product Liability Directive) – Software and AI systems are expressly classified as products subject to liability; effective as of December 9, 2026. Available at: eur-lex.europa.eu/eli/dir/2024/2853/oj
⁸ Bitkom (2026): The Labor Market for IT Professionals, 2025 Study Report – Approximately 109,000 Unfilled IT Positions in Germany. Representative survey of 855 companies. Available at: bitkom.org/Bitkom/Publications/The-Labor-Market-for-IT-Specialists
