The Hidden Cost of Technical Debt

The short version

Software is now written faster than it is understood. AI and vibe coding have made building cheap, but maintaining what was built is where the money goes. In our session on 7 October, Dave Hickman, Daniyal and Keval Prabhu walked through why technical debt keeps growing, why it has become a business problem rather than an engineering one, and what it looks like to manage it as a continuous loop instead of a periodic clean-up.

The numbers behind the problem

• 21–40% of IT spending can be consumed by technical debt.
• 42% of developer time goes to maintenance, debugging and refactoring, not building what comes next.
• 60% of enterprises say legacy systems are holding them back from adopting new technology.
• $1.52 trillion of accumulated software technical debt in the US.

These figures come from published industry research, including Deloitte's 2026 study and work by Pega and Savanta.

Key insights

1. Technical debt is the cost of today's shortcut, paid tomorrow. Every request brings a trade-off, and every trade-off makes the next change slightly harder. Teams don't accumulate debt because they don't care. They accumulate it because they are balancing speed now against cost later.

2. Vibe coding is an accelerant, not the cause. Describing what you want and getting working software in minutes is powerful. But software can now be created faster than it can be understood. The code runs, yet the reasoning behind it is recorded nowhere. More software gets created, so there is more to maintain.

3. The real loss is context between stages, not within them. Requirements, design, development, testing and deployment have each matured on their own. The gap is what happens between them. A small change ripples from design to code to tests to deployment, and when parts of the code came from a prompt, tracing that ripple gets much harder. Teams spend more time working out what is already there than improving it.

4. Treat engineering as a connected loop. Understand the need and the system, analyse, decide, build, validate, and capture what was learned so the knowledge stays with the software. The goal is for context to survive however the code was originally written.

5. AI is most valuable for understanding code, not only writing it. AI can surface relationships and dependencies that are hard to see, and help engineers make better decisions in a system they didn't build. Software can help engineers understand software.

6. Debt isn't only in the code. The demo covered several sources of debt: code quality, database structure, security vulnerabilities, live production errors, and drifting or vulnerable packages. For example, an unclear timer interval may work fine for 10 or 20 users and cause memory pressure at scale. A shortcut like that is easy to miss, and easy for a junior developer to introduce without knowing.

What we showed in the demo

Using a real project built largely with vibe coding, we connected a code repository and a database and ran a scan. The scan returned roughly 1,500 debt items from the code and 67 from the database structure. It combined established static and AST analysis tools with AI, rather than relying on AI alone.

From there, each finding followed one path:

• Grounded plan: a plan to fix it, written with knowledge of the exact lines, the related requirements and the existing tests, so only the relevant context is sent to AI.
• Human review: a lead reviews the plan and decides whether to send it to a release. Debt, bugs and features all go through the same release flow.
• Automated fix: once the release is active, the fix is built against the latest code and merged along your existing CI/CD path.
• Human gate: you choose where a person must approve, for example requiring a human merge after the development branch.
• Tests: acceptance criteria were generated by AI, validated by a human, and turned into automation tests that run as part of the release.

The same flow covers security findings such as SQL and log injection, live log monitoring (CloudWatch, Sentry, Datadog, New Relic, Grafana and others, checked every 10–30 minutes, before a user reports the problem), and outdated or vulnerable packages. In live projects, scans run as each release completes, so new debt is found and fixed before it reaches production.

Audience questions

Is every messy piece of code really "debt"? What about code that hasn't changed in years and never breaks? Not necessarily. Findings are grouped into recommendations, insights and debt, and classified by type: performance, quality, security or design pattern. Severity is deliberately left to a person, who decides whether to act. As Dave put it, it depends on the context: a stable legacy module behind 30% of your revenue carries different risk than one with a documented workaround. That is why a human stays in the loop at each step, even with 50-plus AI agents in the toolchain. Over time, signals such as the same issue appearing in many places, or a line of code linked to a production CPU or memory problem, could add criticality as a hint.

Does it integrate with Linear, Jira, Azure DevOps and Grafana? Jira and Azure DevOps both have two-way sync. Linear is straightforward to add. Observability integrations include Grafana, Alert Manager, OpenSearch, Elastic APM, New Relic, Datadog, Sentry and Azure Monitor.

Can it work from an existing ticket and figure out the code change? Yes. A ticket or a support message can be read, classified (code change, data issue, or a question), and turned into a draft response or a ticket. Whether the response is sent automatically or by a person is configurable.

Other points worth keeping

• Controlling AI cost. Most conversations about AI start with token bills. Because the platform builds a knowledge graph of the code, requirements and tests, much of the analysis happens before anything is sent to a model, and only the relevant context goes to the LLM. Dave quoted costs in the range of tens of dollars per project per month.
• Different people need different views. With the knowledge in one place, the system can answer by role. A business analyst gets user-level documentation, and an architect gets APIs and database layout. This matters most in larger teams, or wherever people move on.
• Debt isn't only a coding problem. Gaps in documentation, requirements and QA create the same kind of debt, and a shared knowledge base helps with all of them.

Want to talk it through?

If you're carrying legacy code, inheriting a vibe-coded project, or trying to keep AI-assisted development under control, get in touch and we'll walk through your situation.