alexsngai
Joined 3 years ago
Joined 3 years ago
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.
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!