AI Coding Agents Are Making Technical Debt Expensive.

AI is changing the economics of software design.

The interesting thing about coding with agents is that it is quietly changing what “good software design” means. Or maybe more accurately, it is changing what bad software design costs. 

Technical debt is no longer a future problem

For years, technical debt mostly existed as an abstract future problem. We all knew tightly coupled systems were harder to maintain. We knew poor separation of concerns would eventually slow teams down, and that tests mattered. But most of the time those costs were deferred, because you could still ship software with a messy architecture if the team understood the mess well enough. 

Today, agentic development changes that equation because poorly designed systems now create immediate operational costs. Literal costs. 

Token efficiency is becoming an architectural concern

The more I work with coding agents, the more I find myself thinking about token efficiency as an architectural concern. Not because tokens themselves are especially expensive in isolation, but because waste compounds quickly when agents are involved in iterative workflows. 

One of the biggest hidden costs is validation. Every time an agent has to stop and ask itself “did I actually do what was requested?”, it burns context and tokens. Every time it needs to inspect a large surface area of the application to verify correctness, costs rise again. If the codebase is difficult to reason about, the agent compensates with more exploration, more retries, more analysis, more defensive prompting. You can almost feel the architecture leaking into the token bill. 

Why coding agents reward disciplined engineering

What I’ve gradually ended up doing is moving back toward approaches that, a few years ago, we would have simply called disciplined engineering. Write the tests first. Define clear interfaces. Isolate logic from presentation. Reduce ambiguity. Keep responsibilities narrow. Build systems where correctness can be verified cheaply. 

In practice, agents perform significantly better when the problem space is tightly scoped and externally verifiable. A failing unit test is a very efficient feedback mechanism. The agent knows exactly what success looks like. It can iterate inside constrained boundaries instead of re-reading half the application trying to infer intent. The alternative is surprisingly expensive. 

Validation is the hidden cost in agentic development

Recent research into token consumption in agentic coding workflows found that coding agents can consume up to 1000x more tokens than traditional code-completion workflows, with validation and context exploration becoming major drivers of cost. More interestingly, higher token usage did not reliably improve outcomes. Accuracy often peaked at moderate token usage before declining again. 

That aligns fairly closely with what I’ve been seeing in practice. Past a certain point, additional agent “thinking” often just means the model is compensating for unclear structure. Which starts to make old engineering patterns look surprisingly modern again. 

Test-driven development suddenly makes economic sense

Test-driven development suddenly makes economic sense in a way it arguably never did before. The same applies to clean architecture, onion architecture, separation of concerns, and all the slightly unfashionable engineering practices that many teams quietly abandoned under delivery pressure. 

We used to justify those approaches as investments in maintainability. Future-proofing! Team scalability! Concepts that were technically correct, but difficult to quantify in real time. Now… the feedback loop is immediate. Bad boundaries increase token consumption, and poorly isolated business logic increases validation costs. Large, tightly coupled UI frameworks increase exploration costs - today. 

Technical debt now appears directly on your invoice

Technical debt has stopped being theoretical interest accumulating somewhere in the future. Agents turn it into an operational expense that appears directly on the invoice. UI development is where this becomes especially obvious. 

Modern coding agents are reasonably effective when they can interact with software through deterministic interfaces. Web applications fit that model quite well because agents can use browser automation frameworks like Playwright to observe behaviour and validate flows. Desktop UI frameworks are much harder. 

Why UI-heavy systems are harder for agents

I’ve found Windows Forms particularly awkward in this regard. The agent cannot naturally “see” the application in the same way it can inspect a DOM. Validation becomes fragile and expensive because the system lacks clean observational boundaries. The practical result is that I increasingly separate application logic from UI concerns much more aggressively than I used to. Core behaviour becomes testable independently, while UI layers are kept relatively thin and validated in isolation. 

Again, none of this is new - we already had names for these ideas. The irony is that many of the practices that seemed overly cautious or architecturally pure a decade ago now happen to map almost perfectly onto the constraints of agentic development. That’s the beauty of human insight in design.

Agents reward software that is modular, observable, deterministic, and testable. Which, in hindsight, is also what humans preferred all along. There’s also an interesting shift happening psychologically inside engineering teams. Historically, technical debt often lost prioritisation battles because its costs were indirect. Teams could defer cleanup work for months or years without immediately feeling the impact. That becomes much harder when every poorly structured workflow increases token usage, review time, retry loops, and agent supervision overhead in the current sprint. 

Agents amplify both good and bad architecture

A recent large-scale empirical study of over 300,000 verified AI-authored commits found that AI-generated code introduces persistent maintainability issues at meaningful rates, with nearly a quarter of identified issues surviving long-term in production repositories. 

That persistence matters because agents amplify both good and bad structure very quickly. A clean architecture gives agents leverage. A chaotic architecture gives them entropy. And unlike previous eras of software development, the inefficiency is measurable almost immediately. 

We’re rediscovering why engineering discipline mattered

The way I’m thinking about this at the moment is that we may have accidentally rediscovered why software engineering discipline existed in the first place. 

For years, good architecture often felt optional if the team was strong enough to carry the complexity in their heads. Agentic development removes some of that tolerance. The economics become harder to ignore. Now we call it designing for agents.We just used to call it good design. 

If your organistation is working through how AI, automation and identity governance fit together operationally, we’ll be exploring these themes further in our upcoming AI in Identity Strategy Session.

And follow me Robert Burke and Activate on LinkedIn for more practical insights on governed automation, enterprise AI and identity-driven workflows.