It seems like such a strange thing to do, building a language that you aren't going to write by hand. It's guaranteed to perform worse at higher cost, fill up a lot more of the context window, and burn a ton more reasoning tokens.
If you're using AI, a language with a large training set is going to win.
I guess it depends on whether you will write everything in an AI assisted fashion or not. There's benefits to languages that are quick and easy to read by the author even if the LLM is doing the writing, because most code still benefits from human review above and beyond the review that agents provide. Language popularity certainly helps but it seems like for moderately popular languages [1] the cost you pay for a lack of popularity is quite modest.
I don't think those assertions about AI development necessarily hold. And I think it'd be a depressing future if we can't ever have anything new or better that wasn't popular in the training set as of November 2025.
I wrote about some of my thoughts with Zena and AI here: https://zena-lang.dev/blog/2026/09/languages-for-the-ai-era/
This assumes the goal is to create a productive language.
When I design my own languages (I have written several, all terrible!) it's typically to learn about language design.
> If you're using AI, a language with a large training set is going to win
Not necessarily? What if the training set contains an overwhelming amount if bad code written by neophytes? I imagine Python quality by the LLM suffers from this, for example.
What if the language has extremely confusing syntax constructs (like early php) or bad or no conventions (suppose the standard library has somecollection.put(key, value) sometimes and othercollection.put(value, key) other times), and individual code authors just pick what they want adhoc
Large training set ain't gonna save you.