Why Can Technical Debt Increase When We Develop Software with AI?

Today, artificial intelligence agents allow us to develop features, fix bugs, and even run tests in much less time than before. This is a major advantage for development teams: we can move faster and devote some of our effort to other activities.

But I wonder: if we can now generate much more code in less time, does that mean we are building better applications? Or could we be pushing into the future some of the work we are not reviewing today?

This brings us to a concept that is not new but becomes particularly important with the use of AI: technical debt.

What exactly is technical debt?

The term was popularized by Ward Cunningham, who compared it to financial debt to explain what happens when we make decisions that allow us to move forward quickly but require additional work later to maintain or improve the software.

Imagine that, to meet a delivery deadline, we implement a feature without properly following the existing architecture. It may work, and the customer may be satisfied. But when we need to modify it or add new features, we will probably have to spend more time understanding, fixing, or reorganizing it.

This does not mean every quick decision is wrong. Sometimes, deliberately taking on technical debt can make sense, as long as we understand the consequences and have a plan to manage it.

Technical debt is not limited to code that is hard to read, either. It can arise from duplicated functions, tight coupling, missing tests, poor architectural decisions, or dependencies on libraries that are no longer maintained.

The real problem begins when that debt grows without us noticing, and each new change starts to cost more than the last.

Why might AI agents increase this debt?

When we work with an agent, we usually explain what we want to build. Depending on the tools and context it can access, the agent may analyze files, modify code, run tests, and deliver a working solution.

However, the fact that a feature works correctly does not necessarily mean that it is well integrated with the rest of the application.

Consider a simple example.

We have a sales application with a layered architecture and a service that centralizes the business rules for discounts. We ask an agent to add a new discount for certain customers.

The agent generates the code, runs tests for the new feature, and delivers a seemingly correct result. But when we review its work, we discover that it implemented the rules directly in the API controller instead of using the existing discount service.

Does it meet the requirement? Yes, possibly.

Does that mean it is a good implementation? Not necessarily.

Now we have business rules in two different places. If the discount policy changes tomorrow, we may need to modify several components and make sure they all produce consistent results.

This is just one example of how we can create technical debt even when the code works. It can also happen when the agent:

• Creates unnecessary components or abstractions to solve a simple problem.
• Duplicates functions that were already implemented in the project.
• Adds a library without evaluating its maintenance, compatibility, or security.
• Modifies a component without analyzing how the change affects other modules.
• Generates changes faster than the team can review and integrate them.

But we should keep something important in mind: AI does not inevitably create technical debt. An agent that understands the project’s architecture, constraints, and standards can help us produce better implementations and even fix existing problems.

Therefore, the issue is not simply how quickly we generate code, but our ability to evaluate what is generated.

How can we identify and measure technical debt?

One option is to use static analysis tools such as SonarQube. These tools inspect code without running the application and can identify certain maintainability, duplication, and complexity issues.

Among the indicators we can look at are cyclomatic complexity, which helps us understand how many execution paths a function has; code duplication; and estimated remediation effort, which approximates the work needed to fix issues identified by the tool’s rules.

There is also the Technical Debt Ratio (TDR), which compares that estimated remediation effort with an estimate of development effort:

TDR = (Estimated remediation effort / Estimated development effort) × 100

For example, if we estimate 100 hours to fix the detected issues and use 2,000 hours as our reference development effort, the result would be 5%.

This does not mean that 5% of the code is poorly written. It means that, according to those estimates, fixing the identified issues represents 5% of the development effort used as a reference. In tools such as SonarQube, development effort may be calculated using the tool’s own parameters, so we need to interpret the indicator within its methodology.

Still, no metric tells us the whole story. A tool may identify duplicate code or complex methods, but it will not necessarily determine whether an architectural decision is right for our business.

That is why, beyond measuring, we need to review dependencies, architectural rules, tests, and the impact of changes on other components.

Can we use AI itself to reduce technical debt?

If we can use agents to generate code, why not use other agents to review what we are building?

I find this one of the most interesting possibilities. We can separate responsibilities: one agent implements the feature, while another reviews its quality, its integration with the architecture, and the potential risks it introduces.

But this does not mean we should create many agents that all do the same thing. What matters is establishing complementary checks, for example:

1. Generate small changes: Request narrowly scoped features that are easier to understand, test, and review.
2. Validate automatically: Run tests, static analysis, and architectural rules as part of continuous integration.
3. Review with another agent or model: Compare the implementation against the project’s technical decisions and ask it to explain the problems it finds.
4. Fix and reassess: Let the agent adjust the code, but set limits on the number of attempts and request human review if significant problems persist.
5. Compare before and after: Determine whether the change introduced new maintainability issues or resolved some existing debt.

It is also useful to document important architectural decisions through Architecture Decision Records (ADRs). It is not enough to tell the agent which technology we use; we should explain why it was chosen, what constraints exist, and what the consequences of changing it might be.

We should remember that a review by another agent does not guarantee everything is correct, either. Its conclusions need evidence, tests, and verifiable rules. AI can help us review, but the developer’s judgment remains essential.

Recommendations

To take advantage of development speed without losing control of quality, I would recommend starting with a few simple practices:

• Define the context before generating code. Share the architecture, standards, permitted dependencies, and acceptance criteria with the agent.
• Do not review only whether the feature works. Also check where it was implemented, what it reuses, which dependencies it introduces, and which components it might affect.
• Establish a quality baseline. Compare indicators before and after incorporating AI-generated code, distinguishing existing debt from newly introduced debt.
• Automate repeatable checks. Use tests and analysis tools to detect violations, while reserving human review for decisions that require business and architectural knowledge.
• Do not turn metrics into goals in themselves. A good indicator is no substitute for a good design decision.

These recommendations are not intended to slow development down. On the contrary, they are meant to prevent the speed we gain today from becoming tomorrow’s maintenance problems.

Conclusion

We could say that artificial intelligence has significantly changed how quickly we develop software, but it has not removed the need to understand how our applications are built.

An agent can generate a feature in minutes, but if that implementation increases coupling, duplicates responsibilities, or makes future changes harder, the time we initially save may ultimately turn into a maintenance cost.

That is why I believe the next step is not merely to use agents to write more code, but to learn how to use them to evaluate, maintain, and improve what we have already built.

The goal is not to eliminate technical debt completely, because that would hardly be realistic. It is to recognize it, measure it when possible, make informed decisions, and keep it from growing out of control.

Development speed is an important advantage, but its real value depends on our ability to maintain and evolve what we build today.

That is why, at INSPYR Global Solutions (IGS), we have developed our own framework, which allows us to generate projects while ensuring that these recommendations are applied. We have also observed that our technical debt is lower and easier to manage.

This reflects an important part of how we approach innovation at IGS: combining the potential of AI with technical expertise and sound engineering practices to build solutions that are not only faster to develop but also easier to maintain and evolve.

If you’re interested in working with AI, exploring new development approaches, and growing alongside professionals who value technical excellence, explore career opportunities at IGS.

“Learn to share, and share to learn.”

References

• Agile Alliance. Introduction to the technical debt concept. https://agilealliance.org/introduction-to-the-technical-debt-concept/
• SonarSource. Understanding measures and metrics: Technical debt and technical debt ratio. https://docs.sonarsource.com/sonarqube-server/2025.4/user-guide/code-metrics/metrics-definition
• Microsoft Learn. Maintain an architecture decision record (ADR). https://learn.microsoft.com/en-us/azure/well-architected/architect-role/architecture-decision-record
• Martin Fowler. Architecture decision record. https://martinfowler.com/bliki/ArchitectureDecisionRecord.html