"easy not complex" I'm not completely convinced by this point : it's hard to stay simple ! Maybe I'm just nitpicking between simple vs easy, but words especially in such a context (language and specs expression) are important !
OpenSpec – A lightweight and configurable AI spec framework
91–98 of 98 posts
Re: OpenSpec – A lightweight and configurable AI spec framework
#92Can 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.
I think modeling languages for code gen fall short because they aren't expressive enough and basically have to become programming languages and their users, programmers. This is the line of thinking that leads to "the specs are the code" conclusion.
I believe writing specs is different with AI for a few reasons: (1) natural language is expressive enough and the team collaborates at this level already, (2) LLMs can fill in the gaps, point out inconsistencies, and reliably map natlang to code, and (3) LLMs can read and refine specs at superhuman speeds, which makes spec maintenance economically viable for the first time ever outside of high stakes applications.
For this to work over the long run, specs must take a certain form. IMO: they must focus on original intent and what must be true after implementation (assertions) rather than implementation details. I also don't think one needs to specify anything an LLM can easily infer, so specs should be kept lean.
For spec drift, my team uses a sandboxed agent that checks for drift daily, triages, and surfaces issues. Beyond fixing specs, this has revealed a lot of product level miscommunications and helps us get ahead of them.
Re: OpenSpec – A lightweight and configurable AI spec framework
#93Can 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.
I think modeling languages for code gen fall short because they aren't expressive enough and basically have to become programming languages and their users, programmers. This is the line of thinking that leads to "the specs are the code" conclusion. I believe writing specs is different with AI for a few reasons: (1) natural language is expressive enough and the team collaborates at this level already, (2) LLMs can fi…
I agree with you, and am all in on a solution. It has to be part of the language itself: https://hale-lang.org/docs/claims/
Re: OpenSpec – A lightweight and configurable AI spec framework
#94This 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).
Please don't take this as offense, I'm honestly curious as I'm pretty bad at these things. 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...
the workflows are still so scpecific to the individual that they all feel like a short blanket at some point, i have my own "framework" that i'm perfecting for my use case
Re: OpenSpec – A lightweight and configurable AI spec framework
#95Interesting project. How does it compare to GSD (opengsd.net)? Just from the command set it seems a lot lighter but also less expressive.
GSD is quite OK but very token hungry (~4x but it buys traceability and has quite a powerful autonomous mode) I use gsd-meta-manager to manage multiple GSD projects in parallel without having to use a skill to query each project individually to see where they're at. Does openspec have something like that too?
Re: OpenSpec – A lightweight and configurable AI spec framework
#96Earlier quoted context omitted.
Please don't take this as offense, I'm honestly curious as I'm pretty bad at these things. 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...
the workflows are still so scpecific to the individual that they all feel like a short blanket at some point, i have my own "framework" that i'm perfecting for my use case
I have the same feeling when I come across a new one. It's easy to throw something together that's good enough. That's why I open sourced spekk. I don't think there's a product here, just a way of thinking and doing I want to share.
FWIW, there are about ten people using Spekk at my agency daily. The standardization across people and projects is helpful to us. It's built for teams like us, not just me. There are definitely some features that took us a few weeks to months to get right, even AI assisted, and I think that has value whether you use our tool or ask your AI to copy parts of it.
We're a small team though, so your point still stands.
Re: OpenSpec – A lightweight and configurable AI spec framework
#97I'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. Basica…
> Basically the old theory is true - the code IS the specification. The spec is whatever I write by hand. The code is what the LLM writes for me. The spec could be anything depending on how much detail you want. The problem with the "code IS the spec" in the age of LLMs is that they will change stuff without telling you while hitting their immediate goal. Six months ago, I used to review every single change. Now I ge…
I can appreciate your approach, but I'm not hand writing 100s to 1000s of specs by hand - at that point I'll just write the code myself
Re: OpenSpec – A lightweight and configurable AI spec framework
#98I'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. Basica…
The code is only part of the specification. It does rarely document the actual requirements to a degree you can rely on for decision making. Sure, the code should speak for itself, but it mostly speaks about the WHYs of the implementation, not the reasoning behind the actual requirement. I found that OpenSpec actually helps a lot in this regard.
I challenge you to use a frontier LLM to analyse your code and specs and verify if they are meaningfully aligned.
Code almost never speaks to the WHY; ADRs will help there.
Code never captures requirements, but it does reflect actual system behaviour, which is a specification.