Can Anyone Maintain AI-Written Code? What the Research Shows and Does Not

The honest answer is: it depends on the code, the team, and whether anyone has reviewed it. AI coding tools generate code that frequently passes its own tests and looks structurally reasonable at a glance. What the research shows is that a meaningful share of AI-authored commits in public repositories introduce static-analysis issues, mostly code smells, and that about a fifth of those issues are still present in the latest version - real but not always fatal. The question to ask about your codebase is not "was it written by AI?" but "has anyone who understands the product read it end to end?"

What the "Debt Behind the AI Boom" Paper Actually Found

The paper "Debt Behind the AI Boom" (Liu, Widyasari, Zhao, Irsan, Chen and Lo; first submitted to arXiv on 30 March 2026, latest revision 13 October 2026) built a dataset of about 302,600 verified AI-authored commits from 6,299 GitHub repositories across five AI coding assistants. Running static analysis before and after each commit, it found 484,366 distinct issues, of which 89.3% were code smells. Between 7.5% and 14.8% of each assistant's commits introduced at least one issue, and 22.7% of the tracked AI-introduced issues still existed in the latest version of the repository. The arXiv page does not state a peer-reviewed venue, so treat it as a preprint.

Code smells are structural patterns that make code harder to read, test, or extend. They are not bugs. A function that is 400 lines long is a code smell; it might work perfectly. A module with 20 dependencies is a code smell; it might be intentional. The reason smells matter is that they tend to make code more expensive to change. Code that is hard to read is code that is hard to change safely.

The Important Caveat: Who Is in the Dataset

The dataset only contains commits the authors could verify as AI-authored in public GitHub repositories. That is a selection effect: developers whose AI use is visible in the commit history may work differently from those who edit AI output heavily before committing, and private codebases are not represented. The paper's figures describe those commits, not every AI-assisted project.

This does not invalidate the finding. It refines it. The 7.5% to 14.8% range is a signal about visible AI-authored commits in public repositories, not a universal claim about all AI-assisted coding, and the paper does not compare against human-authored commits in the figures quoted here.

What Code Smells Look Like in Practice

In the AI-built apps we review before launch, the structural patterns that appear most often are not the ones that show up in a static analysis scan. They are subtler than hardcoded secrets or missing input validation. The most common are:

Long functions that do three or four unrelated things, usually because the prompt described a feature end to end and the tool generated a single handler for it
Duplicated logic across routes or components, because each prompt was independent and the tool had no memory of the previous answer
Data fetching and business logic mixed in the same file, making it impossible to test either in isolation
Inconsistent patterns for the same operation: one API route validates with Zod, the next does not, because different prompts produced different implementations
No error handling on async operations that can fail in production but not in a local demo
Naming that describes what the code does at the moment it was generated, not what it is supposed to do in the product - making it opaque six months later

None of these is a critical bug. Each one is a tax on every future change. A developer who needs to modify a 400-line function to change one behaviour risks breaking three others. A codebase where the same data-fetching logic exists in eight slightly different forms means any security fix has to be applied eight times, and if you miss one, the vulnerability persists.

What the Research Does Not Show

The paper does not show that AI-written code is unmaintainable. It shows that AI-authored commits in public repositories introduce issues, mostly code smells, a fifth of which persist. Human-written code accumulates debt too - software engineering research has documented this for decades. The question is the density and how much survives review.

The figures I could verify also do not tell us whether the 22.7% of issues that survive to the latest version are the severe ones or the mild ones. Survival is not the same as damage. A long-function smell that survives because it is stable and rarely touched is a different risk from a duplicated-validation smell that survives across a security-critical flow.

Vendor reports from AI coding tool providers tend to focus on developer satisfaction, PR merge rates, and time-to-first-commit. These are real metrics, but they measure different things from maintenance cost. Faster shipping of the first version does not predict whether the second developer to touch the code will be able to understand it. Treat vendor figures as evidence of adoption enthusiasm, not evidence of maintenance quality.

When Debt Becomes a Structural Problem

The practical threshold for "this codebase needs attention before adding features" is not a smell count. It is when two things become true simultaneously: the team cannot change anything without unexpected breakages, and the time spent understanding the code before changing it exceeds the time spent writing the change. At that point, the debt is no longer background friction - it is the primary constraint on development speed.

Apps inherited from another developer or from an AI tool after the founder stops prompting tend to arrive at this threshold faster than expected. The first developer (human or tool) had context. The next one does not. In a human-written codebase, some of that context survives in commit messages, comments, and naming choices. In an AI-generated codebase, the context existed in the prompts, which are not in the repository.

The Practical Question for Your Codebase

If your app was built primarily with AI coding tools (Lovable, Cursor, Bolt, v0, or similar), the questions that determine whether you have a maintainability problem are:

Has a developer who did not write the code read it end to end? If not, the structural debt is unknown.
Can a new developer make a change to one feature without understanding three others? If not, coupling is high.
Do changes to the app regularly produce unexpected bugs in unrelated areas? If yes, test coverage or module isolation is insufficient.
Is there a test suite that runs on every change? If not, refactoring safely is guesswork.

If the answer to all of these is uncertain, the codebase is not necessarily unmaintainable - but it has not been assessed. The assessment is what a rescue and launch review produces: a structured read of the code by someone who can distinguish between debt that is cosmetic and debt that will grow.

What a Review Produces

A technical review of an AI-built codebase produces three things: an honest debt assessment, a prioritised list of what to fix before adding features, and a recommendation on whether the architecture can absorb the growth the product needs. It does not always recommend a rewrite. Most of the apps we see have architectures that are correct in structure but inconsistent in execution - which is fixable with a targeted cleanup and a set of patterns the team agrees to follow going forward.

If you are uncertain whether your codebase has accumulated the kind of debt this research describes, the first step is to get a read. Start with the free code review for the structural signals, then reach out for a launch and rescue review if you need someone to go deeper into the architecture, the test coverage, and the data model before you commit to the next phase of development.

Common questions

Is AI-written code maintainable?

It depends on the code, the team, and whether anyone has reviewed it. Research on public repositories found AI-authored commits often introduce static-analysis issues, mostly code smells, and about a fifth of those issues are still present in the latest version. That is real but not always fatal.

What did the Debt Behind the AI Boom paper find?

It analysed about 302,600 verified AI-authored commits and found 484,366 distinct issues, 89.3% of them code smells. Between 7.5% and 14.8% of each assistant's commits introduced at least one issue, and 22.7% of tracked issues still existed in the latest version. It is a preprint.

How do I know if my AI-built codebase needs a review?

Ask whether a developer who did not write the code has read it end to end, and whether changes regularly break unrelated areas. If the answers are uncertain, the codebase has not been assessed. Zovintra offers a free code review and a launch and rescue review for deeper architecture checks.