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.
> 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 get the LLM to audit the code to compare against the spec. Any divergence means one of two things:
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?
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.
Agreed. Having used OpenSpec extensively for a few months now, long-lived specs in the repo are useless, but the OpenSpec change process is super valuable for keeping agents on track across a single complex project (e.g. developing a single complex new feature in a large codebase).
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.
Are you maintaining a single long lived spec for an entire repo/project and trying to have AI implement against that, or are you creating a spec for each feature addition or piece of work you want to AI to do? What you say I hear commonly from folks who are trying to maintain a single spec for a repo and finding it falls over as that spec gets complex and what’s being asked of the AI is muddied by you asking it to figure out the diff between what was already in the spec/previously implemented and what it’s being asked to do.
The author doesn't distinguish whether these projects failed because of technology and execution, or failed because product market-fit. They simply blame AI being involved.
AI will only help if you use rapid iteration to cheaply/quickly produce ideas. All the normal project failure modes still exist.. Blaming AI because AI is dumb.
I only read up to point 3 because the hyperbole and frothing fervour was overwhelming.
- Most open source projects on the Internet are on Github. One could argue Github itself has taken a significant role in the growth of OSS in the last decade
- Using Discord is totally du jour for open source communities in 2025
- Reddit is still the biggest discussion forum on the Internet. Including discussion about open source
The normal, uninitiated folk don’t know any better about their choices of technology & what that means for our private data & autonomy. We have seen this song & dance of getting locked into shitty platforms like Slack, but projects are repeating history when they know better. Why not just tell folks to use Google & Apple Photos or Facebook? If you can see the advantage of your FOSS project & how it protects users, the same should apply to your own tech choices. If you want to maintain broad appeal for some reason instead of actually introducing them to other FOSS tech that would also be good for user, it might be a bit hypocritical tho understandable to have these channels open, maybe even official—but to make these the only option? Not a gateway/bridge? No mirrors? No email to send patches? Not cool.
When I quit my job and had to get my own laptop I bought a Chromebook. If your usecase is Terminal + Browser they're really very good.
I don't like that I'm supporting the Browser monopoly, but the battery life is supreme++(ARM versions at least), the Linux integration is great, I can run Android apps too(rarely though).
PWA's are integrated really well into ChromeOS so you won't be running one Electron instance per webapp. (My PWA's are Kagi Assistant, WhatsApp, SchildiChat(Element), Discord)
The same idea applies to self-driving cars though, no? That is an industry where the "AI revolution" will enrich only the existing incumbents, and there is a huge bar to entry.
Self-driving cars are not going to create generational wealth through invention like microprocessors did.
If it can produce something you can read in 20 minutes, it means there was a lot of... 'fluff' isn't quite the right word, but material that could be removed without losing meaning.
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.
reply