the initial idea was a general-purpose language, but obviously the scope for that would be too big. I think that having "natural language frameworks" for some application types can work: REST APIs, CLI apps, React components... . If you have a set architecture, like the Elm architecture, centered around events being fired that update some state, that could lead to some standards. One feature that I intend to add is having an "interview" with the AI. You write the spec, then it reads it and gives you some questions/issues, like: "this point is too vague", "what do you want to update here? a or b?". That would help ensure that the prompt/spec itself is improvable with AI.

People say that a microservice is something that "fits in your head". Once the logic gets too complex, you should separate it into another service. Maybe in the future the phrase will be "what fits in the AI's context". That would be a good litmus test: if a piece of software is hard for an AI, maybe we should simplify it - because it is probably too hard for the average human as well.