What's the best programming language for coding agents?

I'm not sure I trust a source that says "just 70 tokens average, nearly half of Clojure (109 tokens)".

There's no reason to add the phrase "nearly half of", and there's especially no reason to add it when it's significantly far away from half.

But on the main topic, I still feel that Go is an excellent choice for LLMs. There is pretty much just one way of doing most things, and the available training data is pretty consistent. This is very different from Python, where training data is polluted (I presume) with tons of code written by non-software engineers and demonstrating many different ways of doing the same thing.

Also a big plus for Go is the tooling. Fast compiles and good linting shortens the iteration cycle time, resulting in less need for me to tell the LLM to correct mistakes.

For some reason, most LLMs I've used default to wanting to write Python. I have to repeatedly teach them to use Go unless there is a very compelling reason to choose otherwise.

I would personally rather see and use Clojure, but I don't feel its ecosystem would provide the same benefits as Go, including obviously the easy single binary distribution.

Ive been amazed at how well LLMs are at writing Gleam[1] and Lustre[2]. Compared to a mainstream language, there is basically zero gleam code in the training data.

I have no evidence to back this up, but I suspect that languages that are good for humans[3] will be good for LLMs. Compiled, strongly typed, statically typed, immutable, pure functions, pattern matched, memory safe, etc.

[1] https://gleam.run [2] https://lustre.hexdocs.pm [3] Yes I realize that languages features that are "good for humans" is a hotly debated topic. That's just my personal list for what I like in a language.

We studied this question pretty systematically in the MirrorCode paper [1], comparing Python, C, Rust, Go, OCaml, and Ada across 19 very long-horizon tasks, for Claude Opus 4.7 and GPT-5.5.

> In our results, there was little sign of inter-language differences in solve rates, for any model (Figure 5b). This suggests that AI models have learned generalized programming skills, rather than pattern-matching syntax. This does not mean that implementation language is irrelevant. Conditional on solving a target, we found a small effect on token usage: successful Python solutions tended to use fewer tokens than average, while successful Ada solutions tended to use more (Appendix C). We consider these to be small differences, given that these six programming languages vary widely in how concise they are, and in how much functionality is provided by their standard library (recall that agents cannot download dependencies in MirrorCode, they must solve the task using only the standard library).

In Appendix C, Ada tended to use only about 25% more tokens than the average language. Ada is a language used mainly in safety-critical aerospace and defense systems, which has ~200x less pre-training data available than C or Python.

We're also comparing more recent language models (on just Go vs Ada, for cost reasons), on our leaderboard [2].

[1] https://arxiv.org/pdf/2606.30182

[2] https://epoch.ai/MirrorCode#leaderboard

Contrary to what most comments seem to indicate, my takeaway from this is that it doesn't really matter all that much for the agents what language you pick. If humans are still to be involved in the process at some point, then its imperative that the language can be read by them, so the preference or skills of the developer(s) are of primary concern, not the agent.

It's not clear to me how useful of a signal replicating existing pieces of well-known software is for this kind of evaluation, given what we know about how effectively LLMs can retrieve data from their training corpus and style-transfer it across different settings (programming languages here). That would explain their convergence in ability across different languages on the tasks in this post. I'd be far more interested in people's real-world experiences.

Related:

Which programming languages are most token-efficient? - https://news.ycombinator.com/item?id=46582728 - Jan 2026 (91 comments)

One thing worth noting is that syntactic density doesn't necessarily mean cheaper because because symbols don't chunk/tokenize as well as plain English

What I see from results like this is that the delta between languages is small enough now that it's hard to justify not not using something like Rust for the performance and correctness benefits if you're using LLMs and it fits the domain

Cool line of questioning, but one piece of information is pivotal and critically not-yet-included: equivalent accomplishments in each language. For example, if I want to write standard things: web server, memoized fibonnaci, recipe search engine, what's the length-and-density of these outputs for each language? I think that would add in some ~normalization.

This is a great discussion: I wonder though if we are asking the right question. Yes, absolutely language choice can play a large role in the efficiency of coding agents. The point about Rust is right: static typing provides a fast verification loop at compile time. I would argue though that the way the codebase is composed could actually generalize the concept of "easy verifiability" past the actual coding language.

