Nine vibe coding mistakes that follow you into production

Vibe coding means describing what you want and letting an AI coding tool write it, while you judge the result by whether it looks and feels right. It works. We use AI coding tools every day, and this article is not a lecture against them.

But we also get the phone calls that come three months later, when a vibe-coded app has real users, real data, and a real problem. Those calls repeat. The same nine mistakes come up so often that we now check for all nine in the first hour of looking at any inherited codebase. Here they are, with the fix for each. If your app is close to launch, the launch safety check turns the serious ones into a scorecard you can act on today.

1. The API key is in the app

What happens: the coding tool needs a key to call a payment provider or a model, and the fastest place to put it is right in the code. The key ships to the browser, or gets pushed to a public repository. Bots scan public repositories for keys constantly; security researchers who plant test keys there watch them get abused within minutes.

The fix: keys live on the server, in environment variables, never in code and never in anything the browser downloads. If a key has ever been in a public repository, it is burned. Rotate it today, not after you finish the feature. Then turn on secret scanning in your repository settings so the next leak is caught by a machine instead of a stranger.

2. Every endpoint is public

What happens: the tool scaffolds an API that does what the screen needs, and nobody asks who else can call it. The screen has a login. The API behind it does not check one. Anyone who opens the browser's network tab can copy the URL and read the database from their own laptop.

The fix: every route checks who is asking, and denies by default. Then test the app as a stranger: log out, take the raw URLs, and try them. If any of them answer, that is the day's work. This is the single most common serious hole we find in vibe-coded apps, and it takes an afternoon to close on day one and a painful week to close after launch.

3. The demo database is the production database

What happens: the app was built against one database, users arrived, and now the tool that happily ran "delete everything and rebuild" during development is pointed at real customer data. One confident prompt, and the table is gone. There is no backup, because a demo does not need one.

The fix: separate development from production the moment a real person's data enters the system. Turn on automatic backups and actually restore one once, because a backup you have never restored is a hope, not a backup. Make schema changes through migration files instead of letting a tool reshape live tables.

4. Letting the tool regenerate whole files

What happens: you ask for a small change and the tool rewrites the entire file, quietly dropping the fix you made last week. Nothing errors. The old bug simply comes back, and nobody connects it to the edit that caused it.

This failure is common enough that our own systems carry a watchdog that restores the scheduler from a known-good copy the moment it goes missing, because a tool that means to edit a file will sometimes replace it. A note telling the next person to be careful is not a mechanism. The watchdog is.

The fix: small changes, reviewed as differences against the previous version, in version control, committed often. If you cannot read the change the tool made, do not accept it. Version control is not bureaucracy; it is the undo button for exactly this failure.

5. There are no tests, so every change is a gamble

What happens: the demo worked, once, on the happy path, with the founder driving. Every change after that might break something and nobody would know until a customer does. So changes get scarier and slower, which is the opposite of what the AI tool was supposed to buy you.

The fix: write tests for the things that must never happen, before the things that would be nice. One of our client-facing agents ships with a guardrail suite that tries seven different ways to trick it into quoting a price the business cannot fulfil, plus a live check on every reply that catches an ungrounded answer and hands the conversation to a person. When someone shows you a product built in a weekend, ask to see the tests. A shrug means you are looking at a demo.

6. The model does the arithmetic

What happens: a total, a price, a dosage, a date arrives in front of a customer because a language model wrote it. Models are persuasive and approximately right, and approximately right numbers are how you lose a customer or end up in a dispute.

The fix: the rule we build every system by: code computes the numbers, the model only narrates or extracts, and the boundary is enforced by a test. In our reporting product, any sentence the model writes containing a figure that plain code did not already compute is thrown away and replaced with a template. If you cannot point to where that boundary is in your app, it does not have one.

7. Nothing is logged

What happens: the app cannot answer the question "what did it do yesterday". So the first sign of trouble is an angry customer, and the investigation is archaeology.

The classic quiet failure: an API account runs dry, every run starts failing, and nothing looks different from a quiet day. Our systems page on the exact errors that mean the money ran out, and a watchdog confirms the critical jobs are still installed, because silence reading as health is how outages hide.

The fix: every run writes a line: when it started, what it did, whether it succeeded. Silence gets an alert, because the failures that hurt are the quiet ones. And something has to watch the watcher.

8. There is no plan for when the model is wrong

What happens: the app assumes the model answers well every time. Then the model has a bad day, or the provider has an outage, and the app either falls over or, worse, confidently serves nonsense.

The fix: decide, for every model call, what happens when the answer is wrong or missing. Sometimes the fallback is a template. Sometimes it is a retry. At every point where a mistake is expensive, it is a person: our property agent prepares the dossier, and a human closer takes the conversation from there. The preparation is the automation. The judgement is the product.

9. Nobody owns it at two in the morning

What happens: the app runs on the freelancer's hosting account, the domain is registered to someone's cousin, the model key belongs to a personal account, and the person who vibe-coded it has moved on. When it breaks at night, there is no one to call and nothing you can even log into.

The fix: every account in the business's own name from day one: hosting, domain, database, model keys. A short runbook that says what runs where and what to do when it stops. A named person who answers. This is the least technical item on the list and the one that decides whether a bad night is an incident or a catastrophe.

Vibe code the demo. Engineer the product.

The pattern in all nine is the same: vibe coding optimises for the moment the screen first works, and production is everything after that moment. The tools are genuinely good now. The first day is cheap. The mistakes above are what fill the gap between a thing that worked once and a thing that works on Tuesday.

If you have a vibe-coded app that real customers now depend on, we run a two-week assessment at a fixed fee that checks all nine of these, in writing, credited against any build. The honest outcome is sometimes that your app is fine. The useful outcome is knowing which of the nine you are carrying before your customers find out for you.