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.

▲

SOLAR_FIELDS 7 hours ago | parent [-]

Why would it be? If you can describe an approximation of a system and regenerate it to be, let’s say, 98% accurate in 1% of the time that it would take to generate it by hand (and that’s being generous, it’s probably more like 0.1% in today’s day and age and that decimal is only moving left) aren’t there a giant set of use cases where the approximation of the system is totally fine? People will always bring up “but what about planes and cars and medicine and critical life or death systems”. Yeah sure, but a vast majority of the systems an end user interacts with every day do not have that level of risk tolerance

▲

kamaal 4 hours ago | parent [-]

You are just validating the point that code is spec.

For your proposed system to work one must have a deterministic way of sending said spec to a system(Compiler?) and getting the same output everytime.

Input/Output is just one thing, software does a lot of 'side effect' kind of work, and has security implications. You don't leave such things to luck. Things either work or don't.

	▲	SOLAR_FIELDS 3 hours ago \| parent [-]
		Absolutely let’s not do away with the determinism entirely. But we can decouple generation of the code from its deterministic behavior. If you are adequately able to identify the boundaries of the system and run deterministic tests to validate those boundaries that should be sufficient enough. It’s not like human written code was often treated with even that much scrutiny in the before times. I would validate human written code in the exact same way.