For instance, if an application can be broken down into components that have a verifiable contract in how they are to be used, then an LLM can load only the relevant modules into its context and fully understand how to use them and fix them if needed. It is also easier for the LLM to verify the functionality of a component rather than the entire system.

Additionally, in an application composed of functioning components, issues are more likely to occur at the boundaries between them, which the LLM can focus on rather than having to always consider the entire application that it most likely can't load fully into its context.

A well designed componentized Python application will likely be far more efficient for modification by an LLM than a large Rust monolith.

> Most of the claims that get thrown around about how a particular language is good for LLM use seem to be wrong (e.g., the claim that Ruby, Clojure, and J, are particularly well suited to LLMs, which were mentioned in the evals linked above, as well as the somewhat common claim that Elixir is particularly suited to LLMs), but it's not clear what's right.

I feel this is a missed opportunity to explore the architecture of Elixir and why it's suited for agentic coding. With elixir, as long as the agent does all the work in a separate worktree and then applies the changes at once in the main repo, if you have a long living runtime the BeamVM is able to swap modules with their updated versions. AFAIK, In elixir every module is an autonomous actor that communicates with message passing and is isolated in their own VM. Agents can implement functional code batches and see the changes take effect in real time, no matter if it's a web server, a data transformation pipeline or something else.

> Dynamically typed languages generally have a lower LLM token cost than traditional statically typed languages because omitting explicit type declarations makes the code more compact.

If this was true, the programming languages that are very much on the left side of

> https://danuker.go.ro/programming-languages.html#non-math-ma...

> https://danuker.go.ro/programming-languages.html#overall-map

should be very ideal for LLMs, in particular if they are dynamically typed.

What I can tell you is: I experimented with AI prompts for generating Wolfram (Mathematica) code using some LLMs, and I can tell you that the results were very disappointing: in my experience LLMs have difficulties with programming languages that are

- very concise, and

- for which there is less code publicly available.

Wolfram (Mathematica) is a good example of such a programming language.

Zstd gets rather easier from dotnet 11, it becomes a near one-limer since it's getting added into System.IO.comoression.

I know this because my agent already knew this the other day when I was evaluating compression, but that's because it has access to search.

That's a key part of what makes agents good coders too, mine is often looking up and downloading the source for how libraries are implemented.

It seems unnatural to air-gap them for evaluation.

I guess they didn't want them just finding an existing library to copy, but it's not very "real-world" to deny the ability to search quickly.

That said, the best language is still just the one you know. No amount of token saving is worth getting a bunch of code back you can't easily understand and review.

I love Dan's writing. I really do. But I don't understand why he doesn't have some basic styling on his blog so that it's easier to read.

I discovered last week that Fable 5 can write perfect xTensa LX7 assembler code without tools or references. Mind blown.

But, when working on a creative graphics task, the results were best in Lua, middling in integer-only C, and underwhelming in ASM in terms of creative depth.

Python has a less known advantage because it had no curly braces, so LLMs can focus its attention to logic instead of syntax.

https://blog.est.im/2026/stdin-11

Interesting to see Factor and J so far to the bottom and right in the zstd test, but much closer to the rest in the Pandoc test (with Asm taking their place). This suggests that both the task and language (not just the language) influence the efficiency.

I try to use LLMs for Kotlin, Python, Emacs Lisp, and Smalltalk (among many others, but these are what I have ongoing projects in). You'd think that Kotlin and Python would be much easier to generate than the other two, right? But that's not what I observed: Elisp is very close to Python in terms of how fast and how many tokens it takes to generate the code! The generated Elisp code is often better on the first try than generated Kotlin code for a comparable task.

Smalltalk is... complex. It's meant to be developed interactively in a running image, but running Codex on API pricing is too expensive, and Codex CLI cannot interact with the image without a lot of plumbing. I ended up building multiple tools that live in the image and a protocol for calling them, and a set of skills for using them - including code search, docs search, test runner, and script/string evaluator. I also defined a way of annotating types for method arguments and return values (without having a type checker), which helped a lot. Still, it's an uphill battle; I wouldn't go there on API pricing!

