Vibe coding: when to explore and when to specify

Useful definition (not the hype)

Vibe coding is an LLM-assisted development mode where you describe the intent in natural language, let the model generate the code, and focus on the visible outcome (the demo, a few quick manual tests), often without deep diff review. The term was popularized in February 2025 by Andrej Karpathy, and it quickly slid from weekend throwaway to product talk.

Not every AI use in the IDE is vibe coding, though. Assisted engineering, with a spec, a review, tests and ownership, remains craft. Strict vibe means accepting to “forget the code exists” while iterating.

Time-to-demo is excellent. A durable product, however, only comes if you draw a boundary. The recurring critiques target fuzzy accountability, maintainability and the security surface: auth, secrets, invented dependencies.

Where vibe coding works

Vibe coding shines wherever failure costs nothing:

• Spikes and proofs of concept
• Throwaway UI and one-shot scripts
• Exploring an unknown library
• Scaffolding, on throwaway branches with an expiry date

Solo or as a founder, it lets you validate a hypothesis in a few hours. For learning, you can read the generated code like a tutor, as long as you understand it before merging.

The rule fits in one sentence: 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

Confusing the demo with the product gets expensive: the silent debt (divergent styles, missing tests, secrets in the chat) quickly outweighs the initial gain.

On the security side, you find hacked-together auth, forgotten validations and unaudited dependencies. Generated code often “skips” review if the team does not force a checklist.

The last symptom is human: nobody dares touch the module anymore. Remember that more commits does not mean more value. We look at incidents and review time.

When the need is unclear, stop prompting in a loop and specify. Clarity of need beats prompt creativity.

From vibe to specs and RPI

A minimal spec fits on one page: the user goal, the out-of-scope, the forbidden data, testable acceptance criteria and the risks.

The RPI loop (Research, Plan, Implement) structures the rest: you gather the context, plan the files and the tests, then implement only after a reviewable plan. On complex codebases, a short RPI is not enough: we add a design phase and handoffs between phases (see Claude Code's compact if the session runs long).

Subagents are there to isolate the research: their context does not pollute the implementation agent.

Disposable code stays allowed on an isolated branch. It is forbidden on main without a rewrite as soon as a critical path is touched.

Planning vs acting

Acting without a plan speeds up the noise, and planning without shipping does too. The team rule is simple: a short reviewable plan, then action. If the action drifts, we re-plan, we do not vibe harder.

Before merging, the checklist fits in five points:

• A versioned spec
• Tests or scenarios
• No secrets in the code or the chat
• Human review on auth, payments and PII
• A success metric

If you want a vibe coding / specs workshop on a real repo, we can scope it in 20-40 minutes.