I have not seen spec first development work well in real world environments at all. The problem is that you typically don't know what you don't know upfront for most product based decisions. Going back and forth in the spec to fix problems is a huge mistake, it just leads to contradictory sets of requirements for the agent.
What does work well is using AI to generate a quick and dirty prototype ala vibecoding, and then using that as a basis to regenerate the final code. Some might say it's still spec driven development, but the spec is a working prototype.
they do work well in production. have a look at https://github.com/holgerleichsenring/agent-smith. While writing that the methodology had been created. Obviously, I didnt know upfront what I wanted to generate here. Also features are changed or removed on the way. that's not a problem, when the specifications are part of the git repository as it is done here. Actually it's the other way around: it is an advantage as the agent can have a look at everything that had been done previously and can understand what, why and how it had been implemented. give it a try :-)
the agent creates and maintains the specs, doing this manually doesn't make sense. The specs are written for the agents. after execution of create-spec, review-spec skill will check against the code and add evidence of the spec's aims. Only when the aims fits to the evidence, the specs is going to be validated successful. after that apply and deliver skills can be executed. finally there is commit hooks and tests that shall ensure quality and functionality. have a look at https://github.com/holgerleichsenring/agent-smith for the quality gates.
I have not seen spec first development work well in real world environments at all. The problem is that you typically don't know what you don't know upfront for most product based decisions. Going back and forth in the spec to fix problems is a huge mistake, it just leads to contradictory sets of requirements for the agent.
What does work well is using AI to generate a quick and dirty prototype ala vibecoding, and then using that as a basis to regenerate the final code. Some might say it's still spec driven development, but the spec is a working prototype.
they do work well in production. have a look at https://github.com/holgerleichsenring/agent-smith. While writing that the methodology had been created. Obviously, I didnt know upfront what I wanted to generate here. Also features are changed or removed on the way. that's not a problem, when the specifications are part of the git repository as it is done here. Actually it's the other way around: it is an advantage as the agent can have a look at everything that had been done previously and can understand what, why and how it had been implemented. give it a try :-)
If your specs are not executable or are editable by the agent, they are as non-deterministic as any code that comes out of them.
the agent creates and maintains the specs, doing this manually doesn't make sense. The specs are written for the agents. after execution of create-spec, review-spec skill will check against the code and add evidence of the spec's aims. Only when the aims fits to the evidence, the specs is going to be validated successful. after that apply and deliver skills can be executed. finally there is commit hooks and tests that shall ensure quality and functionality. have a look at https://github.com/holgerleichsenring/agent-smith for the quality gates.