I think of specs as a combination of user intent + context that might be relevant for the issue. The expansion of the spec into a full-fledged document, whether thats agent-written or human-written can be flexible as long as it contains the original user intent and requirements (so it becomes useful input to any coding agents handling the implementation).

In this case, what sudocode aims to preserve is the human intent that might be lost in agent chat logs, etc. It then provides utilities to turn those specs into implementation plans (issues). And specs in this case are mutable and designed to be iterated on (just like code).

Or with a physics analogy, the code is the position of a particle while the specs capture velocity information. You can iteratively work on changing the velocity which will then change the position (code changes).

As for the spec review burden, the sudocode provides an interface for coding agents to provide bi-directional feedback onto the original spec, so you can fire off a few coding agents and see how they performed relative to your specified requirements. You can let the execution of the coding agents speak for themselves!