Glossary / AI & Vibe Coding
Vibe Coding
Vibe coding is building software by describing what you want to an AI coding tool in natural language and accepting the code it generates, rather than writing most of it by hand. The developer steers with prompts and reviews output instead of authoring every line.
What is vibe coding?
Vibe coding is building software by describing what you want to an AI coding tool in natural language and accepting the code it generates, rather than writing most of it by hand. The developer steers with prompts and reviews output instead of authoring every line.
Key takeaways
- Vibe coding generates real source code from prompts, so you own the code and its problems.
- A working demo is not a shippable product; the failure modes move from "broken" to "quietly insecure".
- The three usual leaks: a live key in the bundle, a database with no row-level security, and public source maps.
- Use AI to reach a prototype fast, then treat that prototype as a spec and do a real security and design pass.
Why it matters
It has collapsed the time from idea to working prototype from weeks to hours, which is genuinely powerful for validation. But the same speed ships code no human has read line by line, so the failure modes move from "it does not work" to "it works, and it is quietly insecure or unmaintainable".
Common mistakes we see
The pattern we see most often is a founder who has a working app in a weekend and assumes "working" means "done". It rarely is. Vibe-coded front ends routinely ship the production API key in the JavaScript bundle, leave the backend database open because row-level security was never turned on, and deploy source maps that hand a competitor the full source. None of that shows up in the demo. The generated code also tends to be locally correct but globally inconsistent: three different date pickers, four ways of handling errors, state that works until two users touch it. Our rule is simple. Use AI to reach a prototype fast, then treat that prototype as a spec, not a foundation. Before real users touch it, someone who understands security, state and design systems has to do a proper pass. That pass is cheap now and expensive after you have a thousand accounts.
When to use it, and when not
Use it when
- Validating an idea or building a throwaway prototype fast.
- A solo founder or small team without engineering capacity yet.
- Internal tools where the blast radius of a bug is small.
Think twice when
- Anything handling real user data or payments without a security pass first.
- A product you will scale, where consistency and maintainability matter.
- Regulated or high-trust contexts where a quiet leak is a serious breach.
How it compares
| Vibe coding | No-code | Hand-written | |
|---|---|---|---|
| Speed to prototype | Hours | Hours | Days to weeks |
| You own the code | Yes | No | Yes |
| Security handled for you | No | Mostly | No |
| Ceiling on complexity | High | Low to medium | High |
Vibe coding compared with the alternatives
Before you ship a vibe-coded app
- No secret or server key appears in the shipped JavaScript.
- Row-level security (or equivalent rules) is on for every table.
- Source maps are not served in production.
- Security headers (CSP, HSTS, frame options) are set.
- A human has reviewed auth, state handling and accessibility.
Example
A solo founder builds a client portal with an AI tool in two evenings. It works. A passive scan finds the Supabase service key in the bundle and the users table readable by anyone. The fix took an afternoon; had it launched, it was a breach.
Related terms
See our vibe coding development service
We take vibe-coded prototypes to production: security, state, design system and the polish real users need.
See our vibe coding development service
