It is not pseudocode? It doesn't have to be something with strict syntax or very limited keywords, but maybe the compiler/linter (llm) could point out when you are being ambiguous or not defining how something should be done if several alternatives are possible.

Isn't that what Geoff did: https://ghuntley.com/cursed/

OK, it wasn't a Claude Skill, but it was done using Claude.

That's slightly different - that's draining and implementing a new language from scratch, not just using LLMs to help onboard new language users.

That said, part of what he did with Cursed was get LLMs to read its own documentation and use that to test and demonstrate the language.

> Most programming languages are similar enough to existing languages that you only need to know a small number of details to use them: what's the core syntax for variables, loops, conditionals and functions? How does memory management work? What's the concurrency model?

I think that’s correct in terms of the surface-level details but less true for the more abstract concepts.

If you’ve tried any of the popular AI builders that use Supabase/PostgREST as a backend, for instance Lovable, you’ll see that they are constantly failing because of how unusual PostgREST is. I’m sure these platforms have “AI cheat sheets” to try to solve this, but you still see constant problems with things like RLS, for instance.

When LLMs write and maintain code, does the programming language they use even matter? Anyway, the inputs to LLMs are all in natural language, and what we get is what we wanted built.

Is it better to specify the parameters and metrics —aka non-functional requirements —that matter for the application, and let LLMs decide? For that matter, why even provide that? Aren't the non-functional requirements generally understood?

It is the specifics that would change—scale to 100K monthly users, keep infrastructure costs below $800K, or integrate with existing Stripe APIs.