Keep the AI-built prototype, or start over?

AI-assisted building has changed what a prototype costs. Something that used to take a sprint of mockups now takes a few days and actually runs. Stakeholders click through it, real data goes in, and somebody says the sentence every engineer has learned to dread: “Great, can we ship it?”

Sometimes the honest answer is yes. Sometimes the prototype’s best use is as the clearest spec the team has ever had, and the code should go in the bin. The mistake is not picking the wrong one. It is never picking at all, and letting the prototype drift into production because it was already there.

Why the question is harder now

When prototypes were slow and ugly, nobody confused them with products. A wireframe does not get deployed. A generated prototype looks finished: real screens, a real database, a login page. The polish arrives long before the error handling, and the polish is what people see.

It also tends to be built the way prototypes should be built: one happy path, data shapes that changed four times in an afternoon, shortcuts taken because the goal was to learn something by Friday. That is the right way to build a prototype. It is the wrong foundation for a system somebody has to run for three years.

When keeping it is the right call

We keep a prototype when the senior engineer who owns it can answer yes to most of these:

• The data model settled early and stayed put. Screens are cheap to change; tables full of customer data are not.
• Someone can explain every module without opening the chat transcript that produced it.
• Auth, permissions, and anything touching money or deletion were written deliberately, not accepted as generated.
• The structure would survive a second feature. If adding the next obvious thing means copying a file and editing the copy, the structure is telling you something.
• There are tests for the behavior that matters, written against decisions, not backfilled to match whatever the code already does.

If the answers are mostly yes, keep it and budget for the hardening pass: error paths, timeouts, observability, rollback. That work is the same whether the code came from a model or a keyboard, and it is what our senior-engineer-on-the-hook rule exists to protect.

When starting over is cheaper

Mostly no means rebuild, and the good news is that rebuilding is not starting from zero. The expensive part of a first version was never typing the code. It was figuring out what the thing should do, and the prototype already paid for that.

So harvest it before you delete it. Write down the screens that tested well, the data model you wish you had started with, the edge cases stakeholders found by clicking around, and the features that sounded important and nobody used. That document, plus the same AI-assisted tooling, usually gets a clean version standing faster than the prototype took, because nobody is discovering requirements along the way.

We have watched teams spend months patching a prototype into shape when a rebuild would have taken weeks. The sunk cost feels real because the screens are real. It is still sunk.

Make the call before the demo

The worst time to decide is in the meeting where everyone has just seen it work. Decide when you start building: is this a throwaway to learn from, or the first slice of the product? Say it out loud, write it in the ticket, and build accordingly. A throwaway can skip the tests and take every shortcut. A first slice gets a real data model and a real owner from day one.

If you did not decide up front, decide now, using the list above, and put the hardening or the rebuild in the estimate where everyone can see it. That is the conversation we have at the start of most vibe coding and AI-native delivery work: what are we building this week, and what is it allowed to become.