Goodhart's Law of Specification: When a spec reaches a state where it's comprehensive and precise enough to generate code, it has fallen out of alignment with the original intent.

Of course there are some systems where correctness is vital, and for those I'd like a precise spec and proof of correctness. But I think there's a huge bulk of code where formal specification impedes what should be a process of learning and adapting.

My dream antiprogram is a specification compiler that interprets any natural language and compiles it to a strict specification. But on any possible ambiguity it gives an error.

    ?

This terse error was found to be necessary as to not overwhelm the user with pages and pages of decision trees enumerating the ambiguities.

Openspec does this. But instead of "?" it has a separate Open Questions section in the design document. In codex cli, if you first go in plan mode it will ask you open questions before it proceeds with the rest.

The UX is there, for small things it does work for me, but there is still something left for LLMs to truly capture major issues.

Bless our interesting times.

You know, this makes me wonder... is anybody actually prompting LLMs with pseudocode rather than an English specification? Could doing so result in code that that's more true to the original pseudocode?

You can give the macro-structure using stubs then ask the LLM to fill in the blanks.

The problem is that it doesn't work too well for the meso-structure.

Models tend to be quite good at the micro-structure because they've seen a lot of it already, and the macro-structure can easily be promoted, but the levels in between are what distinguishes a good vs bad model (or human!).

I’m not sure if it went anywhere but I remember there was this attempt at one point called Sudolang:

https://medium.com/javascript-scene/sudolang-a-powerful-pseu...