Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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...
- I have been doing some greenfield work as a solo founder in a fully agentic workflow for a while now, and I mostly find these “frameworks” don’t work for me.
I am not yet convinced this space has been claimed in a way like say how “React” became the framework of choice in frontend development.
These initiatives all seem to tackle a “nice to have” or “quality of life” impact in the workflows in my opinion. Haven’t yet seen a proposal that addresses the larger problems, which, I think are even hard to quantify and explain still.
AI is great as a writing aid, still bad as a reading aid. To me the bottleneck remains the human and how can you help the human make better and more informed steering decisions backed by data driven and verifiable proofs against your system.
The organizing aspect of information feels like a step towards the bigger picture but not that much of a leap yet.
by hmokiguess - 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 - if you have a structure around starting with something like an ADR, common patterns for the whole repo etc., it's super hard to keep track of and actually keep it up to date. You make a strong early decision in an ADR and realize that you have to change it later on, or diverge. These changes get rarely properly recorded.
2. Review loop - Same model review isn't enough, I want bunch of models bouncing off each other, whilst still using my subscription and not API.
3. Feature creep and deferral tracking - it happens a lot that you encounter either during review or one of the validation phases that you also need to implement x, which is not covered by the original spec. There are several options to handle that, with the key that all those decisions need to be tracked and at some point decided by a human.
4. Custom workflow with governance - I have my own preferred SDLC if you can call it that, which includes rounds of agentic review of spec, before manual approval gate, review loop with certain specification depending on the codebase, feature size, deferral rules.
5. Ceremony based on context - Because it would happen that some of the ceremony would get in the way at some points (like producing a 100+ loc spec for 10loc change) I ended up basically developing a flow to decide whether a feature actually needs the full ceremony (full lane) or we can simply use the native plan feature (fast lane), so that I don't have to go through the whole ordeal of steps, when I need a tiny change.
I forked this code and added bits that matched my flow and it works out pretty well https://github.com/nutthouse/tutti
- 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.by sheepscreek
- 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).
by wyum - 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.
by twen_ty - The documentation is entirely about how to use it, how to manage the skills and configure it.
What I'd like to see is what it is, how and why it works, ideally backed by some benchmarks. Otherwise it looks like just another pile of skills with unknown outcomes.
by ricardobeat - I've used OpenSpec extensively on two large pieces of software which were worked solo over 6-9 months.
Recently, I've completely ditched the specification part. I found they just weren't useful over the longer term. I used an LLM to assess in both directions whether the code matched the specs and whether the specs matched the code. On both software projects this came out with huge divergence from spec to code.
Basically the old theory is true - the code IS the specification.
What I did find very useful and have retained is the process flow. Create a proposal, review the proposal, implement, review the code. Also useful was building and maintaining ADRs and invariant logs for where a unit test cannot be made to verify behaviour. The process and the ADRs, unit test, invariant log all help the software stay coherent as the LLM churns on it over many unconnected contexts.
by mafro