Your next vibeCode starts where the last one finished

But first, a disclaimer. Claude helped me write this. The thoughts are mine. Putting them in order is the part I handed over and it still took me a couple of hours. Two hours only because the base was already there.

Your first vibeCode is rough. Mine are. Everyone’s are.

But the next one does not have to start where that one did. That is the whole argument.

It is also the part missing from every post telling you vibeCoding is bad. There are a lot of those about, so this is a real question for the people writing them.

First, the thing you were going to say. You are right. Do not put vibeCode in production without safeguards. Review it. Test it. Look at the data it touches. Have someone own it when it breaks. I am not arguing with any of that.

Now my question.

Have you built something from scratch with AI assisted coding? Or are you describing something you watched someone else do badly?

I ask because the answer usually explains the post.

That is not a dig. It is just how I read things now. Whatever you are reading, work out where the writer is standing. The bias is the part that never gets said out loud. So when someone tells you vibeCoding is bad, the useful question is what it would cost them if it were good.

Same goes for me. I make a living helping people build with AI. That is a bias and you should hold it while you read this. I would rather you did.

So here is where I stand.

A vibeCoded artifact is possibly one of the most important things you can make.

It proves something

A slide describes what the thing might do. So does a document. A vibeCode is the thing. Running. In front of someone who can tell you if it is any good.

So you stop arguing about the idea. You go and find out. Most of what I learn about an idea, I learn in the twenty minutes after someone else touches it.

The code is reusable

This is the part people miss.

The vibeCode is not throwaway. It is a working source. It maps to the proper version. Whoever builds that is not starting from a blank page. They are starting from something that runs, with the hard question already answered.

Rewriting something that works is a known job. Working out what to make is not. The vibeCode does the hard one.

The first vibeCode is rough

You are right about that too. Mine are rough. Nobody should be defending the first output.

But that is the worst it will ever be. And that is where most of these posts stop looking.

What matters is what you rebase onto.

Start from a blank page every time and nothing improves. Rough on Monday, rough on Friday. Start from a base that is better than last time and the vibeCode gets better on its own. Same prompt. Better base. Better result.

The base is three things. The scaffolding you no longer write by hand. The frameworks and conventions you settled on, so there is one obvious way to do something instead of five. And the knowledge base you keep adding to, where you write down what you want, how you want it and what went wrong last time.

That last one compounds. Every correction is either a note you write once, or a correction you make again next week.

This is devops thinking, pointed at prototypes. Nobody accepts a build pipeline that starts from nothing every time. Same rule here. Most people have not noticed yet.

This post is a carbon copy of that process. The first draft was rough. It went round again and again with the AI (in this case Claude). Each pass started from notes and conventions I already had rather than from nothing. That is why it took hours instead of days. For me that is the win.

Same loop. Different artifact.

Pick your base

So where does the base come from. Two answers.

You build it. Your scaffolding, your conventions, your notes, built up over the work you have already done. This is the one that compounds, because it fits how you work.

Or you take someone else’s. A framework, a starter, a template, conventions that plenty of people have already argued about.

Both are fine. Doing neither is the mistake. Choosing a base deserves more thought than the prompt does. The prompt is a one-off. The base is every prompt after it.

You are in a team now

On your own you could get away with a folder. You are not on your own any more.

The moment you build with AI you are working in a team. Your new teammate is fast and never tires. It also turns up with none of the context that is in your head. And it forgets most of what happened yesterday.

You would not hand a new person a folder of files and expect good work back. You would tell them how things are done here. The AI needs exactly that. The only way to hand it over is to write it down. Which is another word for process.

So you need version control. You need the habits that come with it too. The code part is obvious. The bigger part is that those habits hold your ways of working in a form somebody else can read, including the one that does not remember yesterday.

Branches, so two of you can work without standing on each other. That matters more with AI, not less. A lot more gets written per hour.

Releases, so you can point at one and say that one worked. Which also gives you something to go back to.

Issues, so the queue is visible and the argument about what to build next happens next to the thing itself.

Docs, in the repo, beside the code. That is not admin. That is the context getting out of your head and into the one place your team and your AI both already look.

All of it is ways of working, written down. GitHub fits that naturally, which is why I use it, but the practice is the point rather than the tool.

Same move as before, one level up. You encode what you learn so the next attempt is better. The only difference now is that the next attempt is not only yours.

The stack

The other half of a good base is what you build on. Build on a platform that scales.

Almost none of it needs building. Compute near your users. A database. Object storage. A queue. Static hosting. A way to lock it down. Deployed in seconds, from the repo. It is all sitting there. Most of it costs nothing until you are properly using it.

So do not reinvent any of it. Every hour spent standing up infrastructure is an hour not spent on the thing only you can make. And whatever you build yourself, you own forever.

Pick a platform that hides the complexity and scales the moment it needs to. Deploying should not be a project. You should not be sizing servers for traffic you do not have. You should be able to afford five of everything.

That last one is why this belongs here. An expensive stack makes people precious. Nobody spins up a throwaway when every environment costs real money. So the prototype quietly becomes production, because it was the one that got provisioned. A cheap base means you can bin one. Which is what you should be doing.

So what

In most cases, do not deploy the vibeCode.

Learn from it. Use it to move fast.

And improve the base. That is the only thing that makes the next one better.

If you want to do this on purpose rather than by accident, that is what shape, build, launch is for. Decide what to make. Build it. Put it in front of someone. The prototype’s job in that is to be the thinnest thing that proves it.

The words

A few of these get used loosely, so here is what I mean by them.

Sharing is how we learn

That is what I have learned so far. Sharing it is how I learn the rest.

What is in your base? What have you written down that your AI reads? One line is enough. Mine got built out of my own mistakes and I would rather see what other people keep.

I will go first. Claude Code, because it reads the repo and the notes I have already written. Git and GitHub, so I can try something rough without risking the thing that works. And a plain notes file the AI reads before it starts. That last one is the smallest and it changed the most.

Not a recommendation. Just what settled.

Then tell me where I am wrong. The rebasing, the base, the version control argument. And if you have built something from scratch with AI assisted coding and still think the artifact is worthless, I want to know why. If you have not built one, build one this weekend.

One I keep turning over. AI assisted coding has changed a lot in a year. Can you still see it the way you did? It is going to change a lot more. Can you see that view holding?

If you would rather talk than type, I sit in an open room every Wednesday at 5:30pm AEST, or book a free 1:1. Either way the only question is what you are trying to make.