A change that took an afternoon in your first month takes two days now. You open the file, you can’t tell what depends on what, and you’ve started avoiding whole areas of your own codebase because you don’t know what an edit will knock over. That avoidance is the real symptom, and it has a mechanism.
Most code is understood by its author on day one and decays from there. Prompt-built code skips the day-one step: nobody ever held the whole thing in their head, each generation was bolted onto the last, so the drift starts immediately and compounds. An AI-built app begins hard to change and gets harder every week. In the 26 apps AxonBuild audited in June and July 2026, at least 23 had zero working automated tests, so every change after the demo, human or model, was made blind. Nothing in those codebases could tell anyone what an edit had just broken.
The exit is founder-sized: a rules file that briefs the assistant on what not to break, two or three tests pinned to the paths that cost money, and one handoff question that takes five minutes. That’s deliberately smaller than what the technical-debt guides prescribe, because their advice assumes a team you don’t have. The tests come with one warning, and it’s 818 lines long.
The god file
The clearest sign of the drift is a file that only grows. Ask an assistant to add a feature to a component and it appends to the file it was handed, because that file is the context it can see. Ask ten times and you own one file that does ten things.
The shape repeats in audit after audit: a component that started at 150 lines is 800 now. It fetches the data, holds the business rules, and renders the UI in one scroll. Developers call it a god file, or a god component, and the name is earned. Every part can reach every other part, so there is no local place to change anything: you touch the top and something moves at the bottom. A 150-line component is a thing you can hold in your head. An 800-line one is a thing you negotiate with.
Regular code is understood, then it decays. A lot of AI-built code was never understood by anyone, so it gets harder to change instead of easier.
The doom loop, measured
The second sign lives in your git history: fix, revert, try again, revert, all in the same file in the same afternoon. The name for the pattern is code churn: lines revised or reverted soon after they were first committed.
GitClear’s 2025 analysis of 211 million changed lines, drawn from anonymized private repositories plus 25 of the largest open-source projects, put numbers on 2020 through 2024, the years AI assistants took over more of the typing:
Every row points the same direction: more rework, more duplication, less consolidation. Duplication is the row that bites hardest later, because when the same logic lives in five places, the assistant only fixes the copy you pasted into the prompt. The other four keep the old behavior, and the app starts disagreeing with itself.
You can read your own gauge in one line:
git log --follow --oneline -- src/components/Dashboard.tsxRun it on the file you’re most afraid of. Five commits in one week with messages like “fix”, “fix again”, and “revert” is churn, on your screen instead of in a research PDF.
Why AI technical debt advice doesn’t fit your repo
Search for advice on AI-generated code technical debt and what you’ll find is genuinely good, for the reader it was written for. The AWS developer-advocate piece at the top of that search prescribes an Explain rule, a Touch rule, and a Buddy rule: restate the AI’s code in your own words in the PR description, give every generated block a human edit before merge, and put a second reviewer on AI-heavy pull requests. Augment Code’s guide to compounding AI debt prescribes spec-driven development, and its trigger for writing a formal spec is AI code headed for production “where multiple engineers will modify it.”
Count the assumed inventory: a PR process, a merge gate, a second reviewer, multiple engineers. If you built the app alone with prompts, you have none of that, and you can’t adopt a two-reviewer rule through willpower. This is what AI technical debt looks like in a vibe-coded app: the compounding those guides describe, running in a repo with none of the brakes they take for granted. What follows is the version that survives with a team of one: instructions the assistant actually reads, and tests that fail loudly with nobody watching.
The rules file that stops it
The cheapest defense is a standing instruction the assistant reads before it touches anything: a .cursorrules file, a CLAUDE.md file, whatever your tool calls its rules file. It’s the one permanent place to say which areas are fragile and what has to be true before they change.
# Fragile areas -- do not change without a passing test
Auth + sessions: src/lib/auth/*
Payments + webhooks: src/lib/payments/*
Tenant isolation: supabase/migrations/* (RLS policies)
Rule: never edit the files above without adding or updating
a test that proves the old behavior still holds.What earns a place in that file:
- The two or three areas where a wrong-but-plausible change costs money or leaks data: auth, payments, data isolation.
- One falsifiable instruction per area (“don’t change this RLS policy without a two-account test”), never “be careful.”
- A pointer to the test that has to stay green when that area is touched.
What doesn’t earn a place: style preferences, folder-naming conventions, and general be-careful language, because none of them change what the assistant does. A rule earns its keep by being checkable. Ten falsifiable lines beat two hundred aspirational ones.
Two or three tests as behavior pins
A rules file tells the assistant what to avoid; a test makes the avoidance enforceable. Without one, “don’t break auth” is a hope. With one, breaking auth turns a green run red before anything ships.
You don’t need full coverage. Across the 21 third-party apps in the corpus, Maintainability & evolvability averaged 61.1 out of 100, one of the healthier pillars, while Reliability & correctness, the pillar that includes tests and error handling, averaged 31.4, the worst of the twelve. The structure of these apps usually survives inspection; what’s missing is anything that announces a regression. A handful of tests pinned to the flows that cost money when they break covers most of that gap: signup to a working account, checkout to unlocked access. The next confident edit either keeps the pins passing or fails the push, in front of you instead of a customer. Pins are the change-time half of the signal problem; the runtime half is an app that fails silently behind a 200 OK.
The pins have to run the real flow, though. A retail POS app I audited is why I open every green suite with suspicion: 818 passing tests, and not one of them executed the sale-creation path (the silent-failures post tells that story in full). Green checkmarks over an untested checkout are worse than no tests at all, because they end the conversation that would have caught the bug.
The handoff test
One question measures all of this at once: could a new developer, or a different AI assistant with zero context, open your repo and know within five minutes what not to touch? A repo with a rules file and three pins answers yes. A repo where the map lives only in your memory answers no, and that arrangement doesn’t survive a week off or a handoff.
None of it requires starting over. A rules file you write once, two or three behavior pins, and pulling the god file apart the next time you’re already in it will cover most of the distance. That’s the discipline that keeps a one-database, no-staging deploy from turning a small edit into an outage, and it’s one slice of whether the app is ready to launch at all. If you’d rather have this located for you, the scorecard walks the twelve readiness areas in about two minutes, scores the nine it can measure, and names your weakest one; a Beyond the Demo Audit reads the god files and the git churn for you, with every finding tied to a file and line.
The goal is unchanged since your first prompt: code the next change can’t break without telling you.
Common questions about AI code maintainability
Why does my AI generated code break when I change it?
Because it was generated one locally plausible piece at a time, with no map of the whole. Three mechanics do most of the damage: logic duplicated across several places, so your change updates one copy and strands the rest; a god file where distant sections share state; and no tests to announce the first breakage while it’s still cheap. You fix the break you can see, and the one you can’t waits.
Do I need full test coverage before adding features?
No. Full coverage on an existing app is a multi-week project that mostly protects code nobody is changing. Two or three pins on the flows that cost money, plus a rules file naming the fragile areas, buys most of the protection for an afternoon of work. Add the next pin when you’re about to touch one of those areas, not before.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
