Over the last few months, I’ve experimented quite a bit with the two main approaches people use today to build software with models like Cursor, Claude, or any advanced coding agent.

On one side there’s Vibe Coding, on the other Spec-Driven Development. These aren’t just different techniques: they represent opposite ways of dividing control between you and the LLM.

In Vibe Coding, you set an atmosphere, a general intention, and then let the model carry you forward in the flow.

You write something like: “Let’s create a dashboard to monitor monthly subscriptions. I want a clean look but with a retro-futuristic touch, dark mode by default, discrete animations, shadcn/tailwind components.”

From there starts a continuous dialogue: it proposes, you correct (“the card is too wide”, “move the chart to the right”, “add a small glitch effect on refresh”), it adapts, you refine the feeling.

It’s a very fluid process, almost conversational. You move incredibly fast, discover solutions you wouldn’t have considered alone, and the result often has a creative energy people really like.

The downside is that after 30–60 minutes of iterations, you can end up with a codebase that works well but is hard to explain to someone (or to yourself in three months). The structure tends to be more organic than intentional.

Spec-Driven Development flips the dynamic: you’re the one dictating the rules with precision.

First you write a detailed spec (usually 600–1500 words) that covers:

• business objective
• functional and non-functional requirements
• technical constraints (performance, bundle size, accessibility)
• preferred architecture (folder structure, state management, API contract)
• important edge cases
• design system components to respect

Then you pass it to the LLM with clear instruction: “Implement exactly this spec. Don’t simplify, don’t invent extra features, follow the structure and constraints indicated.”

In this case the model becomes an extremely capable executor but with very little creative freedom. The code that comes out is almost always more readable, testable, maintainable and predictable over time.

I don’t think there’s a “right” approach in absolute terms. It depends on the moment in your project and your objective:

rapid exploration, prototypes, side projects, idea validation in a few days → vibe coding is hard to beat for speed and creativity

product that needs to be maintained by a team, pass security reviews, scale, or last for years → spec-driven provides a much more solid foundation

These days, what works best for me is a conscious hybrid:

initial discovery and prototyping phase → vibe coding at 100%

once you’ve figured out the direction → rigorous spec for core parts and final refactoring/clean-up

Basically I go from letting myself be guided by the LLM’s flow to taking the helm when the stakes rise.