The remarkable thing about the current moment is who is shipping software. A neuroanesthesiologist builds and launches a hospital department website by supplying content and iterating, never reading the code. Someone with no engineering background stands up a coffee-shop management system with point-of-sale, inventory, and ordering. The first version works. That part is genuinely solved. The trouble is that "the first version works" is the beginning of the project, not the end of it.

Everyone celebrates the demo. Far fewer talk about the week after the demo, when the questions stop being "can I build this" and start being "can I keep this alive." Maintainability. Which open-source pieces to trust. How to hand the thing off to someone else. Whether the project's context survives once the original build session is closed. These are the questions that separate a working prototype from a system you can actually run, and AI assistance has made the first far easier without touching the second.

The first draft hides its own debt

A vibe-coded first version works precisely because the agent made a thousand decisions you did not see. Library choices, data models, error handling, the shape of the API — all decided in the flow of getting it running, none of them reviewed by someone who will have to live with them. The app works, and underneath it is a pile of unexamined decisions that nobody on the project understands, because nobody made them deliberately.

That is fine until you need to change something. The first modification is where the debt comes due: you ask the agent to add a feature, and it cannot, because it no longer remembers why it built things the way it did, and neither do you. The working demo bought speed by deferring understanding, and understanding is exactly what maintenance requires.

Context that dies with the session is the core wound

The most concrete pain people describe is context loss between sessions. You build something over an afternoon, close the session, come back, and the agent starts from zero — re-learning the project, re-deriving the decisions, sometimes contradicting what it did yesterday. People build project-memory tools for Cursor and Claude specifically because every new session otherwise begins by rebuilding context that should have persisted.

This is the difference between a tool and a teammate. A teammate remembers the project. An agent without a memory layer is a brilliant contractor with amnesia, and the cost of the amnesia lands entirely on the human, who becomes the only durable store of why the system is the way it is. A handoff layer that keeps project memory — decisions, scope, structure — is what turns the amnesiac contractor into something you can actually build on.

Handoff is the real test

The clearest sign that a vibe-coded project has matured is whether someone other than its creator can take it over. Can a developer pick up the hospital site, the coffee-shop system, the side project, and understand what it does and why, without interrogating the original builder? That requires the things the first draft skipped: documented scope, a record of decisions, review trails, an explanation of the structure. Handoff is where deferred understanding becomes non-negotiable.

Non-coding builders feel this acutely because they cannot read the code to reconstruct intent. For them, the handoff layer is not a nicety — it is the only way the project outlives their personal involvement.

Build fast, then build the layer that keeps it

None of this is an argument against vibe coding. Getting a non-engineer to a working system in an afternoon is real, and valuable, and not going away. It is an argument that the celebration stops one step too early. The first version working is the easy half. The half that decides whether you have a product or a disposable demo is the layer that comes after — maintainability, tool choices, and project context that survives past the session that created it. Build the first version with AI. Then build the layer that keeps it alive.