Hacker News Reader

Comment by sheepscreek | Hacker News Reader

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.

View on HN

I mostly use speckit, not openspec. I think basically these are the same tools. There are other reasons for using such tools, but one reason is to enforce discipline for me and the LLM. Otherwise, often it starts going round in circles. Helps me save tokens as well. Again, the discipline is the important bit (along with clearly produced artefacts). Can I do all of this just with the LLM? Yes and that's what I did but it was very messy.

For teams its very helpful too, as you entire team standardizes around a common set of artifact for planning and executing work (with explicit semantics). Avoids snowflake agent sessions and artifacts for planning, proposing and executing work.

They can plan, but no guarantee it will produce what you want. Sometimes most of the work is aligning on what to build. And I'm not handing over technical planning to it yet.

I use this skill and it makes the specing process progressive. Human driven for the "what", 50/50 for higher level technical planning, only where it has questions in the low level details: https://github.com/scosman/vibe-crafting

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

This is absolutely not true

if anything in the latest batch, they have been trained to try everything and anything to get a task done, hence their hacking abilities, but also how they go way off the rails when they don't get sufficient context on our human intent for the task

feels less like planning and more like throwing spaghetti at the wall the moment ambiguity emerges, I really hope the next batch dials it back

Well, they are absolutely pretty good at faking being good at long-horizon planning which is enough to fool a lot of people till things start breaking lol.

At least for my personal projects, it's enough that they're better than me at long-horizon planning.

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.

That's what I thought too. I used speckit quite a bit before and I've had mixed results at best. You are just moving ambiguity and code review from one place to another without really gaining anything.

I just rely on a log of user messages, all messages the user typed in a project as raw data and do a pass with agents to synthesize intent. Then use this for planning and validation of code. I think the user messages are the most valuable data in a project for this reason. Doing this reflection pass on messages takes just a few minutes even for thousands of messages. It keeps global perspective which is often lost in local work.

Do you save the plans from plan mode alongside of the feature? I use specs to save the artifact but hadn't thought of using plan mode as the spec generator itself.

I agree but your taste in making solutions, or that of your organisation may be very different from what an LLM does by default. I personally use specs to capture this taste; an example shared by most LLMs is that they like to document not only what they have built but also what they have not built. Especially after changing solutions or small migrations. Specifications can resolve most if not all of that behaviour.

specifying is not planning

Reply on news.ycombinator.com