There's a particular kind of AI building session that's easy to get pulled into.
You start with an idea. By dinner, something works. You spend the evening fixing the layout, adding a feature, changing the navigation, asking the agent to sort out an error. You leave it working overnight. In the morning, there's more software to inspect.
The default next step is to keep going.
But after using what you've built, you might realise you'd approach the whole thing differently now. The useful part is buried three screens deep. Half the features exist because of an assumption you no longer believe. The app works, but explaining what it should become takes longer than explaining what you wanted in the first place.
I think we should be more willing to archive that version and start again.
Especially for small tools and early prototypes, building with AI can look more like playing a roguelike. You attempt a run, find out what works, reach its limit, and return to the start with a better idea of what to do.
The next run starts with a different builder
The part of the roguelike metaphor I like is that losing a run doesn't erase everything you gained from playing it.
You recognise a dangerous room. You understand a combination you overlooked before. You stop picking up something that looked useful but kept getting you killed. Even when the character starts over, the player has changed.
A prototype can do the same thing.
Before building it, you're guessing about what the tool needs to do. Once you've used it, you have something more specific to work with. You know which interaction feels awkward. You know which feature you never opened. You can point to an actual example the system mishandled.
That understanding can survive a complete change of implementation.
The first version might have been a perfectly useful way to discover that you were building the wrong shape of thing. It doesn't have to become the foundation of every version that follows.
A working first version can be surprisingly persuasive
Once something exists, it starts influencing the questions you ask.
How do I add this to the dashboard? Where should the new tab go? Can the agent make this workflow less awkward?
Those questions quietly assume the dashboard, the tabs and the workflow should stay.
Imagine building a tool for saving articles. The first version has folders, tags, summaries, search and a dashboard showing everything you've collected. Then you use it for a few days and discover that the only thing you want is a short reading queue with a sentence explaining why each article is there.
You could keep modifying the original app. Hide the dashboard. Make folders optional. Put the queue on the home screen. Adjust the summaries to explain why you saved something.
Or you could start with the reading queue and build only what it needs.
The second approach gives you a chance to make different decisions throughout the app. The data you store, the first screen you see, and the action you take after reading can all follow the simpler idea.
In Organic Software, I wrote about letting a tool grow through use. Sometimes that process reveals that the original structure is getting in the way. A fresh version can be a sensible response to what you've learned.
Cheaper implementation changes the decision
Starting again has a cost. You have to rebuild useful behaviour, find new bugs and check things you already checked once.
If the first version took months, that's a substantial commitment. If an AI-assisted prototype took an evening, and the next version can be much smaller, the calculation may be different.
I'd compare the work still ahead: how much effort will it take to make the existing version fit the clearer idea, and how much will it take to build and verify a fresh one?
The hours already spent explain how you got here. They don't settle that comparison.
This also changes what an overnight build is for. You could ask an agent to extend the current version. You could also ask it to build a separate, narrower prototype from a revised brief, then try both against the same task in the morning.
More generated code isn't much of a result on its own. I'd want to know whether the new version makes the actual task easier. That's a useful place for an AI evaluation checklist: deciding what you'll check before a fresh interface persuades you it's better.
Keep a record between runs
A restart only helps if the next attempt benefits from the last one.
Before archiving a prototype, I'd write a short note about what happened. Who was it useful for? What did they actually do? Which assumption failed? What should the next version leave out?
For the article-saving tool, that note might be:
I want help choosing what to read next. I didn't use folders. A generic summary didn't remind me why I saved an article. The next version should open directly to a reading queue and preserve my reason for adding each item.
That's enough to change the next build substantially.
I'd also carry forward examples of real inputs and the behaviour they need to produce. If the first version taught you that an imported article can have no title, keep that case. If someone needs to export their saved links, preserve that requirement. Tests that describe useful behaviour can travel between implementations, even when the code underneath them changes.
Keep the old version available for comparison. Starting from scratch doesn't require deleting your history.
Restarting can become its own trap
The first part of a build is often the most enjoyable. A blank project becomes something visible. Each change feels substantial. Later, you have to deal with awkward inputs, confusing states and the small details that make a tool dependable.
It's easy to call another restart learning when you're avoiding that later work.
I'd want to finish this sentence before beginning again: “The next version will be different because I learned…”
If I can't be specific, another run probably won't help much.
There's also a limit to the game metaphor. A live service has users, stored data and behaviour people rely on. Those commitments survive whatever you decide about the code. Replacing it may require a migration, compatibility work and a way to recover if the new version fails. A disposable prototype gives you much more freedom.
And repeated runs can consume the same evenings as endless tweaking. I've written before about how AI doesn't automatically give you time back. Restarting needs a stopping point too.
Once a version does the job well enough, use it for a while. Let actual use give you a reason for the next change.
What appeals to me about building this way is being able to finish an evening with something I won't keep, without deciding the evening was wasted. I might have a much better brief for the next attempt.
Sometimes that's enough to justify a new run.
Try this prompt
Review this prototype and my notes from using it. Compare improving the existing version with building a smaller version from scratch. Identify what I've actually learned, which assumptions have changed, and which behaviours, data and constraints must survive. Estimate the work of rebuilding and verifying each option, including any migration. Recommend a restart only if you can explain what the next version would do differently. Don't change the code yet.
