Skip to content
SmallShopAustralian Made Software
← All insights
If you've heard the term and want to know what it actually means for something you're about to launch

Vibe coding: what it actually means, and where the risk is hiding

The term describes building software by describing what you want and accepting the code back without reading it. The risk was never the AI — it's the not-reading part.

5 min read
Protect

The term was coined to describe a specific way of working: you describe what you want in plain language, an AI tool writes the code, and you accept it without reading it closely, judging it by whether it runs rather than by what it actually does. That's not a criticism of the tools — Lovable, Bolt, v0, Cursor and Claude Code are genuinely good at producing working software fast. The phrase describes a choice about how closely anyone checked the output, and that choice is where the risk actually lives.

For a weekend project or a throwaway prototype, not reading the code is a completely reasonable trade. The problem shows up when the same app, built the same way, quietly becomes the thing real customers sign up for — and nobody went back to check it against a different bar.

Veracode's 2025 GenAI Code Security Report found that 45% of tested code-generation tasks produced code containing a known security weakness. That's not a comment on any one tool. It's the reason "it runs" and "it's safe" are separate questions, and why the gap between them is exactly where nobody's looking if nobody's reading the code.

Where it tends to go wrong in practice

  • Secret keys placed in code that runs in the visitor's browser, where anyone can read them, because the app works either way.
  • A database with no real rule stopping one customer's request from reaching another customer's data.
  • A server that trusts whatever the browser tells it, rather than checking who's actually asking.

None of these make the app look broken. That's the whole shape of the risk — it's invisible from the outside, and invisible to whoever's using the app as intended, right up until someone tries to use it in a way it wasn't checked against.

The actual fix isn't "stop vibe coding"

It's adding the reading back in, once, before real customers arrive — not rewriting the app, and not switching how it gets built. A second pair of eyes, checking specifically for the handful of things that look fine and aren't, closes most of the gap without touching how fast the next feature gets shipped.

Read next

All insights