Defining vibe coding

Vibe coding, as the term is generally used, describes building software primarily by describing intent in natural language and accepting an AI agent's generated code with minimal review - optimizing for speed of a working result over understanding of how it works. The term was popularized to describe a genuinely new and useful workflow: for prototypes, internal tools, and throwaway experiments, this is often the right trade-off. The risk shows up when the same loose-review workflow is used to build something that will handle real customer data or real money.

Defining vibe engineering

Vibe engineering describes the same starting point - natural-language prompts driving an AI agent - but with the review discipline of traditional software engineering kept intact: explicit architectural requirements in the prompt, a human refactor pass, and verification through tests and code review before anything ships. It's not "no AI assistance" - it's AI assistance inside an engineering process, rather than instead of one. This is effectively the same distinction our PRV Cycle piece describes in more operational detail.

The two terms describe a spectrum, not two rigid categories - most real projects sit somewhere between "accept every suggestion" and "review every line as if a junior engineer wrote it." The useful question isn't "which camp are we in," it's "where on this spectrum does this specific piece of code need to sit, given what it touches."

The architecture of the difference

VIBE CODING Natural-language prompt AI-generated code Accepted as-is, shipped VIBE ENGINEERING Prompt with explicit architecture stated AI-generated code Human refactor into existing conventions Tests + review, then ship

The workflows start identically. The difference is what happens after the model responds - nothing, or a refactor-and-verify pass.

The specific risks vibe coding skips

Security

Auth checks, input validation, and data isolation are exactly the kind of implicit decisions an unreviewed prompt leaves to the model's defaults - and defaults vary by model, by prompt phrasing, and by day.

Data integrity

Transaction boundaries and idempotency - covered across our notification and payment pieces - are rarely specified in a loose prompt, and rarely correct by default when they're not.

Maintainability

Code accepted without a refactor pass tends to diverge from a codebase's existing conventions with every new feature, compounding into a codebase no one - human or AI - can confidently modify.

Where the line should actually sit

Not every line of code needs the same scrutiny. A throwaway internal script or a rough prototype used to validate an idea with five users is a reasonable place for pure vibe coding - the cost of a bug is low, and the value of speed is high. A checkout flow, an auth system, or anything touching customer data belongs on the vibe engineering side of the spectrum regardless of how fast the alternative feels, because the cost of a bug there is not low - it's the kind of cost covered in our piece on what a missing idempotency check actually does to a payment system in production.

Key takeaways

  • Vibe coding and vibe engineering share a starting point (natural-language prompts) but differ entirely in what happens after the model responds.
  • Vibe coding is a reasonable choice for prototypes and low-stakes internal tools - the risk is applying the same lack of review to production, customer-facing, or transaction-critical code.
  • The specific risks skipped are security (auth, validation, isolation), data integrity (transactions, idempotency), and long-term maintainability.
  • The PRV Cycle - prompt with architecture stated, refactor into conventions, verify with tests and review - is the concrete practice of vibe engineering.
  • The right question for any given piece of code isn't "are we vibe coding or vibe engineering" - it's "does what this code touches justify skipping the review."
If you're not sure which side of that line your current codebase actually sits on, that's a fast thing for a second set of eyes to assess - often faster than continuing to guess.