A lot of people say the new skill is writing better specs. I agree, but I think there is a trap here. A good spec is not just a more detailed prompt. It comes from understanding the domain AND software engineering well enough to know what should not be left open.
What are the invariants? What states are allowed? What must never happen? What should be rejected even if it looks plausible? And also: where can the system break in real implementation? Retries, race conditions, idempotency, validation boundaries, authorization, partial failure, contract drift.
And a couple hundred other decisions a good SWE makes to make a digital product evolvable, not collapsing under fast-growing complexity.
That is the part agents do not solve for you. Agents can suggest generic solutions, but they do not know which solution is correct for your concrete system. Moreover, they cannot tailor the solution to a concrete system if a person does not know what exactly should be tailored and how.
They can help write the spec, expand it, and check it against the code. But they cannot replace the engineering judgment behind it. This is where spec-driven development can quietly turn into vibe coding.
The agent still guesses about hundreds of things in your system. The developer still approves something that "looks right". The system meanwhile accumulates hidden complexity. And now each iteration happens much faster.
Spec-driven development is not automatically the opposite of vibe coding. It becomes the opposite only when the spec is grounded in real domain understanding and engineering judgment.
Otherwise it can become the same thing, just with longer documents, which also have to be maintained as an additional source of truth (sometimes a temporary one).