How it works
Vibe coding inverts the usual order of software work. Instead of deciding what to build and then building it, you prompt a coding agent, watch what appears, and react. The loop looks like this:
- You describe a feature in loose natural language.
- The agent generates code, often across many files.
- You run it, glance at the result, and prompt again to fix or extend.
- Repeat until the thing roughly works.
No written specification anchors the process. The requirements live in your head and drift with each prompt. The only durable artifact is the code the agent produced, so the code becomes the specification by default — whatever it does is what the system now "means." Decisions a spec would make explicit (edge cases, invariants, error handling, data shape) are made implicitly by the model, one generation at a time, and you inherit them without having chosen them.
The term is casual, but the mechanism is precise: you are trading an explicit contract for fast feedback. For a throwaway prototype that trade is often correct. The danger appears when vibe-coded output quietly graduates into something people depend on, because nothing recorded the intent it was supposed to satisfy.
Why it matters in an agent harness
In a harness, vibe coding is not a personal style — it is a governance gap. A harness exists to keep an agent controllable, reversible, and legible. Vibe coding removes the reference those controls depend on.
Without a spec, you have nothing to evaluate against. Evals need an expected behavior; "looks right" is not a fixture. Regression evals become impossible because there is no recorded contract a later change might violate — the agent can rewrite the meaning of the system and no check will fire.
Reversibility degrades too. Rollback and checkpoints let you return to a known-good state, but "known-good" assumes you know what good was. If the intent was never written down, a checkpoint just preserves an older set of vibes.
Observability suffers similarly: diff review tells you what changed, not whether the change was authorized by any intent. You end up reviewing volume instead of decisions.
The practical failure is scope creep inside a single session. Each prompt nudges the code, blast radius grows, and the agent accumulates undocumented behavior faster than a human can audit it. The harness answer is not to ban exploration — it is to force intent to become an artifact before output is allowed to persist, so evals, rollback, and review have something to hold onto.
Vibe coding vs spec-driven development
The distinction changes where you place the control point, so it is worth making explicit.
| Dimension | Vibe coding | Spec-driven development |
|---|---|---|
| Order of work | Build, then infer intent | Decide intent, then build |
| Source of truth | The running code | The written spec |
| Evals | Nothing stable to test against | Spec yields fixtures and assertions |
| Reversibility | "Known-good" is undefined | Checkpoints map to intended behavior |
| Best fit | Throwaway prototypes | Anything others will depend on |
The table is not a verdict against speed. It shows that the two approaches put the human decision at different moments — before generation, or never — and only one of them leaves a harness something to enforce.
The Rifty take
We treat vibe coding as a legitimate first gear and a dangerous cruising speed. Explore by feel when the cost of being wrong is a discarded branch. The moment the output is meant to persist, we make the intent an artifact and let the harness gate on it. The tradeoff we accept is a slower start in exchange for a system whose behavior is something you chose, not something you discovered after the fact.
Common failure modes
- A prototype is promoted to production with no spec ever written, and the code silently becomes the contract.
- Requirements live only in prompt history, which is later discarded or compacted away.
- Evaluation collapses into "run it and eyeball it," so regressions ship without firing a single check.
- Diff review degrades into rubber-stamping large agent-generated changes nobody can fully trace.
- Each session quietly redefines edge cases the previous session had settled.
- Rollback restores the code but not the lost intent behind it, so recovery is guesswork.
Frequently asked questions
Is vibe coding always a bad practice?
No. Vibe coding is a reasonable first gear for throwaway prototypes and exploration, where the cost of being wrong is a discarded branch. It becomes a liability only when the output is promoted into something people depend on without anyone writing down the intent it was meant to satisfy.
How does vibe coding break evals?
Evals compare actual behavior against an expected contract, and vibe coding never records that contract. With no spec, there is no fixture and no regression baseline, so "looks right" replaces measurement. The agent can rewrite the system's meaning between runs and no check will ever fire.
What is the opposite of vibe coding?
Spec-driven development is the practical opposite. You decide the intended behavior first, capture it as a written spec, and build against it. That spec becomes the source of truth, yields eval fixtures, and gives checkpoints and rollback a defined notion of "known-good" to return to.
How do you contain vibe coding inside an agent harness?
Force intent to become an artifact before output persists. Let exploratory sessions run freely, but gate anything durable on a recorded spec, diff review tied to that intent, and evals derived from it. The rule is not to ban feel-driven work — it is to stop undocumented behavior from graduating into production.
Why does vibe coding grow blast radius over time?
Because each prompt nudges the code without an anchoring contract, the agent accumulates undocumented decisions faster than a human can audit them. Scope creeps within a single session, edge cases get silently redefined, and reviewers end up processing volume instead of authorizing decisions — so unintended behavior spreads unchecked.