I think Vera might be missing something here. In my experience, LLMs code better the less of a mental model you need, vs the more is in text on the page.

Go – very little hidden, everything in text on the page, LLMs are great. Java, similar. But writing Haskell, it's pretty bad, Erlang, not wonderful. You need much more of a mental model for those languages.

For Vera, not having names removes key information that the model would have, and replaces it with mental modelling of the stack of arguments.

https://arxiv.org/html/2510.11151v1

This reminds me of Dafny: https://dafny.org/

Actually, that's an interesting question: how good are LLMs at writing Dafny?

Yes, you’re adding this layer of verification, but LLMs don’t think in ASTs or use formal logic.

They are statistical predictors, just predicting what the next token will be.

There is a reason they perform best with TS/PY and not Haskell. The difference in size of the code corpus for each language.

The premise behind this seems to ignore all of that.

This has been tried so many times already. It works nice for functions that only do some arithmetic. But in any real life system that pushes data around over the network or to databases, most things will happen inside effects which leaves the compiler clueless as to whether the function implementation does what it's supposed to do or not.

Don't get me wrong, I'm a big fan of using the compiler to improve productivity and I also believe strong typing leverages LLM power. But this kind of function specification is a dead end IMO.

So then why is the first mentioned and most obvious difference from other languages

> There are no variable names. @Int.0 is the most recent Int binding

LLMs are trained on code written by humans. They are most “familiar” with popular programming languages, have large datasets of examples and idioms to draw on. I don’t see the advantage of inventing a new language the machine must “learn” with syntax unlike anything it’s been trained on.

Validation and testing are also already things we do with human written code, too.

1) Programming language training happens by volume, and the amount of JS/TS/python out there, and the rate it's growing at - is causing a training effects loop, which means for a few generations of models, these will be the best performing languages. Will be hard for a contender to spin up.

2) At some point, if we plateau on productivity - then efficiency improvements will happen, which will open a door for programming languages that maintains productivity, but is 10x cheaper on cost.

3) I think more immediate gains are at the cloud level. IMO, one of the reasons Google cloud is performing better(along with firebase) is much better overall CLI experience, leading to a pleasurable experience developing against it. This part of the market is ripe - whoever builds a most LLM friendly cloud has a shot of shooting up. Hence projects like exe.dev, and whatever cloudflare and vercel are trying. It would be good to have some shakeup in the cloud world.

Anyway, this is where my thoughts are currently.

Elaborate a little here.

The major design decision I'm a little skeptical about is removing variable names; it would be interesting to see empirical data on that as it seems a bit unintuitive. I would expect almost the opposite, that variable names give LLMs some useful local semantics.

The right granularity for agents isn't files or lines, it's entities: functions, classes, methods. That's how both humans and agents actually think about code.

We built sem(Ataraxy-Labs/sem) which extracts entities from 30+ languages via tree-sitter and builds a cross-file dependency graph, so building semantic version control and semantic diff. weave (same org) takes it further and does git merges at entity level. Matches functions by name, merges their bodies independently.

The dependency graph also answers questions LLMs can't. I love the analysis based on ASTs.

I do applaud the lang design effort as there are countless routes of accepting Jesus as your savior.

Is this a thing for the llms? As a human, I also prefer being told what went wrong and why and how to fix it, rather than `expected {`

Seemingly opposing forces.

I do, too!

You already lost me here. There's a reason variable names are a thing in programming, and that's to semantically convey meaning. This matters no matter whether a human is writing the code or a LLM.

It appears that me and creator have had vastly different experiences with LLMs and their capabilities with complex code bases and complicated business logic.

My observations point to LLMs being much more successful when variables and methods have explicit, detailed names, it's the best way to keep them on track and minimize the chance of confusion, next closest thing being explicit comments and inline documentation.

Poorly named and poorly documented things in a codebase only cause it to reason more on what it could be, often reaching a (wrong) conclusion, wasting tokens, wasting time.

Perhaps this diversion in philosophy is due to fundamental differences in how we view the tool at hand.

I do not trust the machine, as such I review it's output, and if the variables lacked names, that would be significantly harder. But if I had a "Jesus, take the wheel!" attitude, perhaps I'd care far less.

Nanolang: A tiny experimental language designed to be targeted by coding LLMs

https://news.ycombinator.com/item?id=46684958

https://github.com/jordanhubbard/nanolang

SudoLang: A Powerful Pseudocode Programming Language for LLMs:

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

Programming Without People: Designing a Language for LLMs:

(ALaS (AI Language Specification)):

https://dshills.medium.com/programming-without-people-design...

LMQL ("LMQL is a programming language for LLMs."):

https://lmql.ai/

Which language is best for AI code generation? The answer might surprise you:

https://revelry.co/insights/artificial-intelligence/which-la...