For LLMs, less code means fewer tokens, and tokens are what you pay for so you spend less on development.

I don't think that's strictly true.

What you need is for your LLM to be able to understand enough context to be able to make a change with as few token as possible, so if your code isn't expressive enough or if it has a tendrils calling lots of different functions/methods all over the place, then you'll have to give it much more code (context) than if you've got nice encapsulated modules that don't depend on other parts.

The design of your architecture (probably?) has a greater impact on token use in a large app than the language it's written in. Although, obviously, languages lend themselves to particular architectures so it's correlated.

I remember the old discussion between clojure programmers and someone who works in a strongly typed language. The argument was “types allow you to be certain that if you change some code, an unrelated but affected part of the codebase will also be flagged and it is not missed” the clojure guy response was “why would you ever design a program where a change in one place affects the other”.

I do think this is an unrelated win of functional languages that hasn’t yet been “discovered” by the vibe coder crowd - FP’s whole premise was that it makes your code depend on much much less things so you can “fit it in your head and reason about”… that’s like the perfect sweet spot for agentic as well, we just haven’t seen tools utilize that in earnest.

>What you need is for your LLM to be able to understand enough context to be able to make a change with as few token as possible, so if your code isn't expressive enough

Recently there's an article on language plasticity in the era of AI/LLM and why D language is very well suited for this era [1].

Perhaps we need a proper benchmark similar to Beaver but for AI assisted coding for different programming languages instead of Text-to-SQL [2].

[1] Language Plasticity is More Important Than Ever:

https://blog.dlang.org/2026/08/10/language-plasticity-is-mor...

[2] BEAVER: An Enterprise Benchmark for Text-to-SQL:

https://beaverbench.github.io/#overview

Additionally, if there’s more “knowledge” of the code and best practices and such baked into your model, it has to spend fewer tokens reasoning about it or even potentially looking it up. I think even one web search to retrieve additional information not also in the model will probably blow up any supposed benefit you’d get by a slightly more token-efficient language.

APL would win in that regard.