Maintaining an AI-built application: understanding what you had built

Vibe coding works until someone has to take over the application. Two accounts, one from a founder and one from a French developer, describe the same wall. What brings it down is a document you have read and approved.

Maintaining an AI-built application hits a moment a founder describes on Reddit (r/vibecoding, August 2026): 'And suddenly the hard part isn't building anymore. It's understanding what you built.' They list the signs: a function existing in two places, a component doing too much, files nobody dares delete.

The wall appears after delivery

Construction gives no warning. The first weeks are exhilarating: you describe, the tool produces, the screen responds. The wall appears later, at the twentieth change, when a simple request requires understanding three parts of the product before touching one. AI still produces code at that point; what is missing is the meaning of the whole. Nobody can say why a rule exists or what removing it breaks.

When several hands touch the same product

The same wall appears earlier with two people. A developer explains on Reddit (r/developpeurs, May 2026): 'My manager intervenes on projects I'm working on by vibe coding. As a result, the projects have no structure and are hell to maintain.' They specify they are the company's only formally trained developer. Two people independently describing their intentions to AI produce two application halves sharing no rules. Each half's quality changes nothing.

The specification is the product's memory

Software keeps two things: running code and the reason it runs that way. The second lives in the builder's head and fades within months. An approved specification fixes it in writing in your language: what the product must do, for whom, under which rules, and what it must not do. The document takes fifteen minutes to reread a year later. That is the subject of your specifications will be worth more than your code, and why we require human approval before every construction stage.

What can be regenerated and what cannot

With a document describing the product and tests written before code, a lost part can be rebuilt: request construction of that step again and tests tell you whether it holds up. Without the document, code itself is the only memory, and reading it requires the skill you sought to avoid by having AI build. The difference appears when changing provider, tool, or engine: code can be remade; knowledge of your business cannot.

What rapid generation tools do better

For a prototype shown to a partner and discarded next week, everything above is unnecessary weight: Lovable, Bolt, or v0 gives you a live screen in an evening, and no document will be missed because nothing survives. The boundary between these situations is what we described in a prototype in an evening, a product in a week. You cross it without warning when a first customer starts using the thing.

Taking over a product already built

If you are already beyond the wall, rebuilding should not be the first instinct. There is a takeover workflow: review the existing product, extract its buried rules, write the missing specification, then advance through verified steps. Maestro offers it for existing software, including someone else's work, and we described its outcome on an ageing tool in reworking business software. Compare the cost of restoring order with a year's maintenance, quantified in how much application maintenance costs.

The six-month test

Open your application and choose a business rule at random: a discount calculation, an email condition, a status blocking an action. Try writing it in three sentences without looking at code, then ask the person who built with you to do the same. If the versions differ, or neither comes, you already know the state of your product memory. Writing those three sentences takes ten minutes per rule and is better done today than when someone must take over for you.