alt Hacker NewsThis is also where I think we end up. If the behavior of the system is specified well enough, then the code itself is cheap and throwaway. Why have a static system that is brittle to external changes when you can just reconstruct the system on the fly?
Might be quite awhile before you can do this with large systems but we already see this on smaller contextual scales such as Claude Code itself
Replies
> If the behavior of the system is specified well enough
Then it becomes code: a precise symbolic representation of a process that can be unambiguously interpreted by a computer. If there is ambiguity, then that will be unsuitable for many systems.
>>If the behavior of the system is specified well enough, then the code itself is cheap and throwaway. Why have a static system that is brittle to external changes when you can just reconstruct the system on the fly?
You mean to say if the unit and functional tests cases are given the system must generate code for you? You might want to look at Prolog in that case.
>>Might be quite awhile before you can do this with large systems but we already see this on smaller contextual scales such as Claude Code itself
We have been able to do something like this reliably for like 50 years now.
The specification for most systems _is the code_. English cannot describe business rules as succinctly as code, and most business rules end up being implied from a spec rather than directly specified, at least in my experience.
The thought of converting an app back into a spec document or list of feature requests seems crazy to me.