My takeaway is that it's not obvious which language fits the LLMs and a given task best.

What is the best language for the user of the LLM?

What is the best language to have high quality correctness oracles so that the user doesn't have to babysit the LLM and do lots of manual testing?

Cool seeing Guards of Atlantis 2 here.

One thing that often happens with board games is rule issues in translations. Specifics that are clear in one language get lost in translation. Wolff Designa is out of Latvia. So not surprised there are some hard to interpret rules.

It’s interesting that LLMs struggle with the board game rules like we do. I think game designers should get the llm to teach them from their rulebook. If an LLM can’t understand the rules good chance people will also be confused.

What's optimal for LLMs and for people is probably not going to be the same. People are a bit lazy.

Coding agents do much more than generating code though. Much of what they do relates to validating that what was generated is a valid solution. That includes everything from type checking, running tests, static code analysis, linting, running code in a headless browser, etc. The more tools agents have at their disposal, the better the feedback loop gets. But of course some of these tools are costly to run.

Statically compiled languages have a head start here as they simply exclude entire categories of bugs that a dynamically typed language might have. And with things like type inference, their token overhead can be pretty minimal. Modern languages like Kotlin or Swift are pretty compact and don't really add a lot of bloat relative to say typescript/javascript. Go is a bit more verbose but tends to work well. Rust seems pretty popular with LLM users as well. The main challenge with languages like this is the performance hit you take running their build tools. Doing that a lot slows you down and it burns a lot of tokens as well.

A while ago I benchmarked different tokenizers with a few common C++ coding styles. Depending on the combination I was able to reduce the token usage by as much as 5% just by auto formatting the codebase with clang-format. Of course, this doesn't necessarily mean that a coding agent would perform better, but it was a fun experiment.

I don't care so much about token efficiency and cost, within reason. I care about whether the quality of the code is maintainable over time and through many iterations. My gut feeling is that very strict languages with good types, a standardized style, and very strong static analysis tools, is what helps make that happen. Of course it also has to be well-represented in the training data.

That leaves Go, Rust, Python with type annotations, and Typescript. And, I choose them in roughly that order unless there's a reason to choose otherwise. Rapid iterations on scripty tasks get Python. Most CLI, system services, and web apps are Go. Desktop apps and games are Rust. Typescript if I don't have a choice (i.e. it runs in a browser).

IMO, rust.

Not because it is concise but because you won't need to spend tokens debugging segfaults and a whole spectrum of bugs that the compiler catches. LLMs usually write tests in the same source files so most features are implemented and working in one shot.

C and C++ do well because there is most literature and code out there to help them reason about it. C is helpful because it has little hidden runtime for them to trip over.

that being said, those languages obviously have limits in applicability looking at the entire spectrum of software. JS, python and others still have useful domains.

i dont think newer languages as rust are better for LLMs as they might be for new programmers. for new programmers they offer extra features but for an LLM this is added potential to make mistakes. Also a lot of newer languages are less stable so you can realise their current implementations might not be fully trained on by the models or even be after their cutoff date..

Great post. If it wasn't clear by now, considering a language's token efficiency is almost certainly incorrect, since it's only a local optima for input/output of the code.

Most session tokens are spent elsewhere, so an LLM that handles a token-efficient language more poorly can be worse overall.

