The next wave of technical debt is architectural, and AI is accelerating it
In this article​
Summary
AI coding tools can help teams produce code faster. They typically also make software harder to change if the architecture does not keep up.Â
Architectural debt is a major concern in technical debt management because it sits between systems, not inside individual files. It affects how components depend on each other, how software portfolios scale, and how quickly teams can ship changes responsibly.Â
Unlike code-level debt, such as duplicated logic or complex functions, architectural debt is harder to detect and more expensive to fix after the fact. This article explores what architectural drift is, why AI can speed it up, and what organizations can do before it becomes a structural problem.Â
Introduction
Technical debt is nothing new. Since the early nineties, this metaphor has been used to explain software quality issues that slow down future development in a way that is easy to understand, even for those without a technical background. Â
Technical debt is the extra effort you incur in the future because of shortcuts or suboptimal choices you make today. Think of it as a useful but risky trade-off between time, quality and cost. Â
Similar to financial debt, interest must be paid. Â
 In large organizations, technical debt shows up across dozens or hundreds of systems that depend on each other. To put it in perspective: Deloitte’s 2026 Global Technology Leadership Study recently estimated that technical debt accounts for 21% to 40% of an organization’s IT spending.  Â
This means that for every €100 spent on IT, between €21 and €40 is allocated to addressing technical debt.Â
But before you try to get that number down to zero, it’s good to realize that technical debt is unavoidable and, maybe surprisingly, not always negative. In fact, it can sometimes be a necessary trade-off for increased speed. Â
Just like some financial debt can be essential for making investments and fuelling growth, other types of financial debt should be paid off as quickly as possible due to high interest rates. Â
So, the key question is not about how to eliminate all technical debt but rather understanding where to prioritize reducing it. Easier said than done, especially with the added challenge of a new and popular technology: AI. Â
The rise of AI and technical debt
AI adoption is skyrocketing. Today, 29% of Fortune 500 companies deploy AI coding tools and for good reasons. AI coding tools are making development faster. However, they are also making technical debt rise and harder to contain. Â
On the one hand, AI’s output has been shown o contain 1.7 times more issues than human code. However, on the other hand, AI coding tools can also be used to remediate technical debt. Â
So, like with many other uses cases, AI is proving to be a double-edged sword. But it gets even more complicated than that. Â
Ready? There are many different types of technical debt. Â
The type of technical debt that is most often referred to is the one that means messy code. Why? Because code that is messy, is harder to understand, and code that is complex is a lot harder (more expensive) to change, improve, or fix. Â
Don’t get me wrong; this type of technical debt is still important, but there is one type in particular that’s about to present its bill: Architectural debt.Â
This article will dive into what architectural debt is, why this type of technical debt is rising as quickly as recent AI adoption rates, and what to do about it. Â
What is architectural debt?
To understand architectural debt, we first need to understand what software architecture is. The concept of software architecture is a metaphor borrowed from traditional construction, which emphasizes the importance of planning before building, ensuring structural integrity, and relying on blueprints.Â
In software engineering, architecture is the structural design of a system referring to the way a given codebase is divided and grouped together based on responsibilities, and the underlying dependencies between these responsibilities.Â
In other words, it addresses how different components are interconnected and what happens to one part when another part is changed. Â
While architectural debt is indeed a part of the broader term “technical debt,” it stands apart from issues within a single file or function. Architectural debt manifests in the relationships between systems: it pertains to how components are linked, how teams rely on each other’s work, and whether the software structure aligns with the original design intent.Â
This is exactly where AI’s capabilities fall short; Ai coding tools or agents have a limited context window and typically lack domain knowledge. This means that when making decisions, they do not consider your architecture and may attempt to fill in the gaps independently.Â
At Software Improvement Group (SIG), with 25 years of experience analyzing billions of lines of code, we know that architectural debt has always existed, even in well-run engineering organizations. It’s a lot harder to spot, as even clean code can create architectural debt. Â
What is changing now is the speed at which this debt accumulates due to the adoption of AI.Â
A recent and agentic example of technical debt creation
We used Sigrid®, our software portfolio governance platform, to look at FastRender’s codebase. An impressive Agentic-AI experiment from Cursor in a brutally hard domain. Cursor’s swarm of coding agents produced a browser engine with over 3 million lines of code in just a week.Â
It contained more than 3 million lines of Rust code, roughly equivalent to 110 person-years of development effort. The speed was impressive. But when we ran the output through Sigrid®, it scored 1.3 out of 5 stars for maintainability, placing it in the bottom 5% of systems we see in the market.Â
Its architecture quality scored 2.1 out of 5. Components were tightly coupled, and modularity was low. Changes in one area could affect other areas unpredictably. Â
Important disclaimer is that Cursor presented FastRender as an experiment, not a production system, and that distinction matters. Even so, it shows the kind of structure AI can produce, at speed.Â
What architectural drift looks likeÂ
In a discussion from an upcoming webinar, Luc Brandts, SIG’s CEO, sat down with Jasper Geurts, SIG’s CTO to talk about the need of technical debt management in the age of AI and explained the pain of architectural drift perfectly. Â
“An architecture drift is that step by step, and commit by commit, you get to a situation where your architecture is different from the intentions. You have all sorts of cyclic dependencies and connections that shouldn’t be there.”Â
The important word here is “intentions.” Most organizations have a target architecture, or at least a working idea of one. Drift happens when the code that gets written, reviewed, and shipped gradually diverges from that design. Or when we refer back to the construction metaphor, where a contractor makes changes—such as tearing down a wall or adding plumbing—without referring to the blueprint. Deviations from the blueprint don’t always have to be problematic, and the same applies to software. Â
A dependency gets added under deadline pressure. A module expands beyond its original purpose. A shortcut solves a local problem but creates a coupling that was never meant to exist.Â
Each decision can look reasonable on its own. The problem is the accumulation. By the time the consequences are obvious — usually when a change becomes unexpectedly expensive or a release triggers failures elsewhere — the debt is already part of the system.Â
This type of drift is harder to detect than code-level debt because most tools do not effectively identify it. While many tools can illustrate how an architecture is supposed to look, I often find that clients are surprised when I show them how it actually appears in our platform, based on the built code rather than a theoretical blueprint. Â
Just as a homeowner may not realize a wall contains plumbing that wasn’t part of the original design, they can inadvertently cause a leak by drilling a hole. We can help identify where the actual pipes run.Â
Measuring the real dependencies between components lets us compare the as-built architecture with the intended one and track how the gap changes over time. In every system you’ll find some degree of drift. The question is how much exists, and where it creates risk.Â
Why AI coding tools make this harder, not easierÂ
The productivity gains from AI coding assistants are real. Research shows that developers using these tools can see productivity increases of around 25%. At scale, that is significant. For individual developers working in familiar parts of the codebase on well-understood problems, AI assistance can work well.Â
The issue is what happens underneath that faster output. Recent research points to AI adoption in software development causing technical debt to increase by 30–41%. Teams can produce code faster without producing cleaner systems. The debt that builds up is often architectural, not just code-level, because architecture is exactly where AI tools are weakest.Â
The reason is context. Writing a function is a bounded task. Deciding how a new component should connect to the rest of a system is not. That decision depends on boundaries, dependencies, downstream effects, team ownership, and existing design intent. AI tools do not yet handle that kind of judgment reliably.Â
Or as pointed out in the same webinar mentioned above:Â
“If you have an AI doing this, again, it’s like an intern — a very clever and super-fast intern, but not with a lot of experience developing stuff. Without that context, you will create architectural drift.”Â
SIG’s own measurements show that AI-generated code is significantly lower quality than human-written code. That finding can sound counterintuitive, but it fits how these tools work. They optimize for functional correctness in the immediate context. They do not reliably optimize for long-term maintainability or architectural coherence.Â
The faster code is generated, the faster structural gaps can accumulate — especially when the people accepting the output are less experienced and less able to judge the trade-offs.Â
The vibe coding trend raises the stakes further. When people who are not trained engineers use AI to generate production software, they may bring strong domain knowledge but limited architectural knowledge. They know what the system should do. They may not know how it should be structured, how to keep dependencies clean, or what non-functional requirements mean in practice. The result can be software that appears finished but carries structural risk from the beginning.Â
The ROI case is becoming clearerÂ
One reason architectural debt has often been treated as a technical concern is that it has been difficult to quantify. In addition, according to Deloitte, it’s tempting for organizations to treat technical debt as a back-office nuisance, or as an invisible cost of doing business.Â
However, a peer-reviewed study published in April 2026 found that systematic remediation of architectural debt yields median returns of 437% over 24 months, with a break-even period of just 6.2 months.Â
The numbers might sound unbelievable, but this is consistent with what we see at software Improvement Group. Or as SIG CTO Jasper Geurts said:Â
“It is actually also a CFO problem — it is a business problem, it’s a cost problem.”Â
The fix is not a cleanup projectÂ
When architectural debt becomes visible, the first instinct is often to launch a remediation project. Bring architects together, define the target state, and plan a migration.Â
That can be necessary. In some cases, there is no alternative. But a cleanup project does not solve the underlying problem by itself.Â
The underlying problem is portfolio-wide visibility. If teams do not have continuous visibility into how architecture is changing, drift will return. If there is no way to detect drift as it happens, or to flag a commit that introduces a dependency that should not exist, more of the same debt will build up again.Â
Organizations that manage this well do not review architectural quality only from time to time. They monitor it continuously, in the same way they monitor security posture or build pipelines. They connect quality standards to the engineering process, so developers get feedback before debt reaches production, not six months later during an architecture audit.Â
That matters more as AI coding tools become part of everyday development. Faster code generation increases the need for faster feedback. If an AI-assisted commit introduces a dependency that breaks an architectural boundary, teams should be aware while the work is still in progress.Â
“Technical debt management shouldn’t be an afterthought. It should be in the pipeline, in the way of working — whether that’s human-driven, whether that’s with AI coding assistance, or totally agentically. It needs to be included.”
Before an organization can act on architectural debt, it needs to see it accurately, continuously, and in the places where it matters for the business.Â
Where to startÂ
Not every system with architectural debt needs immediate work. A stable system that is rarely changed and close to end of life may carry debt that is acceptable to leave alone.Â
The useful analysis is about where debt sits in relation to business activity: which systems change often, which are business-critical, and where structural fragility creates delivery or security risk. The highest-priority systems are usually the ones where those answers overlap. A system that changes frequently, supports an important business process, and already shows rising dependency complexity deserves attention before a stable legacy system with limited change activity.Â
That is especially true when AI coding tools are being adopted. AI-assisted development is most likely to create delivery risk where teams are already moving quickly through systems with weak boundaries or unclear ownership.Â
Most organizations cannot answer those questions well without portfolio-level visibility. Individual teams can see their own backlog. They usually cannot see how their system’s architecture compares with others in the portfolio, or whether it is improving or degrading over time. That broader view is what separates architectural debt management from architectural debt awareness.Â
If your organization is increasing its use of AI coding tools, this is the time to put that visibility in place. To learn more about what this means for your organization, we can help. Reach out here.Â
About the author
Werner Heijstek
Werner Heijstek is the Senior Director at Software Improvement Group and host of the SIGNAL podcast, a monthly show where we turn complex IT topics into business clarity.