Hacker News
points by woeirua 2 days ago | 0 comments
I have not seen spec first development work well in real world environments at all. The problem is that you typically don't know what you don't know upfront for most product based decisions. Going back and forth in the spec to fix problems is a huge mistake, it just leads to contradictory sets of requirements for the agent.

What does work well is using AI to generate a quick and dirty prototype ala vibecoding, and then using that as a basis to regenerate the final code. Some might say it's still spec driven development, but the spec is a working prototype.

[–] _ak21 1 day ago
in my opinion, high-level planning is the important thing. not going too deep into planning, but more about having a plan as a red line that helps you not to drift away from the initial goal. in my point of view is that the risk when you start with a vibe-coded prototype, which is a great starting point and something I also like to use. But a few weeks later, you get to the point where the initial goal starts to drift, and you constantly have to steer things back to stay on track. That’s one of the critical pain points in my opinion.
[–] hleichsenring 2 days ago
they do work well in production. have a look at https://github.com/holgerleichsenring/agent-smith. While writing that the methodology had been created. Obviously, I didnt know upfront what I wanted to generate here. Also features are changed or removed on the way. that's not a problem, when the specifications are part of the git repository as it is done here. Actually it's the other way around: it is an advantage as the agent can have a look at everything that had been done previously and can understand what, why and how it had been implemented. give it a try :-)
[–] threecheese 2 days ago
Specs-as-history is rapidly becoming an antipattern as teams actually try to scale SDD. We're already putting guardrails in agents.md (non-normative in all caps), some teams are actually offboarding them - to Rally (which I find the height of hilarity).

Spec docs - at least in all the other things like this thing - aren't a living representation of truth, instead they are a collection of snapshots in time of feature deliverables. Layer 500 of these on top of each other and they quickly become not just useless but actively harmful. Archive them, compile them, whatever your plugin does, it still doesn't help. Nobody is going to pay for tokens just to keep the specs time-coherent, when the agent can just read the code.

Don't get me wrong, a spec is a useful bit of kit for development, just like Jira and Rally, but also like Jira and Rally they aren't the source of truth because there's already a better one which you just paid for.

[–] evulhotdog 2 days ago
I think this is where updating and maintaining the specs is just as important, if not more than adding new ones.

Maybe your flows coins take advantage of ensuring that the specs define the intent and active decisions made and not just “what the code does”, which it can actively read from the code itself.

[–] drdexebtjl 2 days ago
Your silly software factory is not proof that SDD works well in production. It is proof that it can produce software, and that’s a very low bar.

We’ve been using SDD at $workplace for more than a year and we’ve started to actively remove all spec documents so agents don’t get stuck reviewing out of date context for 20 minutes, burn through token budgets, and give disproportionate focus to legacy patterns and business directions we’ve pivoted from.

Models are RLHF’d to work on non-historical documentation and iterative design, and that’s what yields the best overall results.