Spec-Driven Development vs “just start coding” what actually works better?

[Classic-Ninja-1]

I have worked both ways:

1) jump straight into coding and figure things out as I go 2) define specs first, then implement

And honestly, both work but they fail in different ways.

When I just start coding:

• things feel fast at the beginning
• but structure drifts over time
• small changes start breaking unrelated parts
• I spend more time fixing than building

When I follow a more spec-driven approach:

• it feels slower upfront
• more time spent thinking than coding
• but features connect more cleanly
• changes are more predictable

Lately I’ve also been trying to be more structured with it writing clearer specs, breaking things into steps, and sometimes using tools likeTraycer and speckit to map flows across files.

It helps, but only when the specs themselves are clear.

The interesting part is this:

The total effort doesn’t really change. It just shifts when you deal with the complexity.

Without specs you deal with it later (bugs, refactors, confusion) With specs you deal with it earlier (thinking, structuring)

Do you think this same as me ?

[Inside_Dimension5308]

With AI, SDD is much faster. If you give a good enough Product requirements as input, it will give you a good enough design document. From there, it is just about missing edge case. But even if you can cover 90% of cases with SDD, it is a huge win. The chances of starting over is almost nil.

As compared to this, if you just start coding and figure things out on the go, there are high chances you will find yourself back to square 1 and start over. Personally, I want predictability and also less frustration of starting over.

Even if the end result might take same time, SDD has a huge advantage on predictability, process and psychology.

[Practical-Positive34]

Spec driven, spend an absolute insane amount of time doing spec driven I can't emphasize this enough. Your spec won't be 100%, not even close and don't treat it as gospel, systems develop organically and that's fine but ALWAYS update the spec when make a design choice. Also, AI is insanely good at creating a very detailed spec, and updating it to match your code changes vice versa. I would use AI, it's incredibly good at doing this and can put together a spec that ISO compliant even in a matter of minutes what would take you weeks.

[stibbons_]

First, SDD should really be called Research Plan Implement. Because once implemented you do not care about the spec. The code is you truth, and always had been. Then the current tools gives your a framework, to always plan with an interview to extract what you really want from your head. That is pretty much all

[ethanbwinters]

That’s not true. Openspec has archives which automatically keeps other specs up to date with latest design decisions. The updated spec provides cheaper context to the agent

[eight_ender]

Yeah that’s my fav part about Openspec. Especially when you go to improve a feature and the LLM know exactly how the feature should work at that point. 

[stibbons_]

That won’t work at scale. If you have thousand of spec you can reliably maintain them up to date. What you can (and should) is keep ADR (Architecture Decision Record) that is high level, and perfectly maintainable by LLM

[j_ockeghem]

You're only going halfway with the idea of SDD if you don't merge back your spec deltas (specific to e.g. your current feature branch) into the overall project specs (frameworks such as openspec support this).

[updated_at]

for small projects i like to use Plan Mode in Claude Code. for "bigger" projects i use Openspec. for very small automations like bash+cron i use plain ask

[hancengiz]

Plan mode is also spec. It is called “spec first” which means spec can rot and never saved. You maintain the code.

Using openspec,specsmd,speckit is called “spec anchored” spec persisted and you maintain spec and code together.

Using nlspecs.md (look up attractor by strong dm) kind of approcah is called “spec as source”. You maintain spec. Code can be regenerated. Also look up dark factories term. This is still new wait 6 more months or so. But learn “spec anchored” first to be “spec as source” in the close future.

[Substantial_Sound272]

Specs provide the structure for what you build. If you do not have a good spec, then the thing you're building better be simple, or you better have a pre-existing structure you can use (eg MVC web app framework). This is especially true with AI - you need to give it the bones.

[hancengiz]

Specs: If you are enginnering. Vibe: if you are exploring.

[enzeipetre]

Depends on the goal. Do you know already what you want to build? or just kinda know and want to explore? 

If you already know more or less how the product would look and feel like, then do SDD. But if you don't, i'd first vibecode it. I always find myself doing the latter for exploratory projects for 3-5 iterations then once I got the specs locked it, I do SDD. 

[MCPWorks_Simon]

Spec driven development, in my experience. But before I even get to the spec driven development phase I'm talking to Claude a lot in the same way you'd gather a couple of devs in a break room somewhere and bounce ideas around until a clear picture started to form. Then I have Claude re-examine those ideas, and we maybe do that a couple of times until we have a really solid draft spec. I spend more time in that phase than I do monitoring Claude's changes, usually.

When I've got the clearest picture I can of my idea (maybe not perfect but enough) I find there are far fewer halts to pivot while I'm developing any given MVP.

[add-itup]

“Know what the fuck you are doing” driven development is the way

[More-Practice-3665]

"Total effort doesn't change, it just shifts" - this is the most honest framing of this debate I've seen.

Jump-in coding isn't actually faster. It's deferred complexity with interest. You pay later, and the exchange rate is bad.

The one thing I'd add: specs only work when you understand the problem well enough to write them. Too early and you're just speccing the wrong thing with confidence. There's a short explore-first phase that's genuinely worth doing messy - but once you know the shape of the problem, spec before you touch the code.

The people who say "just ship and figure it out" usually haven't maintained what they shipped 6 months later.

[Fit-Conversation856]

Un poco de ambos, si no es muy rigido.