AI Technical Debt Is Two Debts Your Team Is Not Tracking

AI technical debt is not the mess you think it is. It is not just duplicated functions and inconsistent naming that a linter can flag. Half of it looks completely fine in the pull request, passes review, ships, and only shows up six weeks later when nobody on the team can explain why a change in one place broke three things nobody expected. That second half is the part most teams are not measuring at all.

AI Technical Debt Is Two Different Problems, Not One

Ask five engineering managers to define AI technical debt and you get five answers, but they tend to cluster into two very different buckets.

The first is code debt: duplication, inconsistent patterns, code that is technically correct but adds surface area nobody asked for. This is the bucket static analysis tools were built for.

The second is cognitive debt: the gap between how fast code gets generated and how fast the team actually builds a shared mental model of what it does. Sonar's 2026 developer survey found that 88% of developers report at least one negative impact of AI on technical debt, and 53% say AI generates code that looks correct but introduces hidden defects. That is code debt. What the survey does not fully capture is the second kind, and LeadDev's reporting on the concept is the clearest treatment of it we have read.

Three teams out of five conflate the two. Here is what the other two do differently: they track code debt with tools, and they track cognitive debt with conversations.

The Code Debt Part: Code That Looks Right and Isn't

Code debt is the familiar kind. AI-generated code tends to duplicate logic that already exists three files over, because the assistant does not know the logic exists unless it is in context. Sonar's survey puts a number on it: 40% of developers say AI has increased debt by generating unnecessary or duplicative code.

The dangerous variant is not the code that looks wrong. It is the code that looks right. A function passes its tests, handles the happy path cleanly, and reads like something a senior engineer would write, except it silently drops an edge case the original implementation handled. Review catches typos. Review is much worse at catching a plausible-looking function that is subtly incomplete.

// AI-generated: passes tests, looks clean
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// What the original handled, three files away:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}

Nothing here throws an error. Nothing fails CI. The gap only shows up when a soft-deleted user reappears in a report three weeks later, and whoever gets paged has to grep, blame, and ask around to find out which version is correct and why. That grep-and-ask loop is the actual cost, and it is measurable in hours, not in a vague sense that something feels off.

Docs-as-code tools that sit next to the repo rather than in a separate wiki reduce how often that loop happens, because the reasoning behind a function lives one click from the function itself instead of in someone's memory.

The Cognitive Debt Part: When the Team Loses the Plot

Dr. Margaret-Anne Storey, professor of computer science at the University of Victoria, coined "cognitive debt" in October 2025 after watching her students ship fast with AI and then struggle to act on their own user feedback. Her diagnosis: the students had not lost track of the code, they had lost track of what they were building and why, and who on the team knew what.

That framing borrows from Peter Naur's old argument that software is not really the code, it is the shared theory in the heads of the people who built it. When code gets generated faster than the team can build that theory, the theory never forms. You can have a clean, fully tested codebase and still have significant cognitive debt if the people who shipped it cannot fully explain it, or if only one person can.

This is the part standard AI technical debt metrics miss entirely, because dashboards track the code, not the understanding. The question worth asking in your next retro is blunt: put up an architecture diagram, and ask who on the team can explain each box. If the answer is "one person, and they are on vacation this week," you have cognitive debt regardless of what your linter says.

A living internal wiki does not fix cognitive debt by itself. It gives the team a place to write the "why" down before it lives in one person's head only, which is a start.

Why Code Review Can't Keep Up With Generation Speed

Here is the mechanical problem underneath both kinds of debt: AI lets a single engineer generate a week's worth of code before lunch, but review capacity has not scaled at all. The bottleneck moved from writing to reading, and reading is the part nobody sped up.

