More specifically regarding spec-driven development:
There's a good reason that most successful examples of those tools like openspec are to-do apps etc. As soon as the project grows to 'relevant' size of complexity, maintaining specs is just as hard as whatever other methodology offers. Also from my brief attempts - similar to human based coding, we actually do quite well with incomplete specs. So do agents, but they'll shrug at all the implicit things much more than humans do. So you'll see more flip-flopped things you did not specify, and if you nail everything down hard, the specs get unwieldy - large and overly detailed.
> if you nail everything down hard, the specs get unwieldy - large and overly detailed
That's a rather short-sighted way of putting it. There's no way that the spec is anywhere as unwieldly as the actual code, and the more details, the better. If it gets too large, work on splitting a self-contained subset of it to a separate document.
> There's no way that the spec is anywhere as unwieldly as the actual code, and the more details, the better.
I disagree - the spec is more unwieldy, simply by the fact of using ambiguous language without even the benefit of a type checker or compiler to verify that the language has no ambiguities.
People are keen to forget that programming languages are specs. And a good technique for coding is to build up you own set of symbols (variables, struct, and functions) so that the spec become easier to write and edit. Writing spec with natural language is playing russian roulette with the goals of the system, using AI as the gun.