DEV Community

Cover image for Vibe coding is fun — until it hits production
Ksatria Bintang Samudra
Ksatria Bintang Samudra

Posted on Originally published at ksatriabintangsamudra.com

Vibe coding is fun — until it hits production

"Vibe coding" is the perfect name. You describe what you want, the AI produces it, you run it, and if it works, you move on — steering by feel, never really reading the code. It is genuinely fun, genuinely fast, and genuinely fine… right up until it isn't.

Where vibe coding is great

I'm not here to gatekeep. Vibe coding is a legitimately good tool for:

  • Prototypes and spikes — proving an idea in an hour instead of a day.
  • Learning — poking at a new framework by generating and running things.
  • Throwaway scripts — one-off tasks where "works once" is the whole requirement.

For those, not reading every line is a feature. Speed is the point, and the cost of being wrong is basically zero.

Where it quietly bites

The trouble starts when vibe-coded code sneaks into production — because the same "don't read it, just ship it" that made it fast becomes the liability:

  • Security holes you never saw. The model happily writes code that concatenates user input into a query or trusts the client. If you didn't read it, you didn't catch it. (This is how classics like SQL injection get shipped.)
  • Edge cases nobody handled. "It worked when I tried it" is not "it handles empty input, timeouts, and two users at once."
  • Code nobody understands. The most expensive outcome: production code that no human on the team actually comprehends. When it breaks at 2am, "the AI wrote it" is not a debugging strategy.

None of these show up in the demo. All of them show up in production.

The mode switch

The answer isn't to stop using AI — I ship with it constantly. It's to change modes when the stakes change. Vibe for the prototype; engineer for the product.

Graduating a vibe-coded prototype looks like this:

  1. Write down what it must actually do — the spec you skipped.
  2. Read the code the AI wrote. All of it. Understand it well enough to defend it.
  3. Test the edge cases, not just the happy path.
  4. Check the security-sensitive paths — auth, input handling, anything touching money or data.
  5. Verify the built artifact, because what ships isn't always what the model said it produced.

You keep the speed of AI and add the rigor of engineering. That's the whole trick.

The honest take

Vibe coding isn't the enemy — unread code in production is. Let the AI move fast where being wrong is cheap, and slow down to actually understand things where being wrong is expensive. The developers who win with AI aren't the ones who vibe the hardest; they're the ones who know exactly when to stop vibing and start engineering.

Top comments (0)