Vibe coding is fine. The Monday after is the problem.
AI will get you to a working product in a weekend. Here is the plumbing it does not build for you — and what it costs when nobody puts it in.
The weekend build
It is a genuinely good story, and it keeps happening. You describe what you want. It appears. By Sunday night there is a working thing — a login, a database, a deploy — and it does roughly what you said it should. That is not a fluke and it is not cheating. It is the most useful change in how software gets made in twenty years.
Then Monday happens.
Nothing is wrong with the code. Something is missing around it.
The usual assumption is that the problem must be code quality. Mostly it is not. AI-written code is often perfectly reasonable — clearer than a lot of code written by tired humans at four in the afternoon.
The problem is that working code is about a third of what a product is. The rest is plumbing:
- a record of what changed and why
- a way to try something without risking the live version
- a way back when the new version turns out to be worse
- somewhere to keep secrets that is not the source code
- a written account of the decisions everything else is resting on
None of that comes out of a chat window, because you never asked for it. You asked for a feature, and you got a feature. That is the deal you made, and for a weekend it is the right deal.
Four ways it shows up
Nobody can say what changed. A month in, something is behaving oddly and the only record of how it got that way is a conversation somebody has since closed. The commit history, if there is one, is forty commits called “update” and “fix.” Nobody is being lazy here — the tool simply never asked you to explain yourself, so you never did.
There is no way back. This is the one that actually hurts. It worked on Friday, it does not work now, and there is no tagged version, no staging copy, and no rollback. The recovery plan is to describe the old behavior to the model and hope. That works more often than it should, which is exactly why people keep relying on it.
The keys are in the code. Somewhere in the build there was a moment where the fastest way past an error was to paste the key directly into the file. It worked, the moment passed, and the key is still there — sometimes in a repo that is more public than anyone realizes. This is the failure with the worst ratio of effort to consequence in all of software.
The codebase starts arguing with itself. You made a decision in week one about how something works. In week six the model does not know that decision exists, so it solves a new problem a different way. Now there are two patterns for the same thing, then three. Each individual change is defensible. The accumulation is not.
Why it gets worse instead of better
Here is the uncomfortable part: speed compounds in both directions. Every week you add features on top of no foundation, the cost of adding the foundation goes up — there is simply more standing on it.
A prototype nobody depends on can be thrown away, and that is a real and valuable option. A product with customers cannot. Most people do not notice the moment they cross from one to the other, because it does not happen at a launch. It happens quietly, on an ordinary Tuesday, the first time somebody outside the building starts counting on the thing to work.
The fix is much smaller than a rewrite
Almost nobody in this situation should start over, and the instinct to do it is usually the wrong one. Four things cover most of it:
- A delivery process. Branches that mean something, a staging environment, and a release you can repeat and undo. Most of the fear goes away here.
- A GitHub workflow. Pull requests, automated checks that run before a merge, and branch protection. This is the step that gives every future change a review and a paper trail — including the changes an AI makes.
- Security basics. Secrets out of the repo, keys scoped down to what they actually need, dependency scanning on a schedule.
- Written architecture decisions. The handful of choices that constrain everything else, with the reasoning attached, so the next change — yours or a model’s — does not quietly undo the last one.
That is days of work on most projects, not months. And it is work that pays every week afterward.
Keep vibe coding
None of this is an argument for building slower, or for going back to doing it by hand. It is the opposite. Put the guardrails in and you go faster, because the thing that actually slows people down is not typing code — it has never been typing code. It is being afraid to change something.
The goal is a codebase you are willing to touch on a Monday.
If any of this sounds like your project, see what production-ready actually involves, or tell us what you have built and we will give you a straight read on it.