Why Your AI-Built App Gets Harder to Change Every Week

Six months after launch, you ask for a small change: rename a field, add a filter, adjust the checkout. The estimate comes back in days, not hours. The fix breaks something unrelated. And nobody, including the person who shipped the original feature, can quite explain why.

The app still works. That is what makes this stage confusing: nothing is broken, exactly. The system has just become expensive to touch.

What is happening has a name, and in the past year it acquired real measurements.

What is AI technical debt?

It is the accumulated cost of code that shipped working and then got harder to change. With AI-written code the debt carries an extra layer: nobody on the team ever held the reasoning behind the code, so every later change starts with a stretch of reconstruction nobody budgeted for.

Classical technical debt is a familiar trade. A team knows the right way to build something, cuts a corner to hit a date, and pays interest until someone cleans it up. The debt was a decision, and somewhere in the building is a person who remembers making it.

An AI-built app accumulates a different kind. The tool produces working code faster than anyone absorbs it, which means you can ship an entire product without anyone ever holding the full reasoning. Addy Osmani, an engineering leader at Google who writes widely on software quality, gave the result its name this spring.

The distinction matters because the two debts fail differently. Classical debt announces itself: builds slow down, one module becomes the thing everyone fears. Comprehension debt breeds false confidence instead; the code looks clean and the tests stay green.^[3]

Osmani recounts researcher Margaret-Anne Storey's example of a student team that, by week seven, "could no longer make simple changes without breaking something unexpected." Not because the code was messy. Because nobody could explain why it was shaped the way it was.

This is also a different problem from inheriting a codebase someone else wrote. There, the understanding exists and has to be transferred. Here, it was never built at all.

Why does an AI-built app get harder to change every week?

Because generation is fast and understanding is slow, and the gap widens weekly. Each new AI-written layer builds on layers nobody fully understood, so assumptions compound while the shared map of the system never gets drawn. As of this year, that claim has measurements behind it.

In August, researchers at Google published the first study of this from inside a production codebase serving billions of users: 3.52 million code changes, tracked from April 2025 to April 2026, in an environment instrumented enough to watch every line.^[1]

Two findings carry this post. First, the share of code written by AI in that codebase went from 28.99 percent to 68.62 percent in a single year.

Second, the AI-written share had a distinct quality profile: a heavier interface and coupling burden (code more entangled with the code around it, which is precisely what makes change expensive) and real running costs, 5 to 8 percent more compute and memory growth for the same work.^[1]

Two honest caveats. It is a preprint, and it measured one company's C++ at enterprise scale, so it generalizes to "a large codebase under heavy AI authorship," not to every weekend project. The direction of the finding is the point: the entanglement that makes software hard to change showed up exactly where AI wrote more of the code.

The same study measured the human toll: AI-authored changes drew 1.92 times as many blocking review comments, the feedback that must be resolved before code ships. Someone is absorbing that friction on every team. We have written about why the review layer is the control point in AI-assisted work; this is what it costs when the layer holds.

Who ends up maintaining AI-written code?

Mostly people. A peer-reviewed study of 100 popular open-source projects found human developers performing the large majority of later maintenance on AI-generated files: 83 percent of the follow-up commits were made by humans, not agents. The tool writes the file. Someone on your team owns it.

The study, presented at a software engineering conference this year, matched 508 AI-generated files against 508 human-written ones.^[2]

One honest nuance: AI-generated files were touched less often overall. So the finding is not "AI code needs more fixing." It is about ownership: when an AI-written file does need a change, five times out of six a human makes it, in code no human wrote.

That is comprehension debt collecting its interest. The person making that one-in-six-weeks change is reconstructing reasoning that never lived in anyone's head.

Can a better model or a better prompt fix it?

The evidence says no. A systematic audit of technical debt in AI-generated software found that code volume is a near perfect predictor of structural decay, and that neither functional correctness nor more detailed prompting mitigates it.^[4] Generating more code, faster, with better instructions makes the fog thicker, not thinner.

That result should reframe the instinct most teams have when the friction starts, which is to point the tool at its own mess. The tool can produce a cleaner-looking version. What it cannot produce is the understanding that makes the next change safe.

Understanding is not an artifact a generator emits. It lives in people, or it does not exist.

What actually fixes it?

Human understanding, applied where change actually happens. Not a rewrite, and not a tooling purchase: a review habit that asks whether the team understands each change well enough to alter it safely, and steady refactoring of the parts of the system you touch most.

The practical version, for an owner who cannot read the code:

• Ask which parts of the app changed most in the last quarter. Those areas need to be genuinely understood by someone on your side, and covered by tests. Stable corners that nobody touches can wait.
• Make "do we understand this?" a merge question, not a post-incident question. Correctness review catches bugs; comprehension review preserves the ability to change.
• Treat rising estimates as a signal, not a negotiation. When two-hour changes become two-day changes, the fog is telling you where it is.

Comprehension debt is one of the quiet forces that makes the move from prototype to production harder than it looks, and surfacing it is part of what an outside read of production readiness is for: finding the opaque zones before they set the timeline for you.

The teams still moving fast in year three will not be the ones that generated the most code in year one. They will be the ones that kept enough understanding to keep changing what they built. The debt compounds either way; the only real choice is paying it down while the changes are still cheap.