Intro
Eight in ten AI-generated apps we’ve audited have broken deployment pipelines. Sixty-one percent expose security vulnerabilities. Not one had meaningful test coverage. All of them looked done — they ran in staging, demos went fine, the team was ready to ship.
That gap between “looks done” and “is actually understood by anyone on the team” has a name: comprehension debt, a term coined by engineer Addy Osmani to describe what happens when code volume outpaces a team’s ability to absorb it. We didn’t need the term to notice the pattern — we’d already seen it in 27 real AI-generated codebases before we read his piece. But it’s the right word for what we kept finding: not bad code, exactly, just code nobody could fully explain.
If you’ve shipped something with Cursor, v0, Bolt, or Lovable and it’s sitting in staging right now, this is worth ten minutes before you put your name on it in front of real users.
What Is Comprehension Debt?
Here’s what it actually looks like from the inside of a codebase we’re auditing: the client can tell us what the app does. They usually can’t tell us why it does it that way — why this API route handles retries but that one doesn’t, why there are two different auth patterns in the same repo. Nobody’s being cagey. They genuinely don’t know, because no human wrote most of it and no human has read all of it either.
That’s comprehension debt: the gap between how much code exists in a system and how much of it anyone can actually explain. Addy Osmani coined the term for AI-assisted engineering specifically, and it’s useful because it names something teams feel but rarely say out loud.
It behaves differently from the technical debt your team already knows how to manage:
- Technical debt tells on itself. Builds slow down. Dependencies tangle. Everyone knows which file makes the team wince.
- Comprehension debt hides. In our audits, the codebase usually looks fine — reasonable folder structure, consistent formatting, green checkmarks.
Zero of the 27 apps we reviewed had meaningful test coverage, and none of those teams thought that was the state of things until we opened the hood. The debt doesn’t show up as friction. It shows up as false confidence — right up until someone tries to change something small and can’t do it without breaking a part of the system nobody knew was connected.
That’s the moment it stops being an abstraction. For AI-built apps, we’re seeing that moment arrive at the worst possible time: right before launch.
Why AI-Generated Code Hides This Risk So Well
There’s a speed asymmetry at the core of this, and it’s been getting worse every model generation — from early tools like Cursor and Copilot through to today’s frontier coding models. Each generation writes more code, faster. None of that changes the fundamental constraint: a human still has to review it, and review speed hasn’t scaled with generation speed.
When a developer on your team writes code, the review process has always been a bottleneck — but a productive one. Reading a colleague’s PR forces comprehension. It surfaces hidden assumptions and spreads knowledge of the codebase across the team.
AI-generated code breaks that loop:
- The volume is too high to review at the same depth
- The output looks right — clean, well-formatted, syntactically correct
- That’s exactly the signal that used to mean “safe to merge”
Our own audits back this up in a specific way: 43% of the AI-generated apps we reviewed had duplicate logic sitting in the codebase, unnoticed, because nobody had reviewed closely enough to see the same problem solved twice in two places. That’s not a hypothetical failure mode. It’s what falls out when generation outpaces comprehension at scale.
One thing worth naming clearly, so this doesn’t read as alarmist: predictions about how fast this gets fully automated have consistently overshot.
- Geoffrey Hinton predicted in 2016 that deep learning would outperform radiologists within five years — it didn’t land on that timeline
- A 2025 forecast that AI would write 90% of code within months also didn’t play out as predicted
The trajectory toward more AI-generated code is real. The timeline for AI making human comprehension unnecessary keeps slipping.
That’s actually the point. You don’t need full automation to have a comprehension debt problem. You have one today, with the tools already in your stack, at whatever level of AI-assistance your team is currently using.
The Data: What We Found Auditing 27 AI-Generated Apps
Here’s what makes comprehension debt concrete instead of theoretical: we ran the audit ourselves.
In 2026, Pagepro reviewed 27 AI-generated Next.js applications — every one built by a real team using v0, Cursor, or Bolt. Not weekend projects. Working products, built by people who thought they were close to launch.
Here’s what we found underneath the surface:
| Issue | % of apps affected |
| Exposed security vulnerabilities | 61% |
| Duplicate logic | 43% |
| Zero test coverage | 0% had any coverage |
| Broken deployment pipelines | 80% |
Every one of these apps looked done. They ran in staging. Demos went fine. That’s precisely the comprehension debt pattern — the surface signals that used to mean “safe to ship” no longer correlate with whether anyone understands what’s actually happening underneath.
As our CDO Michał Wigda puts it:
“Tools like Lovable, Bolt or v0 can get you 70% of the way to a working application very quickly. But the last 30% — security, architecture, testing and reliable deployment — is what actually makes software safe for real users. That’s the part AI tools rarely solve, and where most AI-built apps quietly break down.”
That “last 30%” is comprehension debt, named differently. It’s not a hypothetical cost that shows up someday. In four out of five of these apps, it was already sitting in the deployment pipeline, waiting for the first real production incident to surface it.
Why Tests and Specs Won’t Save You
Zero of the 27 apps we audited had meaningful test coverage. But even in codebases that do have decent test suites, we still find production-blocking issues — because tests can only catch what someone thought to test for in the first place.
That’s the actual limit. 61% of the apps we reviewed had exposed security vulnerabilities: secrets committed to the repo, unsecured auth flows. Nobody writes a test asserting “this API key shouldn’t be visible in the client bundle,” because by the time someone would think to write that test, they’d have already caught the problem by reviewing the code directly. The failure isn’t a testing gap. It’s a comprehension gap that testing can’t retroactively fix.
Specs run into the same wall from a different direction. A common instinct: write a detailed brief first, review that instead of the code, trust the AI translated it faithfully.
- Translating any spec into working code involves implicit decisions — error handling, edge cases, how two features interact — that no spec fully anticipates
- A spec detailed enough to actually replace review is, functionally, the program itself — just written in a language that doesn’t execute
- At that point you’ve paid the cost of writing the software twice, and you still haven’t reviewed what got built
What this means practically: you can have full test coverage and a detailed spec, and still ship an app where nobody fully understands what’s running in production. We’ve seen it. Tests and specs are both necessary. Neither is a substitute for someone on the team who can look at the codebase and explain what it does and why.
How to Tell If Your AI-Built App Has a Comprehension Debt Problem
You don’t need an outside audit to get a first read on this. A few honest questions will surface most of it.
Three questions to ask your team
- Can anyone explain why a specific architectural decision was made — not what it does, but why it was built that way?
- If you removed the person who prompted the AI the most, could someone else safely modify the core logic tomorrow?
- When was the last PR merged without anyone reading the full diff?
What to check in the codebase
| Signal | What it looks like | How common we’ve found it |
| Duplicate logic | Same problem solved twice, in different places | 43% of audited apps |
| No rollback path | A bad deploy means live debugging, not a clean revert | 80% of audited apps had broken pipelines |
| Secrets in the repo | API keys or credentials committed directly, not env-managed | Majority of audited apps |
| Near-zero test coverage | Especially on paths touching money, auth, or user data | 0% had meaningful coverage |
One pattern is worth watching for on its own: the app has been “almost done” for weeks, and every fix reveals two more issues. That’s rarely a sign the app is unusually broken. It’s a sign nobody has a complete mental model of it — so every change is a probe into the unknown instead of a targeted fix.
None of this means using AI to build fast was a mistake. It means the fast part is finished, and the part that makes an app safe for real users — the part that was never going to be instant — hasn’t started yet.
Paying Down Comprehension Debt Before It Costs You
None of the fixes here require abandoning AI-assisted development. They require treating “the AI finished it” and “someone understands it” as two separate milestones — and closing the gap between them before real users show up.
The four steps that actually close the gap:
| Step | What it means | Why it matters |
| Audit the codebase for hidden risk | Go looking for exposed secrets, missing error handling, silent failure points, and pipelines that can’t roll back safely | You can’t fix what nobody’s found yet — most of these issues never surface until something breaks in front of a user |
| Fix what blocks production | Security hardening, environment separation, monitoring and alerting | Not everything needs fixing today. What blocks safe production use does |
| Refactor what won’t scale | Consolidate duplicate logic, reorganize the parts most likely to cause problems later | AI tools optimize for output, not maintainability — the code works today, changing it tomorrow is a different story |
| Walk the real user journeys | Test core flows under real conditions, verify performance on mobile and slow connections | This is the step that turns “looks done” into “is done” |
This is, deliberately, not a rewrite. The goal isn’t to throw out what you built and start over — it’s to make the 70% that AI got you to safe enough to put your name on, without losing the speed that got you there.
If that’s roughly where your app is right now — working in staging, someone about to review the codebase, no time for a three-month rebuild — that’s exactly the gap our AI Project Takeover service is built to close. We audit, fix what blocks production, and get it there in two weeks, or tell you honestly if the codebase needs a different path.
