Who Maintains AI-Generated Code? The Question No App Builder Answers

Writing new code and maintaining existing code draw on different skills, and current AI coding benchmarks almost exclusively measure the first one. A model can be excellent at generating a working feature from a blank file and still be poor at safely changing that same feature six months later. Most public AI coding benchmarks hand a model a task and a blank slate: build this feature, pass these tests, done. That is a fair test of generation ability, and frontier models have become genuinely strong at it. But it tells you almost nothing about what happens when the same model is asked to touch a large, aging codebase without breaking the parts that already work. One recent AI coding benchmark reportedly found that a majority of frontier models broke previously working features when asked to maintain existing code over time, using a large set of real codebases with genuine multi-month change histories rather than fresh, single-shot tasks. We flag this as a reported finding rather than a figure we have independently verified, but the shape of it matches what shows up in production again and again: models handle isolated changes well and struggle to hold a whole system's context while making them. The reason is structural, not a bug that gets patched next release. A model maintaining code has to know which parts of the system are load-bearing, what depends on what, and which shortcuts from six months ago are now permanent fixtures nobody can safely undo. None of that lives in the code itself. It lived in a conversation, a decision made under time pressure, a comment someone meant to write and didn't.

Code that looks correct on delivery can still contain subtle bugs, and a large share of developers in recent surveys say exactly that about AI-generated code. The cost of those bugs does not show up at launch. It shows up months later, compounded. A subtle bug in AI-generated code is rarely a crash. It is a discount calculated one step too late, a permission check that covers the common case but not the edge case, a race condition that only appears under real traffic. It passes the tests that were written, because the tests were written by the same process that missed the bug. Nothing about the app signals that anything is wrong until a customer hits the edge case. Technical debt from AI-assisted coding is a commonly reported concern in developer surveys, and the mechanism behind it is straightforward: an AI tool optimises for a working answer to the prompt in front of it, not for the long-term shape of the system. Ask it for a feature and it will usually deliver one. Ask it to deliver that feature in a way that a different engineer can safely extend eighteen months from now, and there is no reliable way to specify that in a prompt, let alone verify it happened. The compounding part is what makes this expensive rather than merely annoying. Each new AI-generated feature gets built on top of the last one, inheriting its shortcuts without anyone deciding to accept them. By month nine, the app is not one clear decision away from being fixed. It is a stack of decisions nobody made on purpose, and unwinding them costs far more than making them correctly would have. There is now measured evidence for what unmaintained AI-generated code looks like in production. Symbiotic Security scanned 1,072 live applications built on vibe-coding platforms with Supabase backends and found at least one security flaw on 98% of them, with critical flaws on 16% (Symbiotic Security, June 2026). In that sample, 172 sites allowed anyone to delete database records with no authentication at all, and 39 had tables fully readable by any visitor. None of those applications looked broken from the front end. That is the point. The failure mode is not an app that crashes, it is an app that works perfectly until someone who is not you notices what it permits. Finding that class of problem requires reading the code and the access rules, which is exactly the work nobody is assigned when the build is finished and the prompter has moved on.

The most expensive gap in an AI-built app is rarely the code itself. It is the absence of any record of why the code is the way it is, which means every future change starts from zero. A human engineering team accumulates documentation almost by accident: commit messages, code review comments, a Slack thread where someone explained a workaround, a colleague who remembers the client asked for it that way for a reason. None of that trail exists by default when an app is built through prompts. The chat history might technically still be there, but nobody re-reads six months of prompts to find the one message that explains why the checkout flow skips validation on weekends. This matters most exactly when it is needed most: during an incident, at speed, under pressure. A senior engineer walking into an unfamiliar but well-documented codebase can usually orient in an hour. Walking into an undocumented one, built by iterative prompting with no design record, can take days, because every assumption has to be rediscovered by testing it rather than reading it. The founder is usually the only person who ever held any of this context, and founders move on to the next problem the moment the current one looks solved. By month nine the context has usually decayed even in the one head that had it.

