The two postures
Spec-driven work treats the model like a fast junior engineer. You write down the requirement, the constraints, the files that will change, and the verification step. The model produces code that fits inside the box you drew.
Vibe-driven work treats the model like a sketchpad. You think out loud, the model writes something, you react, it adjusts. The product of the conversation is the spec, written in code instead of prose.
When the spec wins
Anything that touches production, anything with a database migration, anything that another person will read in six months. The cost of a wrong assumption compounds, and a spec is the cheapest way to force the assumption into the open before the diff exists.
Also true for any task where the failure mode is silent. Payments, auth, analytics events, security headers. If the bug will not show up in a screenshot, write the spec first.
When the vibe wins
Early exploration. You do not know what you want yet, and writing a spec for something you have not seen is a slow way to discover that the spec was wrong.
Visual and layout work. A round trip of "make this look more like X" against a live preview is faster than any document.
One-off scripts. If the code will run twice and then be deleted, planning it is overhead.
The middle path I actually use
Most of my real work is vibe at the start and spec at the end. I explore freely until the shape of the thing is clear, then I stop, ask the model to summarize what we have built and what is missing, and turn that summary into a spec for the rest.
The transition point is the moment I notice myself saying "okay but make sure it also handles" for the third time. That is the signal that the conversation has produced enough surface area to need a written contract.
A failure mode in each camp
The spec camp over-specifies. A two-page document for a one-line change is a smell. The model does not need the same context a human reviewer does. Spec for the decisions, not the typing.
The vibe camp under-reviews. A working preview is not a working feature. The model will happily produce a button that looks right and dispatches no event. Treat every vibe session as draft code until you have read the diff.
The thing both camps agree on
You still have to know the stack. The spec writer who does not understand the framework writes specs that the model cannot satisfy. The vibe coder who does not understand the framework ships bugs that look like features. There is no version of this where the human gets to stop reading code.