Your AI-Built MVP Works. That Is the Problem.

We get a version of this call about twice a month now.

A founder built a product in six weeks using AI coding tools. It works. Users signed up. Then something broke in a way nobody could explain, or a fix in one place broke three others, or an investor asked for a security review and the room went quiet. The product works. Nobody can safely change it.

This is not a story about AI being bad at code. AI coding tools are extraordinarily good at producing code that runs. The research from the last two years points at a narrower and more uncomfortable problem: code that runs is not the same as code that can be maintained, and the gap between the two is now measurable.

What the data actually shows

GitClear's research analysed 211 million changed lines of code from 2020 to 2024 across private repositories and 25 of the largest open-source projects. Two findings stand out.

First, refactoring collapsed. The share of commits representing refactoring work — consolidating logic, extracting shared modules, reusing what already exists — fell from around 25% to under 10%. Second, duplication exploded: an eightfold increase in blocks of five or more lines duplicating adjacent code. In 2024, for the first time on record, more code was copy-pasted than moved.

A follow-up study covering 623 million changes through 2026 found duplication up 81% compared to pre-AI baselines, with code reuse down significantly — a measurable shift away from shared libraries. As GitClear's CEO put it, the tool creates a new package every time you want something, and that approach has consequences.

The security picture is worse. Across independent studies, roughly 40–45% of AI-generated code contains a vulnerability mapping to the OWASP Top 10. Google's DORA research found that each 25% increase in AI usage correlated with a 7.2% decrease in delivery stability.

And the productivity gain is less certain than it feels. A randomised controlled trial by METR found experienced developers were 19% slower using AI tools — while believing they had been 20% faster. In Stack Overflow's survey of tens of thousands of developers, 84% reported using AI coding tools while only 29% said they trusted the output, and 66% named "almost right, but not quite" as their top frustration.

Note what those numbers describe. Not failure. Invisible cost.

Why AI debt behaves differently

Traditional technical debt is a decision. Someone says "we'll skip the tests for this sprint and come back," and everyone knows a loan was taken.

AI-generated debt accumulates without anyone deciding anything. The mechanism is simple: a model asked to solve a similar problem twice will emit similar-but-slightly-different code twice, rather than extracting a helper. Do that five hundred times and you have a codebase where the same business rule exists in eleven places with subtle variations, and no one — human or agent — can enumerate them.

That is why duplication is the metric to watch. Duplicated code is the interest rate on the debt. Every copy has to be maintained everywhere on every change, and the bugs it produces surface months later, in production, under load.

The audit: eleven questions worth asking your codebase

Before you scale an AI-built product, run these. Most are cheap.

Structure

1. What is your duplication percentage? Run a structural clone detector like jscpd, which covers 150+ languages and catches near-duplicates that string matching misses. GitClear's industry average crossed 12% in 2024 — use that as a flag threshold, and track the trend rather than obsessing over the absolute number.

2. How many places does your core business rule live? Pick your single most important piece of logic — pricing, permissions, whatever it is — and grep for it. If the answer is more than one, you have found your first refactor.

3. What is your two-week churn rate? What fraction of code written is reverted or rewritten within a fortnight? Rising churn means what you build today gets rebuilt tomorrow, and you are paying twice.

4. What is your moved-to-added ratio? Of all changed lines in a sprint, how much is consolidation versus net-new? A ratio approaching zero means nothing is being cleaned up. Security

5. Is authorisation enforced at the database layer? This is the big one. The Lovable platform incident (CVE-2025-48757) exposed emails, payment data and API keys across 170 of 1,645 scanned applications because row-level security was missing. AI-generated apps routinely enforce access rules in the UI and forget the database underneath.

6. Are secrets in the repository? Run a scanner. You will be surprised more often than not.

7. Is every input validated server-side? Client-side validation that a model helpfully generated is not validation.

8. Have you run a dependency audit? AI-suggested packages include deprecated and occasionally hallucinated ones. Operations

9. Can you explain your data model to a new engineer in ten minutes? If not, neither can an AI agent working in your repo — and it will make things worse trying.

10. What is your test coverage on the paths that touch money or personal data? Not overall coverage. Those paths specifically.

11. Is there a single person who understands the architecture? Not the code — the architecture. If the answer is no, that is the actual finding.

What to do with the results

The instinct after an audit like this is to propose a rewrite. Resist it. Rewrites of working products fail far more often than they succeed, and the AI-built codebase usually contains real product knowledge that a rewrite discards.

What works better, in the order we generally run it:

Stabilise first. Fix the security findings. Row-level security, secrets, input validation. These are contained problems with clear endpoints, and they are the ones that end companies.

Then draw the boundaries. Identify the two or three domains the system actually has, and define the interfaces between them. You are not restructuring the code yet — you are deciding what the structure should be.

Then consolidate the duplication that matters. Not all of it. The duplicated code that sits on your critical paths and gets touched every sprint. Duplication in a settings page nobody edits can wait indefinitely.

Then add tests at the boundaries you just defined, so the next round of AI-assisted changes has a safety net that catches "almost right, but not quite."

Then keep using AI tools. This is the part that surprises people. The answer is not to stop. The heaviest AI users out-produce non-users substantially. The answer is that AI-generated code is a starting point and never a finished product — it needs an architecture to land in, a review that someone qualified owns, and automated scanning on the way to production.

What good governance looks like going forward

Three rules keep AI velocity without the compounding cost:

• A human owns every merge. Not reviews it — owns it. Can explain it, and will be the one paged when it breaks.
• Architecture decisions are made before generation, not after. The model fills in a design; it does not produce one.
• Duplication and churn are tracked as dashboard metrics, alongside velocity. What you do not measure, you do not notice until the rewrite quote arrives.

The short version

AI coding tools produce working code at unprecedented speed, and the 2026 research is consistent that maintainability is paying for it: duplication up eightfold and then 81% above pre-AI baselines, refactoring down from 25% of commits to under 10%, 40–45% of generated code carrying an OWASP-class vulnerability, and a randomised trial showing experienced developers 19% slower while feeling faster. The cost is invisible at the point of creation and arrives later as maintenance overhead, security incidents and rewrites. Audit for duplication, database-layer authorisation and two-week churn before you scale. Stabilise security first, draw domain boundaries second, consolidate the duplication that sits on critical paths third — and keep the AI tools, inside a governance layer that can catch what they get almost right.

If your product was built fast and you are not sure what it is standing on, we run a fixed-scope code and architecture audit that returns a prioritised remediation plan — not a rewrite quote.