A senior engineer's real value on a maintained system is judgement: knowing what the system is doing, why it does it that way, and what not to touch. That judgement is precisely the thing current AI coding tools have not been shown to reliably replicate. Seniors survive in this shift because they provide something different from a fast first draft. They hold the mental model of the system in their head, not just the code that implements it. They know which parts are load-bearing and which are decorative, which shortcuts were deliberate trade-offs and which were accidents nobody caught. They know the decision history, including the decisions that were never written down anywhere because at the time they seemed too obvious to record. That is the value buildAgency is actually built around. A senior engineer assigned to a project does not just produce working code today. They document the decisions as they make them, so the app is maintainable by someone else next year, not just functional by whoever remembers building it. They know what to leave alone as much as what to change, which is the harder and less visible half of the job. This is not an argument that AI tools have no place in the process. A senior engineer using AI well can move fast on the parts of the job AI is genuinely good at, generating boilerplate, drafting a first pass, exploring an option, while keeping the judgement calls and the documentation with the person who has to answer for the system next year.

Ask these three questions before paying for any AI-built app, whether it comes from a builder tool, a freelancer, or an agency. The answers tell you what you are actually buying. - Who maintains this in six months? Get a name, not a tool. "The AI can fix it" is not an answer, because the AI has no memory of this specific codebase's history beyond what is in its context window at the time. - Is there documentation of why decisions were made, not just what the code does? Code comments describing behaviour are common. A written record of why the checkout flow works the way it does, why that library was chosen over the obvious alternative, is rare and is the thing that actually saves time later. - What happens if the person who built it is unavailable? If the honest answer is "we would have to start over reading the whole codebase from scratch," that is the real price of the app, even though it is not on the invoice. A vendor or builder who can answer all three without hesitation has probably already been maintaining software long enough to know why the questions matter. One who deflects to "the code is clean" or "AI can just fix bugs as they come up" is telling you, indirectly, that nobody has thought past launch day.

If your app was built fast and you cannot answer who maintains it next year, that gap is fixable before it becomes an incident. buildAgency at 13labs.au/buildAgency assigns one senior Melbourne engineer to your project, not a rotating junior team and not a black box. Code is documented as it is written, not reconstructed after the fact when something breaks. Decisions get a written reason, not just a working result. You own the code outright at the end, with a record of why it looks the way it does, so the app is still maintainable when the person who built it is not in the room. That is the difference between an app that was shipped and an app that was built to last past month nine.

Is AI actually worse at maintaining code than writing it? Reportedly, yes, though this is an active and still-developing area of benchmarking. Writing new code and maintaining existing code are different skills, and most public AI coding benchmarks measure the former almost exclusively. One recent benchmark using real, long-running codebases reportedly found frontier models broke previously working features at a high rate during maintenance tasks, though we treat that specific figure as a reported finding rather than one we have independently verified. Why does AI-generated code look fine but cause problems later? Because passing tests and being correct under every real-world condition are not the same thing. A meaningful share of developers in recent surveys report that AI-generated code can look correct while still containing subtle bugs, and those bugs typically surface as edge cases in production, not as failures during development. What does documentation actually need to cover for a maintainable app? Not just what the code does, which is often visible from reading it, but why it was built that way. That includes why a particular library or pattern was chosen, what trade-offs were accepted deliberately, and what parts of the system are fragile and should not be touched without care. Can a solo founder maintain an AI-built app themselves long-term? Sometimes, for as long as the app stays small and the founder keeps the context fresh in their own head. The risk grows with every new feature added by prompting, because each one adds to a system nobody has fully mapped, and it grows sharply the moment a second person needs to work on the code. What is the single most useful thing to check before trusting an AI-built app long-term? Ask who can explain, in detail, why the app's riskiest parts (payments, auth, data handling) work the way they do, and whether that explanation exists anywhere outside one person's memory. If the answer is nobody and nowhere, that is the gap to close before the app gets more customers, not after.