>"This doesn't deal with the design of code and the long term effects of choosing the wrong API."

Yes it does. With this approach, any change to the design requires a change to the specs to be made first. I already indicated the specs could evolve over time to allow for refactoring and new features.

>"It also doesn't handle new features, at all, because the tests have not been written. Even if you enforced a requirement for tests with coverage, the tests could (and usually would) still be wrong.

Trying to take conscious, adaptive, intelligent response out of the loop is a mistake."

You've misunderstood, as I stated before, discussions still happen, they're just focused on the specs.

I agree with Ajedi32 on this. Sufficiently detailed specs will be indistinguishable from code. So reviewing code and its behavior is more efficient than having another language to review.

It may depend on the domain, however. I find that a lot of misunderstandings arise in these discussions because people assume the problems are the same in all kinds of computing. That's not so.

I work in viz/UI (interactive charting) so there aren't great libraries for testing or writing specs. All the features interact in unpredictable ways.

Your process may work better where the API is purely functional, where inputs and outputs and side effects are better defined.

I'm happy for you if you've applied this successfully!