Seven Vibe Coding Mistakes That Only Show Up After You Ship

Vibe coding works. That is the part the arguments about it keep missing. You describe what you want, a model writes it, and something real exists by the evening. For a landing page, an internal tool, a prototype you are going to throw away, it is the fastest thing that has ever happened to software.

The mistakes are not in the code you can see. They are in the questions nobody asked, and they surface weeks later, when there is money moving through the thing.

1. Accepting code you cannot read

This is the root mistake and every other one grows out of it. If you cannot read what came back, you cannot tell working from looks-like-working, and those are indistinguishable in a demo.

The fix is not learning to code. It is narrowing what you accept. Ask for one thing at a time, in small pieces, and make the model explain what each piece does before you keep it. An explanation you do not understand is a piece you should not ship.

2. Trusting the browser

The single most expensive category, and it looks completely normal in generated code.

A price calculated in the front end and sent to the server. A discount validated in JavaScript. A quantity check that runs in the component. Every one of those works perfectly until somebody opens developer tools and changes the number, because anything running in the browser belongs to the customer, not to you.

The rule is simple and models will not apply it unless told: the browser asks, the server decides. Prices, discounts, stock and totals get recalculated on the server from your own data, every time, no exceptions.

3. Letting the generated schema become the product

Ask for a store and you will get a products table with a price column. That is correct for about a month.

Then you need a second size, and price belongs to the variant rather than the product. Then a sale price with dates. Then tax treated differently by state. Then an order that has to remember what the price was at the time it was placed, because that is what the customer paid and refunds depend on it.

Each of those is a schema change to a table that now has real rows in it. The model gave you a reasonable starting point and had no idea what you were going to sell.

4. Never asking what happens when it fails

Generated code describes the path where everything works. Ask what happens when the payment provider times out after charging the card, when the same webhook arrives twice, when a customer double-clicks the pay button, and the answers usually do not exist.

These are not rare. Networks drop, providers retry, people click twice. In an ordinary app the result is a confusing screen. Where money is involved, the result is a double charge and a refund you have to work out by hand.

5. Treating tests as something for later

Understandable, and it inverts what vibe coding is actually good at. Models are excellent at writing tests, because a test is a small, self-contained, precisely specified thing.

More usefully, tests are how you keep changing code you cannot read. Without them, every new prompt risks silently breaking something that worked yesterday, and you will not find out until a customer does.

6. Shipping every key you were given

Ask for a payment integration and the model will use the key you pasted. It does not know which of your keys is safe in a browser and which one reads every order you have ever taken, and it will not ask.

Anything in your front end bundle is public. Not hidden, not obfuscated, public, in a file anyone can open. This has its own article because it is the mistake with the worst consequences.

7. Building the boring half yourself

The last one is strategic rather than technical.

Catalog, cart, checkout, orders, customers, inventory, shipping, refunds. None of it is interesting and all of it is solved. It is also the exact part where the six mistakes above do damage, because it is the part that touches money.

Vibe coding is genuinely strong at the storefront: layout, interaction, copy, the thing your customers look at. It is weakest at the transactional core, which is where being subtly wrong is most expensive. Building that half yourself, with a tool that is best at the other half, is the mistake underneath the other six.

What to do instead

Keep vibe coding the part you can evaluate by looking at it. Ask for small pieces and reject what you cannot follow. Move every decision about money to the server. And for the part where errors cost money rather than time, use something that already solved it.

That is what we mean by vibe the front end and rent the back end, and it is less a sales pitch than a description of where the failures actually happen.

If you want to see what the transactional half looks like when you are not writing it, the docs are the endpoints.