I think modeling languages for code gen fall short because they aren't expressive enough and basically have to become programming languages and their users, pro

I think modeling languages for code gen fall short because they aren't expressive enough and basically have to become programming languages and their users, programmers. This is the line of thinking that leads to "the specs are the code" conclusion. I believe writing specs is different with AI for a few reasons: (1) natural language is expressive enough and the team collaborates at this level already, (2) LLMs can fill in the gaps, point out inconsistencies, and reliably map natlang to code, and (3) LLMs can read and refine specs at superhuman speeds, which makes spec maintenance economically viable for the first time ever outside of high stakes applications. For this to work over the long run, specs must take a certain form. IMO: they must focus on original intent and what must be true after implementation (assertions) rather than implementation details. I also don't think one needs to specify anything an LLM can easily infer, so specs should be kept lean. For spec drift, my team uses a sandboxed agent that checks for drift daily, triages, and surfaces issues. Beyond fixing specs, this has revealed a lot of product level miscommunications and helps us get ahead of them.