[flagged]
OpenSpec – A lightweight and configurable AI spec framework
81–87 of 87 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.