"Vibe coding" started as a joke term — describing sessions of prompting an AI agent and accepting whatever it produces without closely reading the code — and turned into an actual, named workflow because enough people were genuinely building real things that way. The honest version of the term isn't "write code you don't understand"; it's "let the AI hold the syntax while you hold the intent and taste."
Why Vibe Coding Matters (and When It's a Trap)
For prototypes, throwaway scripts, and exploring whether an idea is worth building at all, describing intent in plain English and iterating on the AI's output is genuinely faster than writing every line by hand — you're optimizing for speed of exploration, not code you'll maintain for years.
It becomes a trap the moment the thing you built needs to survive contact with real users: production auth, payment handling, data migrations, anything with security or correctness implications. Code you never read carefully is code you can't debug when it breaks at 2am, and "the AI wrote it" is not a root cause.
Getting Started (the Version That Doesn't Bite You Later)
The workable version of vibe coding still has a loop, just a looser one than traditional development:
claude "build a CLI tool that renames files based on their EXIF date"
# review the output, run it on a test folder
claude "handle the case where EXIF data is missing — fall back to file mtime"
# run again, looks right, ship it
The key discipline: you're still testing the actual behavior, even if you're not reading every generated line. Vibe coding without any verification step isn't a faster workflow — it's just gambling with extra steps.
Core Concepts Every Developer Should Know
1. Vibe coding is a spectrum, not a binary. Fully hand-reviewed code is one end; fully unread, unverified code is the other. Most productive AI-assisted work lives somewhere in the middle — skim the diff, run it, read closely only where it matters.
2. Match the rigor to the stakes. A weekend hackathon project and a payment integration deserve wildly different amounts of scrutiny on AI-generated code. Calibrate, don't apply one policy everywhere.
3. Tests substitute for reading, partially. If you're not reading every line, a solid test suite the AI also has to satisfy is the next best verification layer — it catches regressions even when you didn't personally review the fix.
4. "It works" isn't the same as "it's correct." Code that passes your manual smoke test can still have edge cases, security holes, or performance cliffs that only show up under real load — vibe coding compounds this risk because nobody looked closely enough to notice.
Common Mistakes and How to Fix Them
Mistake 1: Vibe coding production auth or payments. These are exactly the domains where an unnoticed logic error has real consequences. Read every line here, full stop — no shortcuts.
Mistake 2: No tests as a safety net. Skipping both code review and test coverage means you have zero signal when something's wrong until a user finds it.
Mistake 3: Treating "the demo works" as done. A prototype that works once in front of you is not the same as a system that works reliably. Know which one you're building before you decide how much vibe coding is appropriate.
When Should You Vibe Code?
Prototypes, internal tools, scripts, weekend projects, and exploring whether an idea is even worth pursuing. Anywhere the cost of being wrong is "I redo it," not "a user's data is corrupted."
In Practice
I vibe code prototypes and internal tooling regularly — fast iteration, low stakes, and I read closely only when something looks off. Anything shipping to suhailroushan.com's production paths gets read line by line regardless of how it was generated. The term is fine; the discipline about where you apply it is what actually matters.
Before your next AI-generated feature ships, ask honestly: did I actually read this, or did I just watch it work once? The answer should match the stakes.