Léo Antunes

Posted on Oct 23

Technical Debt in the AI - Weekly Reflections #3

#ai #architecture #softwareengineering #technicaldebt

This post is based on an internal presentation of the same name that I presented at the company I work for. The talk has two parts. This first part is about understanding the problem: what Technical Debt is, what the data says about AI, and the kind of debt I think AI makes more expensive. Part II, about managing debt, will be a handled in a future Weekly Reflection.

What Technical Debt is

The definition I use comes from Kruchten, Nord and Ozkaya (2012): Technical Debt is the cost of past decisions that makes software harder to change. Two words matter there. "Past" means it comes from decisions we made, or from time passing and the context changing. "Change" means its cost shows up when we try to change the software.

This is why debt matters for stakeholders to: Software delivers new value only when we change it: new features, fixes, improvements. If it's hard to change, every change takes longer and carries more risk, so customers get less from us.

The Economic View helps here. Tech Debt works like a loan. As long as nobody touches the code, it costs nothing. But, when the system needs to change, debt adds friction: more time to understand the code, test it and ship it. That friction is the Interest, and we pay it on every change the debt touches.

How much Interest? In a study, Besker, Martini and Bosch found developers lost on average 23% of their working time to Technical Debt, about one day a week. The most common way that time was lost was extra testing. The numbers are self-reported, but they're a useful order of magnitude.

A few more ideas shaped the rest of the talk:

Debt comes from three places. Deliberate Debt is the shortcuts we do to hit a deadline. Accidental Debt comes from missing knowledge, weak processes or no quality checks. External Debt is the interesting one: nobody made a mistake, but the context changed, and a choice that was right is no longer right. AI is that kind of change.

Some debt costs us even when nobody touches the code. An unpatched dependency is a security risk. Fragile infrastructure causes outages. A missing validation lets data become inconsistent. A slow query gets worse as data grows. And sometimes a feature simply can't be built until a debt is paid.

Debt isn't only in the code. Alves et al. (2016) list more than a dozen types, including architecture, documentation, process, test automation, and Build and Infrastructure Debt. The last two are about how we verify and ship changes, not how we write them. Those are the ones I think AI makes more expensive.

Mostly engineers see it. In Kruchten's Four-Colour Backlog, Technical Debt is negative value that's invisible to customers and stakeholders. They see its effects, slower delivery and more defects. Mostly engineers see the cause. That's a big part of why debt is hard to discuss with product and business.

"AI can fix any messy codebase"

This is the objection I hear most. Part of it is true: writing a fix is cheaper than ever, and AI can refactor a module in minutes. But every change still has to be reviewed, tested and released safely, and in a messy codebase that's the hard part, because nobody is sure what a change might break.

Messy code also produces more mess. AI copies the patterns it finds, good or bad. So debt doesn't go away; its cost moves from writing the change to proving the change is safe.

What the data says

The one sentence I'd keep from the data: we write code faster, it doesn't reach production faster, and what does reach it is less stable.

In 2025, Faros AI looked at 10,000 developers. Teams with high AI adoption merged 98% more PRs, but review time went up 91%, PRs got 154% bigger, and bugs per developer rose 9%. Company-level delivery didn't improve.

A year later, their Q3 2026 report covers 22,000 developers. Deployments are rising again, but the cost moved downstream: PRs are 72% bigger, PRs merged with no review are up 76%, time in QA is up 300%, and monthly incidents are up 125%.

GitClear's June 2026 report compares 623 million code changes from 2023 to 2026, a period in which AI-assisted commits went from 0.5% to about 24%. Duplicated code blocks are up 81%, code that hides errors (like broad catch blocks) is up 47%, and refactoring is down 70%. We write new code instead of reusing and improving what we have.

Faros and GitClear are industry studies, not peer-reviewed. DORA is the strongest source, and it points the same way.

Looking at the GitClear numbers, I think we also have what I'd call "AI Debt": we adopted AI tools faster than the setup that helps them write good code. Most repos have no shared instructions telling an agent our patterns and what to avoid, like an AGENTS.md. Few have fast tests an agent can run to check its own work. And we don't have CI checks for AI's usual mistakes, like duplication or swallowed errors.

Does code quality still matter if AI writes the code? Until review is fully automated, yes. People still review, debug and change it, and duplicated, hard-to-read code makes every one of those steps slower.

Verification Debt

From here on, this is my interpretation of the data, not science.

A pipeline moves only as fast as its slowest step. Before AI, writing code was one of the slowests steps, and review, testing and release were sized for that pace. Now writing is fast, and the slowest steps are review, QA and release. That matches the numbers: more PRs, longer reviews, no faster delivery.

Verification Debt isn't new. Manual QA, manual checks before a release, reviews that depend on one person knowing the system: we always had them. Before AI, we paid that Interest at human speed, a few changes at a time. Now there are many more changes, and each one still goes through the same manual checks. AI didn't create this debt. It multiplied the Interest on the one we already had.

An example from my team

My team needed to upgrade a major version of Django on an integration service we had inherited. It's in our most critical service tier, and it forwards data events to six external integrations, each with its own rules for what to send and when to stop.

AI wrote the upgrade fast. Proving it was safe to release was the Bottleneck. There were no component or end-to-end tests we could run before production, and since we had inherited the project, we first had to discover what we needed to test. We had an Automation Test Debt. So we paid it.
We wrote Component Tests, which test the whole service through its public interface only: send event request to the API, assert the right update goes out. The suite runs with one command in about 16 seconds, locally or on QA, and anyone can run it, AI agents too. It took less than a day to build, with AI doing most of the writing. Writing tests has never been this cheap. So why not write them?

Writing the tests was also how we learned the system. Every test answered a question about a project we hadn't written, and that's how the team took ownership of it.

With the check in place, we stopped batching the work into one big, risky PR. We shipped six small stacked PRs and six production releases one after the other. The component tests was the safe-guard between each merge and release.

Paying Verification Debt more broadly

Unit and integration tests automate Functional Requirements: given this input, do we get this output? Production incidents mostly come from Non-functional Requirements, and those we mostly check by hand. Examples are N+1 queries (a loop that makes one database query per item), missing timeouts that cause cascading failures, retries without limits that make an outage worse, large data volumes, and migrations that lock tables or lose data.

The practices that automate these checks used to be too expensive for most teams to justify. AI makes writing tests, tooling and pipelines much cheaper, so they're affordable now, and with more changes coming in, we need them. I group them in two layers:

Before review, catch known risks: Guardrails in CI that block requests without timeouts, growing query counts or risky migrations; performance and resilience tests; QA environments with realistic data.
After merge, limit the damage: small batches, feature flags, canary rollouts (releasing to a small share of traffic first), automatic rollback, SLOs with alerts, and chaos tests to prove we recover.

The rule of thumb I ended up with: if a machine can check it, a human reviewer shouldn't have to. Reviewers can then spend their time on architecture, design and business logic.

Looking back

Most of this talk is built on other people's data, and I tried to be clear about where the data ends and my opinion begins. The part I'm most confident about is the small example: a test suite built in less than a day removed a manual check from every release. AI made writing the change cheap, and it made writing the check cheap too. The shift I'm proposing is that people stop checking every change by hand and start owning the checks that do it.

The question I left open is the hardest one: with a lot of debt and a full roadmap, what do we pay first? That's Part II.

DEV Community