Ask HN: Does spec-driven development still pay off with frontier coding models?

I'd argue that you 100% need a spec --ideally tied to some high-level unit tests-- and should have a plan, but I don't think there's any strict need to write any of those three by hand; the critical step is where you review it and request changes if needed.

Doing it all manually better guarantees quality of course, so makes sense for a lot of problems. But if you're looking to move a bit faster with a bit more risk, I'd sacrifice the writing step without sacrificing the reading & validating step.

I tend to agree with bbor. I use the agent to build the spec, usually from unfiltered audio to text data dump. The spec also allows you to manage context by pre-defining scope. I would argue managing context is more important than a spec at a certain quality level of the spec. A high-quality spec should inherently help manage context. If you are leaning into full end to end automation, there is no substitute. I'm not sure "better" is the lens. A more capable model also has more paths of interpretation that it can conceivably take based on the framing of your rough goal.

We still write one, but it got a lot shorter as the models improved. The big up-front PRD stopped paying off.

Frontier models are great at filling gaps, and that's the problem, they decide on your behalf.

The plan mostly exists to close those decision gaps. It also helps review: teammates can push back on a 30-line plan in five minutes, but a 2k-line diff takes an afternoon.

Not the full PRDs like before.

Astra, Fable, Opus 5.0 are better with less instructions. Some of the context has been moved into the harness itself, so things like CLAUDE.md etc are becoming obsolete, and same with PRDs.

These days it's more about saying why than what. ADRs and GDDs would be helpful.