NotVibesCoded logo

AI wrote the code. Who maintains it?

Generation made writing code nearly free. It did nothing to the cost of owning it. The first generation of AI-built apps is now old enough to need maintenance, and a lot of them have no maintainer, because nobody ever understood the code well enough to own it.

By NotVibesCoded Editorial TeamPublished 6 min read
Cover for 'AI wrote the code. Who maintains it?': generation made writing code nearly free, owning it still costs full price, five ways the bill arrives, bus factor: a browser tab

Writing the code was never the whole job. It was the visible part, the part with a demo at the end. Every codebase also has a second, longer life: the bug reports, the security patches, the dependency upgrades, the "small change" that turns out not to be small. That second life is where software spends most of its existence, and it is where the bill for AI-generated code comes due.

AI collapsed the cost of the first life to nearly zero. It did nothing to the second. The first generation of vibe-coded apps is now old enough to need real maintenance, and a pattern is emerging: many of them effectively have no maintainer. Not because nobody cares about them. Because nobody ever understood the code well enough to own it.

The bill arrives in five forms

The bug nobody can find. Debugging is not mostly typing. It is having a mental model of the system good enough to say "the fault is probably in this layer, not that one." When the author was a chat session, that model was never built, and it left when the session ended. What replaces it is prompting the AI to guess at its own code, accepting the guess, and shipping a fix for a bug that was never actually located. Sometimes it works. Sometimes the "fix" moves the bug somewhere quieter.

The patch nobody applies. This week, two critical flaws were disclosed in PHP itself, rated CVSS 9.2, with more than 22 million exposed servers and one official instruction: updating is the only safe choice, because there are no complete mitigations. Patching sounds simple until you ask the prerequisite questions. Which version are we running? Where does it run? What else depends on it? Teams that built their stack by accepting generated output often cannot answer any of those quickly, and "quickly" is the whole game when exploits are already circulating.

The change that breaks three other things. In a codebase with tests, a risky edit announces itself: the suite goes red before users do. In a generated codebase with no tests, every change is a regression lottery played in production. Nowhere is this sharper than in the data layer, where AI-generated migrations can apply cleanly and still be wrong in ways that surface months later, when the bad state has been built on top of.

The upgrade nobody dares to run. Generated code is a snapshot of what the model knew: last year's APIs, last year's idioms, dependency versions that were current when the prompt was written. The ecosystem does not freeze with it. Libraries release breaking changes, platforms deprecate endpoints, and each postponed upgrade makes the next one bigger. Codebases do not usually die from one dramatic failure. They fossilize, one skipped upgrade at a time.

The handover nobody accepts. So you hire a developer to maintain it. They open a repository of tens of thousands of lines that no living person can explain, with no tests, no decision history, and naming that shifts style every few files because different sessions wrote different parts. Their quote comes back as a rewrite, and they are not being lazy: reading code you cannot interrogate is slower than writing code you can. The bus factor of an AI-built app is often zero, except the bus was a browser tab, and somebody closed it.

The five ways the maintenance bill arrives for AI-written code: the bug nobody can find, the patch nobody applies, the change that breaks three other things, the upgrade nobody dares run, and the handover nobody accepts

Can't the AI maintain it too?

Partly, and the honest answer has to give the models their due. Current tools are genuinely good at explaining unfamiliar code, proposing fixes, and doing the mechanical parts of an upgrade. If your maintenance plan is "ask the AI," you will get real value from it.

But maintenance is not mostly editing. It is deciding. Is this odd behavior a bug, or is a customer depending on it? Is this dependency bump safe to ship the week of a launch? Was this module written this way for a reason, or by accident? An AI session can tell you what the code does. It usually cannot tell you why it was done that way, because the why lived in a conversation that no longer exists, between a person and a model, neither of whom wrote it down.

That gap is fixable, and it is exactly what context files are for: a maintained, human-readable map of the system that survives between sessions and between people. Explanation is not ownership, though. A map is not the territory, and somebody still has to keep the map true.

What owning AI-written code actually looks like

None of this requires writing the code by hand. It requires treating maintenance as part of the build, from day one:

  • Keep the why, not just the how. A README and context files that explain decisions, constraints, and the parts that look wrong but are deliberate. Ten lines written at build time save ten hours at incident time.
  • Tests are the codebase's memory. You do not need full coverage. You need a thin, trusted suite over the paths that matter: auth, payments, anything that writes data. It converts every future change from a hope into a check, and it is what makes reviewing AI-generated changes possible at all.
  • Schedule the boring parts. Dependency updates, backups, monitoring, certificate renewals: the unglamorous list is the maintenance. Put it on a calendar, because maintenance debt does not send invoices monthly. It compounds silently and collects all at once.
  • Know your inventory. Versions, services, where the secrets live, which third parties the app phones home to. The teams that patched PHP within hours this week are the teams that could answer those questions in minutes.
  • Budget honestly. Writing the code was always the minority of a product's lifetime cost. If the plan funds generation and nothing else, the correct move is to scope the product down until its maintenance is fundable too.

The answer to the title

AI did not eliminate the maintainer. It eliminated the apprenticeship that used to create one: the hours of writing and reading code that built the mental model ownership runs on. That model still has to exist somewhere. In a person, in tests, in written-down decisions, or ideally in all three.

So: who maintains the code the AI wrote? Whoever can answer "why does it work this way?" at 2 a.m. when it stops working. If the honest answer is nobody, the app was never finished. It was abandoned at version one, with a launch tweet on top.

Use AI. Just don't ship slop, and don't ship orphans.

Share this article

Written by

NotVibesCoded Editorial Team

NotVibesCoded is written and reviewed by its editorial team under the standards in the editorial policy. A named author page, with full credentials, replaces this placeholder shortly.

More about the author

Related articles

AI Found Two Critical Flaws Hiding in PHP for a Decade

Two critical remote code execution flaws sat in PHP, the language behind roughly 70% of websites, for more than a decade. AI models helped researchers find them and turn them into working exploits, and the emergency patch that followed is a preview of how security works now.

By NotVibesCoded Editorial Team