How to Keep an AI-Built App Maintainable

An AI-built app stays maintainable if you defend four specific things: the dependency versions, the credentials that silently expire, the business rules that live nowhere but in the code, and the consistency of patterns across features built weeks apart. Notice what is absent from that list. Code quality in the abstract is not what breaks these apps six months in. What breaks them is that the app kept working perfectly while the world around it moved, and nobody was watching the parts that were quietly going stale.

Why six months is the number

The pattern is consistent enough to be predictable. Weeks one to four, everything is fresh and you remember every decision. Months two to four, the app runs and you stop opening the code. Around month six, something breaks, and it is almost never the feature you were worried about. It is an API key that expired, a dependency that shipped a breaking change, or a rule about how discounts work that only you knew and you no longer remember.

This is not a failure of AI-built code specifically. It is the normal decay of any software that nobody maintains. What is specific to AI-built apps is that the usual defences are missing: there was no code review where a second person learned the system, no commit messages explaining why, and often no README, because the app went from prompt to running without ever passing through the rituals that leave documentation behind as a side effect.

The four things that rot

1. Dependencies

Your app pinned a set of library versions on the day it was generated. Some of those have since shipped security patches, and at least one has probably made a breaking change in a major version. The risk is asymmetric: doing nothing feels safe right up until you need to change one line and discover you must first cross two years of upgrades.

The defence is to upgrade little and often, minor and patch versions monthly, majors deliberately one at a time. If your dependencies follow semantic versioning, the version number itself tells you which upgrades should be uneventful, and the ones that are not are exactly the ones worth doing while you still remember the app.

2. Credentials and their expiry dates

API keys, OAuth client secrets, TLS certificates, webhook signing secrets and cloud service accounts all expire, and they do it silently. An expired payment provider key does not produce an error you notice, it produces failed checkouts you hear about from customers. Keep a single list of every credential the app uses, where it lives, and when it expires, and put the expiry dates in a calendar. This one list prevents more incidents than any amount of refactoring.

3. Business rules nobody wrote down

Every app accumulates rules that exist only as code: which customers get the legacy price, why orders over a certain size skip automatic approval, what the retry rule is for a specific webhook. When you built it you knew. In six months you will read your own code and wonder what past you was thinking, and if you ever hand the app to a developer they will have no chance at all.

The fix costs ten minutes per rule: a short comment where the rule lives saying why, not what, and a single decisions file at the root of the project listing anything non-obvious. Ask the AI to explain a section back to you and correct it where it guesses wrong. The corrections are the documentation.

4. Pattern drift

Features built in different sessions use different patterns. One form validates on the client, another on the server. One list paginates, another loads everything. Each is individually fine, and the collection is what makes an app confusing to change, because there is no single answer to "how do we do this here?". Drift grows with every session unless something pins it down.

Pin it down with a conventions file the AI reads before each session: the folder layout, how errors are handled, how data is fetched, how forms validate. It is the cheapest maintainability investment available and it works because it removes the need for the model to invent an answer, which is the same reason getting an agent to follow your code style works at all.

What maintainable means when you cannot read the code

A fair objection at this point: most of the advice above assumes you can read what the AI wrote. Plenty of people shipping AI-built apps cannot, at least not fluently, and telling them to review the code is not useful advice. The good news is that three of the four decay points do not require reading code at all.

• The credential list is a list of external accounts and dates. No code reading involved.

• Dependency upgrades are a command, followed by using the app to see whether it still works. If it breaks, you revert. That is a complete workflow without reading a line.

• The decisions file is written in your own words, describing rules you decided. You are the source of that document, not the code.

Only pattern drift really needs a reader, and there is a workable substitute: ask the AI to compare two features and list where they solve the same problem differently. You do not need to evaluate the code to act on the answer, because the useful output is a list of inconsistencies, and the instruction that follows is simply to make them match. The thing to avoid is accepting a large rewrite you cannot assess. Small, reversible changes you can test by using the app are the appropriate unit of work when you cannot review the diff.

The ninety-minute quarterly pass

Put it in the calendar four times a year. In order, because the order matters:

1. Run the app and use it as a customer for ten minutes. Sign up, do the main thing, pay if there is payment. Most silent breakage is found here and nowhere else.

2. Check the credential list against the calendar. Rotate anything expiring in the next quarter now, rather than on the day it expires.

3. Upgrade minor and patch dependency versions, run the app again, and stop there. Majors get their own session.

4. Read the decisions file and add anything you have learned or changed since the last pass.

5. Confirm you can still restore from a backup. Not that a backup exists, that you can restore it. If you have not verified this since setup, it is the highest-value ninety minutes on this list, and it pairs with having backups configured properly at all.

Ninety minutes, four times a year, is six hours. The alternative is not zero hours, it is one unplanned weekend somewhere in month seven, at a moment you did not choose.

FAQ

Does AI-generated code need more maintenance than hand-written code?

Not inherently. It needs the same maintenance, but it usually arrives with less of the documentation that hand-written code picks up through review and commit history. The gap is in the surrounding artifacts rather than in the code itself.

Can I just ask the AI to maintain it?

Partly. An agent is good at the mechanical parts, upgrading dependencies and running tests. It cannot tell you which business rules matter or that a certificate is about to expire, because neither fact is in the code. It also works far better on a codebase with tests than without, which is its own known difficulty.

How do I know if my app has already drifted too far?

Try to add a small feature. If you cannot answer where the code should go and which existing pattern to copy within a few minutes, drift has already cost you, and a conventions file plus one cleanup session is the cheapest recovery.

Is it worth maintaining an app with only a few users?

Match the effort to the stakes. An internal tool for one person needs the credential list and nothing else. Anything handling customer money or personal data earns the full quarterly pass regardless of user count, because the downside is not proportional to the number of users.