Vibe coding: when to explore and when to specify
Vibe coding (term popularized early 2025): prototype fast without reviewing code. Useful in spikes; risky in prod (security, maintainability). Switch to specs and RPI when a customer or sensitive data enters.
Useful definition (not the hype)
Vibe coding is LLM-assisted development where you describe intent in natural language, let the model generate code, and focus on visible outcomes (demo, quick manual tests), often without deep diff review. The term was popularized in February 2025 (Andrej Karpathy) and quickly slid from weekend throwaway to product talk.
It is not every AI use in the IDE. Assisted engineering (spec, review, tests, ownership) remains craft. Strict vibe means accepting to “forget the code exists” while iterating.
Excellent time-to-demo. Durable product only if you draw a boundary. Recurring critiques: fuzzy accountability, maintainability, security surface (auth, secrets, invented deps).
Where vibe coding works
Spikes, POCs, throwaway UI, one-shot scripts, exploring an unknown library, scaffolding. throwaway/ branches with an expiry date.
Solo or founder: validate a hypothesis in hours. Learning: read generated code as a tutor, if you understand it before merge.
Rule: failure must be cheap. If a customer pays, or personal data or payments are in play, you leave pure vibe mode.
Where it breaks in production
Demo/product confusion: silent debt (divergent styles, missing tests, secrets in chat) costs more than the initial gain.
Security: hacked-together auth, missing validation, unaudited deps. Generated code often “skips” review if the team does not force a checklist.
Lucidity: nobody dares touch the module. More commits does not mean more value. We look at incidents and review time.
Stop prompting in a loop when the need is unclear. Specify. Clarity of need beats prompt creativity.
From vibe to specs and RPI
Minimal spec: user goal, out-of-scope, forbidden data, testable acceptance criteria, risks. One page is enough.
Research → Plan → Implement: gather context, plan files and tests, implement only after a reviewable plan. On complex bases a short RPI is not enough: add design and handoffs between phases (link Claude Code compact if the session is long).
Subagents for isolated research: their context does not pollute the implementation agent.
Disposable code: allowed on an isolated branch. Forbidden on main without rewrite on critical paths.
Planning vs acting
Acting without a plan speeds noise. Planning without shipping does too. Team rule: short reviewable plan, then action; if action drifts, re-plan, do not vibe harder.
Merge checklist: versioned spec, tests or scenarios, no secrets, human review auth/payments/PII, success metric.
If you want a vibe coding / specs workshop on a real repo, we can scope in 20-40 minutes.
FAQ
- Who coined vibe coding?
- The term was popularized in February 2025 by Andrej Karpathy (widely cited public posts). Meaning shifts by author; we keep: LLM generation with little deep review.
- Should companies ban it?
- Rarely. Bound it to spikes and throwaway branches. Bans drive shadow IT.
- Is vibe coding no-code?
- No. Vibe coding generates code via LLM. Debt and ownership differ from visual builders.
- What is RPI?
- Research, Plan, Implement: research, plan, implement after plan validation. Cuts generative slop.
- Link to Claude Code?
- Claude Code makes vibe more powerful, hence riskier without a spec. Compact/clear and plan files limit damage.
- Solo founder?
- Same rules: vibe to explore, spec as soon as a customer pays or sensitive data enters.
Scope your first AI agent
20 minutes to review your tools, data and the first useful case. No jargon, no commitment.