[flagged]
OpenSpec – A lightweight and configurable AI spec framework
81–90 of 94 posts
Re: OpenSpec – A lightweight and configurable AI spec framework
#82Can 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.
that's a good question. UML - at least the mainstream version pushed by e.g. Rational - failed for many reasons. A couple pertinent to this discussion: 1. Lack of closed loop between the "spec" and working code (your spec rot point). The Rational Unified Process(RUP) was a grossly inefficient, heavily manual undertaking. Mapping between artefacts - e.g. "Platform Independent Models" and "Platform Specific Models" was…
This is what I've been mulling over for months. Surely there's a better, more rigorous specification format than Markdown prose that already exists in the industry and is useful to the agents. Formal Use Cases perhaps? Probably not Gherkin but maybe some other spec DSL.
Re: OpenSpec – A lightweight and configurable AI spec framework
#83I'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 don't think your dichotomy works. When an LLM is reaching into agents.md it is absolutely modifying the specs. Who cares about original providence when it ends up in agents.md?
Re: OpenSpec – A lightweight and configurable AI spec framework
#84Been using it for a bit. I think its a matter of time until we dont look at code anymore and only look at specs, plans, design docs. I didnt like the doc organization (or lack of it) using a standard reader or editor, so I built one specifically for OpenSpec. Hope you find it useful https://specks.nicotejera.com
Strongly disagree. I used to think the same thing, but I've slowly come to realize that we won't be looking at specs, we'll be asking an LLM to produce the specs in real time by reading code. Anything that causes drift from the code is a liability and a maintenance burden. Besides, what good are specs if they aren't reflective of reality? Do you know what is reflective of reality, though? The code.
In my experience, if I write good, thorough specs, the code adheres to them. And if something's off, I don't go and modify the code, this is when specs and code start to drift. The whole point about OpenSpec is that you create a new change, with a new spec, and then the LLM modifies the code accordingly. If you follow a process, I believe there's less risk of drift. But to each their own, you can obviously choose to own and author the code and have AI write the specs. For me, its more productive to write good specs, as I can write them faster and more people, sometimes not technical, can weigh in.
Re: OpenSpec – A lightweight and configurable AI spec framework
#85Can 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.
Why would you have a spec drift? My team has an AI review that matches the existing specs against the current implementation. This is very useful and keeps both in sync. If there are any conflicts they are noted in the pull request review and can be fixed. This works very nicely.
Re: OpenSpec – A lightweight and configurable AI spec framework
#86What I prefer is to be able to iterate and iterate on my spec, then implement once. That’s what I’ve come to as a process with CC, and I’ve gotten really good results. Whenever I spend less than 20-30 minutes actively discussing the spec with the agent, the quality of implementation rapidly drops, even with some tiny things.
I like the overall idea of this, but the writing of the spec to me is more like building the thing than the implementation itself, and needs more active human (and agent) cycles.
Re: OpenSpec – A lightweight and configurable AI spec framework
#87What are people using for this nowadays? There seems to be a spectrum from fluid, iterative workflows like OpenSpec to more up-front alignment and control like Matt Pocock skills. Curious what people have settled on.
I settled on lat.md [1] at the beginning of this year and never looked back. Its design offers a compellingly simple surface for weaving natural-language intent into the codebase itself, without overcomplicating things: --- Key Ideas * Plain markdown: readable by humans, parseable by agents * Wiki links connect concepts into a navigable graph * // @lat: and # @lat: comments tie source code to specs * lat check ensure…
Hi, your comment motivated me to try it out on my project. I'm looking for some advice.
I had a 2000 line specification, but no code yet. Based on lat.md, I have split the specification into 25 different files in the lat.md folder (not sure if that's too many).
My next task is to create a staged implementation plan, but I'm not sure how lat.md can help me (or is it even designed to?). Should the implementation plan stages also be separate markdown files in the lat.md folder? Or a sub folder? (Does it matter).
My understanding is that lat will help create a knowledge graph between the specification files the implementation files, and the code.
Re: OpenSpec – A lightweight and configurable AI spec framework
#88I'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 reason the code is the specification is because people don't take specification seriously. Usually for good reason, but sometimes not. Real, long-lived RFC's can exist, and can have directional and corrective impacts on your LLM generated code. The trick is the RFC needs to be human written and maintained. The moment the org allows the LLM themselves to modify the spec... then yes the spec is no longer useful; or rather, "why" comments in code + a sliver of high level directional / summary content is probably all that is valuable.
A fun example can be having the LLM implement a well known spec (which it cannot edit), and then to use the spec in review to find mistakes and corrections. That's helped it really click for me. All these tools that let LLMs generate spec, even with iterative planning... I haven't found it useful for very long. It's great for building something complex in the very short term (e.g. days). But i haven't found keeping them afterwards to provide any benefit.
Re: OpenSpec – A lightweight and configurable AI spec framework
#89This 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...
No offense taken. I'd also say I overthink things, so this question hits home.
The existence of similar tools has certainly given me pause several times. I was aware of SpecKit (GitHub) and Kiro (Amazon) when I started in January of this year. I Googled around and asked AI to find and evaluate similar things to my idea. Somehow I genuinely missed openspec, which seems to have had 20k GitHub stars at that time. I look at this and realize how bad I've been about sharing and promoting spekk.
I've continued to iterate on my idea because nobody else is as focused on the concept of declarative, living specifications that evolve with the code. From the beginning that has been Spekk's differentiator.
I've definitely had doubts about whether building my own version is "worth it."
Some wisdom I've gained as I get older is that the world is a complex place. There are many valid ways to solve the same problem, and every version has its audience and community.
The other thing is that even in this age of AI, putting sustained effort into a thing is still a scarce resource. The best software still takes time to mature and refine. It never ceases to amaze me how many small but important decisions and features go into what many see as "just markdown files and skills."
Appreciate the question.
Re: OpenSpec – A lightweight and configurable AI spec framework
#90I 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.