61–70 of 71 posts
It's interesting to see the divergence of opinions on these frameworks and also at least anecdotally how many people roll their own custom implementations of workflow management on top of their favourite SDD framework. I also ended up doing my own thing mainly to address several omissions in the existing frameworks (for SDD I prefer to use Superpowers and/or Matt Pocock's skills): 1. Artifact staleness and tracking -…
Earlier quoted context omitted.
> been trained on enough long context tasks to have become pretty good at planning This is absolutely not true
Well, they are absolutely pretty good at faking being good at long-horizon planning which is enough to fool a lot of people till things start breaking lol.
In my experience, spec drift is the main reason why none of these tools work. Maybe they work for one shot greenfield feature generation but in a large, multi developer long lived code bases, specs rot and end up being more pain than they are worth.
Can someone tell me how this stuff is any different from the 90's let's use UML for code gen and how it's not going to fail in the same way? In my experience, spec drift is the main reason why none of these tools work. Maybe they work for one shot greenfield feature generation but in a large, multi developer long lived code bases, specs rot and end up being more pain than they are worth.
Can someone tell me how this stuff is any different from the 90's let's use UML for code gen and how it's not going to fail in the same way? In my experience, spec drift is the main reason why none of these tools work. Maybe they work for one shot greenfield feature generation but in a large, multi developer long lived code bases, specs rot and end up being more pain than they are worth.
Haven’t we moved on from these things? Most recent LLMs have been trained on enough long context tasks to have become pretty good at planning. Perhaps with contributions from the harness. In either case, I wouldn’t bother if I were using Codex or Claude Code.
I mostly use speckit, not openspec. I think basically these are the same tools. There are other reasons for using such tools, but one reason is to enforce discipline for me and the LLM. Otherwise, often it starts going round in circles. Helps me save tokens as well. Again, the discipline is the important bit (along with clearly produced artefacts). Can I do all of this just with the LLM? Yes and that's what I did but…
This is my first time seeing openspec, and it seems to share a similar philosophy to what I've been working on this year. If you like this / SDD, I'd appreciate your feedback: https://github.com/spekk-ai/spekk-cli Similar iterative specs philosophy. Ours is a bit different because we focus on declarative specs and installable agent skills. We chose Go for simplicity and minimal requirements (single binary).
You say this is your first time seeing openspec, but you've been working on a pretty similar project for a year now. Openspec and Speckit both seem to have similar (almost same?) goal as yours. Do you just jump into such a project as yours without worrying about others already existing?
I tend to overthink such stuff...
And my issue is always, how do I review so many files. Is the purpose just to go from 1 requirement prompt to so many spec files? How do I know the specs actually reflect the requirement?
I always feel I come away from projects like this even more confused.
This section https://openspec.dev/docs/setup links to "Concepts" Concepts links here: https://github.com/Fission-AI/OpenSpec/blob/main/docs-lab/gu... All the docs here are the templates rather than the actual file (I presume: https://github.com/Fission-AI/OpenSpec/blob/main/docs/concep... ) Somehow not very confidence inspiring...
Hey, maintainer here, the other reply got it right. We recently re-wrote the entire docs from scratch and we added some placeholders for other pieces of documentation we wanted to fill in, but it seems like some of the placeholder links stayed. Will update this!