If anyone remembers TOON from a few months ago, it was an attempt to replace JSON with a more token-efficient representation. TOON was much more compact, but when researchers examined whole-session effects, it was a wash, because harnesses wasted more tokens than it saved dealing with it. (TBF, it's possible TOON use has gotten better if later models have it in their data set.)

Architect your system to use the best tool for each problem. Doing a minimal data pipeline? Use Python. Building a backend? Use Go. Building a frontend? Use React / Typescript.

Building a stack that does all of these? Still use Python, Go, React/Typescript. Because by architecting it this way you make the AI less likely to accidentally refactor logic between layers. In other words, architecting with multiple languages helps create persistent boundaries that isolate different kinds of logic into their appropriate modules.

I believe soon we will have a language made exclusively for coding agents that will be highly token efficient and difficult for humans to read, as human-in-the-loop will be ditched entirely.

I'd like to see the results for Ada on these same measures. On the theory that the Ada type system covers more classes of errors than other languages, and so AI can self correct better.

I wonder if there's correlations between tasks and languages, e.g. maybe R is better for bioinformatics tasks, python for webdev, C for CLIs, etc. I'd expect to see it because some languages are used more often in some tasks than others, but on the other hand LLMs can learn across languages and it's not clear if task-language use patterns are just historical or if the language is genuinely better at the task.

For me c wins here. It is compact, there are all language parts one needs and available and it well fitted to transport knowledge without much syntax hussle

This analysis might benefit from a multivariate regression. You mention a few different explanations for why performance differs and if you could get solid numbers for those you could try teasing that apart.

Also a small note: the axis on one of your plots alternates between 4% and 5% increments whilst holding the ticks constant. Maybe because of rounding?

I'm surprised there is no breakdown of "with skills" (framework) and without. In my experience, apart from human readability, the ability of a model to follow strict skill rules is the important. For example I see a lot less waste of tokens and reasoning retry loops of obvious errors when using Python with uv+ruff than without.

I few months ago I tried to make a project using Fennel (a lisp flavor of lua). I always wanted to use lisp, and hey, since it was the OG AI language I though why not.

Claude could work on it okay apparently but some local llm's struggled with it and got stuck in reasoning loops trying to close the parenthesis.

Any good LLM service (not just coding-focused ones) will write and run ad hoc code without being asked if your prompt involves lots of data. Gemini and Claude tend to pick Python with maybe some SQLite. Some of that must be due to portability alone, but it also means they'll make sure the model and tooling are good at those.

How good or bad are LLMs on languages that have evolved over the years and aren't popular enough to get hand tuned?

Asking because for non programming, if you use them instead of a wiki for a topic that has had yearly changes for like 10 years they get confused and mix releases like crazy.

First, How fast is the Zstd decoder in python at runtime? If rust and python are essentially the same cost, then chose rust.

Second, I am surprised that python scored slightly better than rust. My own experience is that, when programming python, Claude would spend so much more time dealing with the code not working at runtime, while for any given rust problem, rust would likely fail at compile time, iterating faster and taking less tokens. Some tasks in python it just completely failed at, writing awful garbage. I suspect that is because there is much more awful garbage written in python. (I was trying to write an AI harness. Python seemed like the obvious choice. It was decidedly not).

But in this article, python took slightly less time and tokens than rust for both experiments.

I asked Claude: could you write a decoder, from memory, in python (dont do it, just tell me if you could)

> Honestly: I could write something that's structurally right and would not decode a real .zst file.

> The control flow I'm confident about from memory — frame/block parsing, the literals section dispatch, Huffman weight reconstruction, the backward bitstream reader, the interleaved three-state FSE loop, sequence execution with the repeat-offset rules and the overlapping-copy hazard. I'd expect to get that architecture right, and it would be readable.

So perhaps asking it to do things that are in its memory is not a good benchmark. It was trained with the C "educational decoder, and every third-party port in Rust, Go, Java, JS." and offered a working link [1] to the former.

  [1] https://github.com/facebook/zstd/blob/dev/doc/educational_decoder/zstd_decompress.c

In my experience, Dart/Flutter has been so much better than React. Go has been really good for the backend. Basically if the framework/language gives you structure and one way to do things, agents tend to create less mess with less guardrails from you.

The article seems to me to be quite poorly written. In addition, voluntarily or not, this begins to resemble research work, without the formalism that would be necessary. So, I have the impression that we can objectively get nothing out of it.

Is there a relationship between how good a programming language is for coding agents and how popular it is among humans? If so, wouldn't Python be the best language for agents, since it's is the most popular (and hence has the most context available for models)?

The benchmarking in the article gives a clear answer to the title question: Python and Javascript. However, the article doesn't just bury the lede, it misses it entirely, getting distracted by outlier results from clojure and j.

Clojure's performance improves dramatically with an MCP REPL server. Part of that improvement is that the LLM gets parens balancing for free.