Comment by hleichsenring
1 day 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 :-)
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.
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.
[flagged]
[flagged]
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.
[flagged]