The Technical Debt AI Writes at Machine Speed

Every engineer on our team ships AI-assisted code, every day. So this is not a warning from the sidelines. It is what we learned cleaning up after our own agents, and then learning to stop making the mess in the first place.

The pattern is always the same. A codebase a few months old, shipped fast with an agent doing most of the typing, already reads like a system years into its life: three ways to do the same thing, tests that pass without asserting much, whole files nobody can quite explain.

The build is green, the diff read cleanly, the feature works. And every signal you were trained to trust is pointing the wrong way.

The signals you trust are inverted

Old technical debt announced itself. The code was slow, buggy, hard to change, and the team could feel it because they had watched it pile up one deadline at a time.

This debt hides behind the signals you use to tell healthy code from rotting code. It shipped fast, so it looks productive. The suite is green, so it looks safe. The diff was readable, so it looks considered.

None of those signals measures the thing that is decaying. Understand why, and the fix stops being mysterious.

Technical debt was always a trade, not a mess

Ward Cunningham coined the debt metaphor in 1992. Shipping something imperfect now is like borrowing money: it buys speed today and charges interest until you repay it. Taken on deliberately, debt is a financing decision, not a failure.

Martin Fowler later mapped it onto a quadrant with two axes. One is deliberate versus inadvertent: did you know you were taking on the debt? The other is prudent versus reckless: was the trade worth it?

Good teams live in the deliberate, prudent corner. They pick a shortcut on purpose, name it, and plan the payback. The debt that hurts is the inadvertent kind, the debt nobody chose and nobody is tracking.

An agent lives in the quadrant nobody chose

This is the part worth sitting with. An agent cannot take on deliberate debt, because it does not know it is taking on any. It has no model of the trade, so it never records one.

Give it a feature and it regenerates a variant of code that already exists two directories over. Now you have a fourth near-identical validator, and a bug fixed in one survives in the other three. Nobody decided that: it is reckless-inadvertent debt, produced at agent speed.

Even the honest kind multiplies. Strong teams write prudent-inadvertent debt all the time: pick an abstraction, learn it was wrong, refactor. With an agent, five sessions solve five similar problems five different ways before anyone learns which shape was right, so you refactor five things instead of one.

The data is not subtle about it. A 2026 study of AI-generated code in the wild, across 302,600 AI-authored commits in 6,299 repositories, found more than 15% of AI commits introduce at least one issue, and 22.7% of the issues it catalogued were still unfixed at each repository's latest version. GitClear's 2026 analysis shows the same shape from another angle: duplicated code climbing sharply while refactoring sits at historic lows.

More gets written, less gets reworked, and almost all of the debt is the kind nobody chose.

You can't review your way out of a generation problem

The obvious response is to review harder. It is also where most teams get stuck, and the reason is arithmetic. Review used to run at human typing speed and roughly kept pace; an agent produces far more code per week than that same process was ever sized to inspect at depth.

Addy Osmani, tracking AI adoption at Google where more than 30% of code is now AI-generated, names the shift plainly: the model gets you most of the way fast, and the hard remainder, edge cases, security, fit, lands on the reviewer. The bottleneck moved. Most review processes did not move with it.

But throughput is the smaller issue. The bigger one is that review is downstream of the mistake. By the time the fourth validator is in the diff, the debt already exists, and catching it only earns you a rewrite.

An agent lands in the inadvertent quadrant for one reason: it works from a narrow context, the file in front of it and your prompt, and cannot see the abstraction you already have or the boundary you meant to hold. Widen that context and most inadvertent debt is never written.

That widening is a design act, and it is the highest-value work in AI-assisted development. This is what it looks like in practice.

• 1Design before you generate. For anything past a trivial change, decide the shape yourself first: which module owns this, which existing abstraction it reuses, where the boundary sits. A two-line design note in the prompt moves the task from the inadvertent column into the deliberate one before a line is written.
• 2Point the agent at the canonical implementation. "Use the validator in core/validation, do not write another" is an instruction, not a hope. Reuse only happens when you name the thing to reuse.
• 3Put the house rules where the agent reads them. Standing rules files, Claude Code's CLAUDE.md, Cursor's .cursor/rules, GitHub Copilot custom instructions, are where you write the layering, the naming conventions, and the allowed dependencies. An agent follows the architecture when the architecture is written down in the place it actually looks.
• 4Scope each task to one boundary. A task that touches one module through a defined interface cannot drift far. A task phrased as "build the feature" will invent its own architecture, and it will invent a different one next week.
• 5Treat well-factored code as an input, not just an output. This is the counterintuitive one Thoughtworks captures in AI-friendly code design: agents write cleaner code inside clean, clearly-bounded code. The architecture you hold today is the guardrail for everything the agent writes tomorrow.

None of this is exotic. It is the deliberate quadrant, operationalized: you stop hoping the agent chooses well and start removing the choices that create inadvertent debt.

The review net you still need

No upstream discipline is perfect, so keep the merge-time net, sized for machine-speed output rather than for a human who reasoned through every line.

A green build answers one question about a diff. We have written about why tests can pass while production breaks and about the five lenses that cover the rest, and for this debt the one that matters most is maintainability: can a human safely change this next? Keep batches small, because a large AI-written pull request hides every failure mode above while a small one exposes each while it is still one edit to fix.

The trap to name out loud is complacency. Thoughtworks put "complacency with AI-generated code" on Hold, warning that "AI-driven confidence often comes at the expense of critical thinking." The rationalization that quality matters less now because AI will handle the next change gets it backwards, because agents do worse on sloppy code, not better.

When this isn't worth your afternoon

Not all of this earns the effort. If the code is a genuine throwaway, a prototype you will demo and delete, or an internal tool with a known end date, skip the discipline. Debt only charges interest on code that has to live.

And it does not have to be us. If you have the design judgment and the review muscle in-house, run this yourself; the frameworks in these posts are meant to be usable without hiring anyone. The teams that reach out are usually the ones whose generation has outrun a review process built for human output.

The half you can measure is the easy half

Everything above is the technical debt you can see. It shows up in a duplication report, a security scan, a churn number, and that visibility is what makes it manageable, once you move the work upstream to generation.

The expensive half never shows up in a scan, because it does not live in the code. It lives in your team's heads, in the shared understanding of why the system works the way it does, and it drains faster and more quietly than any metric. That is cognitive debt, and it is the subject of Part 2.

The code is arriving faster than ever. Whether it arrives as an asset or as interest you will pay later comes down to how much you decide before the agent starts typing, and how honestly you read what it hands back.

AnAr Solutions engineers AI-assisted software delivery for product teams, with a design-first discipline that keeps AI from writing debt nobody chose. The rules and the five-lens review above grew out of production delivery work, not a slide deck.