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!

yes! sudocode manages agents at different levels of abstraction. You can steer agents at the `spec` level by building up a spec that contains your intent and requirements, then generate `issues` that capture the implementation details. However you aren't limited to that pattern. You can also just manage agents at the `issue` level to better manage their execution state (think something like a kanban board).

In general, sudocode aims to preserve some of this implementation/planning state (context-as-code) in your codebase so it isn't lost in your chat logs. Keeping this context in your repo makes it accessible to coding agents long after code changes were made, so it functions as a sort of episodic memory for your codebase.