Every new feature breaks something else? Fix the technical debt in your AI-built app

You ask the AI for one small change. It works. Then the login page breaks, or a price shows the wrong number. You ask for a fix and something else moves. Every maker recognizes this moment. The tool isn't broken. The pile has gotten too tangled to touch safely. Programmers have a name for that pile: technical debt. This page explains the term, what the research says about AI and it, and what order to clean up in.

What technical debt means, in its inventor's words

Answer first: technical debt is a money metaphor for code. Shipping quickly is like borrowing. You get something working sooner, then pay interest, in extra effort, until you tidy it up. Ward Cunningham coined it in 1992. His point was never "write bad code on purpose." It was about code that lags behind your understanding.

Here is Cunningham in his 1992 OOPSLA report on a financial software product: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." He added: "The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."

In a 2009 video he cleared up a common mistake. Many people, he said, confused the idea "with the idea that you could write code poorly with the intention of doing a good job later." His own position: "I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial."

That second quote matters for you. You build by describing what you want, learning from what appears, and describing again. Your understanding of your own app changes every day. Debt builds when the code keeps adding features and never gets reorganized around what you learned. Cunningham's words: the program "simply does not contain any understanding and all efforts to work on it take longer and longer."

Martin Fowler, a well-known software writer, gives the clearest arithmetic. A feature takes four days in clear code and six in tangled code. "The two day difference is the interest on the debt." Cleaning up first takes five days. For one feature, that loses: nine days against six. "But if I have two more similar features coming up, then I'll end up faster by removing the cruft first." By our sum, three features cost 18 days in the mess and 17 tidying first.

How AI-built apps can pile it up

Answer first: AI tools add code fast and rarely stop to reorganize unless you ask. Repeated logic, leftover pieces and unclear structure then build up, and each makes the next change riskier. No study measures this for non-coders. What follows are signs you can see, and the one dataset that looks at code changes at scale.

These are warning signs an owner can spot without reading code. We list them as symptoms, not as measured rates, because no source we read gives a frequency for any of them.

Now the data. GitClear, a company that sells developer-analytics software, looked at "211 million changed lines of code, authored between January 2020 and December 2024," from repositories it says are owned by Google, Microsoft, Meta and enterprise companies. Its abstract says "the percentage of changed code lines (associated with refactoring) sunk from 25% of changed lines in 2021, to less than 10% in 2024, while lines classified as "copy/pasted" (cloned) rose from 8.3% to 12.3% in the same period."

Read that carefully. Refactoring means restructuring code without changing what it does. Less of it, and more copy-paste, is the pattern of debt growing. But this is a vendor's report, and the full report sits behind a contact form, so we read only the abstract. It compares years in which AI assistants spread. It does not, in the abstract, say which lines an AI wrote. It shows an association, not proof of cause.

Google's DORA research gives a second angle. Its 2024 report comes from an annual survey; "nearly 3,000 working professionals" answered. For each 25% increase in AI adoption, it estimates documentation quality up 7.5% and code quality, as developers rate it, up 3.4%. It also estimates delivery throughput down 1.5% and delivery stability down 7.2%. In DORA's words, stability "measures the likelihood deployments unintentionally lead to immediate, additional work."

That's a mixed picture, and we'd rather show it than pick a side. DORA's code quality figure is satisfaction, not a code measurement. Its "technical debt" figure, a self-reported measure of how much debt hindered work, moved just 0.8% (down). The survey covers teams at organizations, not solo builders. The authors' own advice: "small batch sizes and robust testing mechanisms." DORA's 2025 page adds that AI's primary role "is as an amplifier, magnifying an organization's existing strengths and weaknesses." For you, that reads: tidy habits get faster, and messy habits get messier, faster.

The cleanup order that keeps your app working

Answer first: clean up in small steps, and keep the app working after each one. Fowler defines refactoring as altering "its internal structure without changing its external behavior," and says "the system is kept fully working after each refactoring." Our order puts the safety steps first, the deletions next, and the reshuffling last.

This order is our advice, built on Fowler's and Cunningham's ideas. It isn't from a study. Do one step, check the app, then move on.

Why step two comes before the code

Answer first: a written description of what the app should do is what lets you, and the AI, tell a cleanup from a break. Without it, "the app still works" means whatever you happen to click. Cunningham's idea is that code should reflect your understanding, so write the understanding down first.

Keep that note in your project. When you ask for a cleanup, paste it in and say: "Don't change anything this note says the app does." The method has a name, and it's covered in spec-driven development for vibe coders. If you aren't sure how to tell whether the AI changed more than you asked, see how to read an AI diff without coding.

One more habit helps. Long chats lose track of earlier decisions, which is one way an AI re-adds code it removed. Context engineering explains how to give the tool the right background each time. For the bigger picture of getting an app live and keeping it running, read how to ship a vibe-coded app.

When not to clean up yet

Answer first: skip the cleanup if the app is a throwaway prototype, or if you're about to rebuild it anyway. Debt only matters if you keep paying interest. Cunningham's own idea of "a little debt" is borrowing on purpose. The trouble starts when you borrow and never repay.

Use Fowler's math. If you'll touch an area only once, tidying it first loses, as his six days against nine shows. If you'll keep adding to it, tidying wins. A page you plan to change every week is worth cleaning. A one-off landing page isn't. Fowler also notes the debt idea works well for talking to people who don't write code, so use it with a partner or client when you explain why a "small" change takes longer than expected.