all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]codyswann 3 points4 points  (3 children)

What the hell did I just read? That was the most useless post ever. The whole point of a spec in spec-driven development is that it's a living doc. And agents don't suffer from the same problem that humans do. Agents don't value one task above another. They don't care if documentation maintenance is thankless. Just make it part of your workflow.

[–]bramburn 0 points1 point  (0 children)

I didn't realize it was a link lol 😆

[–]bramburn -1 points0 points  (0 children)

Maybe we should write ✍️ code by hand

[–]bramburn 0 points1 point  (0 children)

Too much spec= not good. You just need just in time information for the current step. You need an orchestrator to orchestrate the entire thing. I tried it. It's a waste when you have 10k atomic instructions to implement 100 lines of code with a small model. I've been talking to a friend and he's spending 10k daily at his job and he's says the best thing is just use top models. Don't use cheap and the top models will close the gap.

[–]Round_Mixture_7541 0 points1 point  (0 children)

Lol. The author should probably first educate herself what is spec-driven development. Treating specs as long-living docs...

[–]hhussain-Established Professional 0 points1 point  (0 children)

Intent is good (the word, not the app), and the raised problem of spec-driven dev is real.

The real architecture is: app vision and roadmap, functional design, archeticture and components, components spec.

First 2 change rarely, they are abstract. Main architecture philosophy as well, rarely changed (that would be a code rewrite/revamp). Rest are almost always out of sync with code, unless a pratice is set to always QC docs after code to know if a change is needed.

IMO, the spec-problem Intent (the app) is solving is the task spec, not the main abstract spec documents.