This is where the tool comparison actually matters, and it is worth being specific instead of vague. Copilot and Cursor are fast at generating code inside the file you already have open, which is exactly why they are good at producing more code than a team can review. Cody and Continue.dev lean more on retrieval across the repo before generating, which helps avoid the duplication problem above, but neither replaces the human step of deciding whether new code fits how the system is supposed to work. None of them tell you whether the person merging the PR actually understands what changed, which is a different question than whether the diff is syntactically fine.

Ask-your-codebase tools exist because of this gap specifically: the fastest way to review AI-generated code well is to be able to ask, in plain language, "where else does this pattern exist" or "what already handles this case," before you approve the merge. That question used to take a senior engineer twenty minutes of grep and blame. It should not.

There is also a repo-size effect worth naming. On a 5,000-line service, one reviewer can hold most of the system in their head, so a plausible-looking function stands out because it does not match the reviewer's mental model. On an 80,000-line monorepo touched by six teams, no single reviewer has that mental model anymore, so plausible-looking code sails through simply because nobody in the room has the context to notice it is wrong. The bigger the repo, the more the review bottleneck depends on tooling instead of one senior engineer's memory.

Juniors Pay This Debt First, and Fastest

Anthropic ran a controlled study in January 2026, a randomized trial with 52 junior developers, and found that those who used AI assistants scored 17% lower on code comprehension tests, roughly two letter grades. Infobip's internal engineering team, running an internship program since 2022 across 225 interns, saw the same pattern in real longitudinal data: pre-AI cohorts grew an average of 2.50 points in self-assessed technical skill over an internship; AI-era cohorts grew 1.56.

The mechanism is not AI use itself. Two interns in Infobip's most recent cohort used AI at the same frequency, with opposite outcomes. One asked follow-up questions and could fully explain what the AI produced; their growth was the highest in the cohort. The other accepted output with minimal review, treated it as a black box, and grew by zero. The tool was identical. The relationship to it was not.

Recording pairing sessions and architecture walkthroughs, and making them searchable afterward, gives juniors something to return to instead of re-asking the same question to whoever is free. It will not replace a mentor, but it lowers the cost of asking twice.

Skip the "Ban AI for Juniors" Fix

Every roundup on this topic lands on the same recommendation eventually: restrict AI access for junior engineers until they have "earned it." Skip that one. It does not match what teams that actually measured the problem found, and it trades one failure mode for another; juniors who cannot use the tools their team ships with fall behind in a different, equally real way.

What worked for Infobip instead was sequencing, not banning: try the problem first, check with AI second, so the habit of independent thinking forms before AI becomes the default move. They added AI-free checkpoints, not as punishment but as calibration, so both intern and mentor know where skill actually stands. Mentors also shifted from reviewing pull requests to tracking process: who asked what, who got stuck where, who explained their own change without help.

Satisfaction scores rose the entire time skill growth was falling, which is the real warning in their data: if you are only tracking how people feel about the tools, you will not see this coming. Twenty percent of interns in Infobip's most recent cohort did not know what was expected of a junior engineer at their level in the first place, which made self-assessment close to meaningless. You cannot measure a gap against a reference point nobody wrote down.

What We'd Actually Change This Sprint

Start with the retro question above: who can explain each part of the system, out loud, right now. That single question surfaces more cognitive debt in ten minutes than any dashboard will.

For code debt, keep static analysis in the loop. Sonar's 2026 developer survey shows 70% of developers already use it, and teams running it report meaningfully better outcomes on rework cost than teams that skip it. That is not a controversial recommendation, it is just one teams skip when they are moving fast because the AI output looked done.

The toil AI removes from writing code does not disappear. Sonar calls this the "great toil shift": it reappears downstream, in managing debt and correcting AI output. Automating the recurring parts of that triage, flagging stale PRs, routing review requests, chasing follow-ups, frees senior time for the part that actually requires a human: deciding whether the team understands what it just shipped.

Measure trajectory, not satisfaction. A team that feels good about AI and cannot explain its own architecture in six months has not saved time. It has borrowed it, at a rate nobody wrote down.