“Vibe coding” describes a real workflow: describe the intent, accept a large generated change, steer by feel, ship a demo before lunch. It is exhilarating. It is also a poor description of how multi-person products stay coherent across quarters.
Requirements-driven development is the opposite stereotype: documents first, implementation second, change control forever. It is slow when discovery is cheap. It is still correct when the cost of ambiguity is billed in outages, compliance, or human safety.
Individuals optimize for flow; teams optimize for memory
A single practitioner can hold the prompt history, the half-finished branch, and the informal acceptance criteria in their head. A team cannot. The moment a second engineer, a reviewer, a security owner, or an on-call rotation enters the loop, vibes become unpaid tribal knowledge.
That is why “just use the model more” fails as an org strategy. Models amplify whatever process already exists. If the process is a private chat transcript, amplification produces private chat debt.
Where vibe shines
- Greenfield spikes and throwaway prototypes (see also RAD’s comeback).
- Local refactors with strong tests already in place.
- Exploring an unfamiliar API surface before writing the real design.
- Personal automation that never becomes a shared service.
Where requirements still earn their keep
- Cross-team contracts: APIs, events, identity boundaries.
- Regulated change: audit trails, approvals, dual control.
- Long-lived products where today’s shortcut is next year’s outage narrative.
- Any merge that can spend real money or expose customer data.
Teams need tooling — five product categories
We will not invent fake product names to sound like a market map. The honest cut is by job-to-be-done:
Most organizations already own fragments of these categories under different brands. The editorial question is coverage: if you only buy IDE agents, you optimized the individual’s vibe. If you skip governance, you automated liability. If you skip orchestration, you collected chat windows.
A blended operating picture
- Use vibe sessions for discovery; capture survivors as lightweight requirements before shared branches.
- Route implementation through IDE or cloud agents with explicit ownership.
- Require review bots on the default path — not as optional theater.
- Reserve orchestration/factory patterns for repeated ship loops, not one-off demos.
- Keep governance proportional to blast radius; never zero for production.
Honest ending
Vibe coding is not unserious. Requirements are not bureaucracy by default. The unserious move is pretending a one-shot single-model session is a software lifecycle. Publications like this exist to keep that distinction sharp while the tooling categories mature.