Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSpec – A lightweight and configurable AI spec framework

openspec.dev

Post reply on HN
Print view View original

21–30 of 74 posts

Re: OpenSpec – A lightweight and configurable AI spec framework

#21

Post by OutOfHere »

jmathai wrote: post #10

I have a super simple spec-based workflow. It works amazingly well. I’m amazed how well coding agents can work through what I consider large features. Last week, I gave a 471 line spec to implement a major feature and it didn’t flinch. I wrote about it here. https://jaisenmathai.com/articles/sojourn-for-ios-was-45-one...

I am sorry but 471 lines is nothing in 2026. Come back when it has executed a 5000-10,000 line spec flawlessly, although the threshold keeps getting higher as the models get better. You're right though about a simple spec based workflow going far.

Re: OpenSpec – A lightweight and configurable AI spec framework

#22

Post by wyre »

iamjfu wrote: post #11
wyre wrote: post #9

It's just a bundle of skills and md files... Why does it need to have an entire CLI?

The CLI is actually useful. It gives the skills a way to deterministically interact with the spec. For example, it can validate the shape without having to spend tokens reading the files.

Compared to including shell scripts with the skills?

Not trying to say that it's not useful, but it seems excessive and potentially bloated.

Re: OpenSpec – A lightweight and configurable AI spec framework

#23

Post by alexjplant »

sheepscreek wrote: post #15

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.

I bother because Claude Code does wacky nonsense unless I use OpenSpec (or something similar) to explicitly research, scope, persist, then implement in a brand-new context. Even Opus will do ridiculous nonsense like throw its hands up when asked to start a Docker container, ignore explicit architectural instructions, write verbose make-work documentation riddled with inaccuracies, etc. Using OpenSpec keeps things as constrained as possible with the side effect of recording what your system does.

OpenCode and various open models do not exhibit this tendency nearly as much in my experience. My recent experiences with GPT-5.6 were also very positive in this regard. Alas for regulatory reasons this stack is a non-starter at $DAYJOB so I'm stuck working around Anthropic's capacity optimizing shenanigans.

Re: OpenSpec – A lightweight and configurable AI spec framework

#24

Post by Wazzymandias »

sheepscreek wrote: post #15

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.

> been trained on enough long context tasks to have become pretty good at planning

This is absolutely not true

Re: OpenSpec – A lightweight and configurable AI spec framework

#27

Post by etoxin »

wyre wrote: post #22
iamjfu wrote: post #11

Earlier quoted context omitted.

The CLI is actually useful. It gives the skills a way to deterministically interact with the spec. For example, it can validate the shape without having to spend tokens reading the files.

Compared to including shell scripts with the skills? Not trying to say that it's not useful, but it seems excessive and potentially bloated.

I use the cli tool outside of the agent session. e.g. `openspec view` to see all the specs and what's pending.

Re: OpenSpec – A lightweight and configurable AI spec framework

#30

Post by kaurimu »

8cvor6j844qw_d6 wrote: post #12

What 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 ensures nothing drifts out of sync

* lat search for semantic vector search across all sections

---

For me it strikes the right balance between structure and flexibility. It gives agents enough context-efficient grounding to reduce functional and architectural drift [2], while remaining malleable enough to evolve with new requirements.

Admittedly I haven't run any evals, and I'm sure there are even better systems out there... but if I still had the problem I was trying to solve when I found it, I wouldn't be talking about it right now.

Of course it's likely that my problem has only migrated to a higher order of complexity, but surfacing it again through building increasingly complex things is an interesting enough challenge in itself.

[1] https://github.com/vercel-labs/lat.md

[2] 100% auto-eliminating drift is an unrealistic goal -- that's where you come in.

Post reply on HN