The Best Language for AI-Assisted Coding Is…

If you ever had an LLM generate code for the same problem in different languages, you might have wondered whether some languages are more suitable than others for being read and generated by LLMs. Maybe you even observed a notable difference in quality between the different outputs.

Could there be a specific aspect of a programming language that helps LLMs to better understand code they're reading, or generate better code?

In other words, will we witness an “agentic coding singularity” in which all coding agents use a single, synthetic “hyper language” that pushes all other languages into oblivion (or into the shelter of human developers who still love to craft code by hand, discuss languages and programming techniques, and be familiar with a codebase)?

Will all programming languages become obsolete?

Or does the choice of a programming language become increasingly irrelevant, because LLMs can emit code in almost any language you ask them to? Like, “Write Space Invaders in SQLite!”

On measurability

When asking about differences in quality, we need to define “quality” and determine measurable aspects of this definition. A few aspects come to mind:

Functional correctness

Does the code do what the spec requires? (Yes, writing a spec is a good idea.) Are the tests meaningful and do they pass?

The rate and nature of errors and bugs

How many errors does the code produce when running? How many bugs are hidden in the code that may cause wrong behavior, break data, or open security holes?

Clarity

Is the code clear and readable to a human reviewer (and to an LLM that has to maintain the code)?

Token efficiency

How many tokens does the LLM burn through when reading a certain amount of code? That's not just a question of cost; rather, if code translates efficiently into tokens, more code fits into the LLMs context window, allowing it to analyze larger codebases and better understand the bigger picture.

Studies have been done, but…

There are plenty of studies and benchmarks that evaluate how LLMs perform at coding tasks in various languages. Don't expect that a clear winner has emerged from all this research activity; there is none. Moreover, I wasn't able to find a study that evaluates the latest frontier models. There's a broad consent among LLM users that these models enter new levels of coding quality. But even without, some language characteristics seem to increase a language's suitability for LLM coding.

For example, static typing is a clear advantage for coding agents, as they get helpful feedback at compile time already and don't have to run tests to uncover type-related bugs.

A bachelor thesis found some indication that LLMs work better with languages that have low levels of abstraction, a clear syntax, and straigthforward semantics.¹

The one thing more important than language characteristics

This doesn't help much with answering the initial question, though. There is still a wide range of statically typed languages that aren't too abstract and convoluted. But there is one more aspect that turns out to be important, and it's not related to language characteristics.

Consider that LLMs don't understand programming as humans do. LLMs cannot draw logical conclusions. All they do is calculate the most probable answer to a given input, based on their huge knowlege base encoded in the nodes of their neural networks. This fact leads quite naturally to the following conclusion:

An LLM gets good at writing code in a given langauge when it is exposed to large bodies of code of that language (and hopefully, that's mostly code of good quality). So the more popular a language is, the more code is publicly available, and the better an LLM can generate working code in that language.²

What this means for Go

It's one and a half decade since Go 1.0 was released in 2011, and this means a lot of Go code is already out there, ready for LLMs to learn form. But so is code written in languages like C, C++, Java, C#, Python, JavaScript, and Rust.

For me, Go is still a winner in the discipline “most suitable LLM language”. It has quite a number of wonderful advantages, and some of them are a match in heaven for LLM coding:

A fast compiler

Go's insanely fast compile time is a game changer for agentic workflows that test code repeatedly until the LLM is satisfied with the result. While compile times of other languages pile up to hour-long sessions, similar edit-compile-test loops in Go complete in minutes.

A rich, battle-tested toolchain

The benefit of tool execution increases with the capability of each tool. Go's toolchain is mature, battle-tested, and covers many tasks that other language ecosystems would have to pass on to third-party tools.

Long-term stability

Go has proven to be exceptionally stable over the years. Code written in Go 1.0 still compiles with Go 1.26 with very few exceptions (usually caused by security fixes that sometimes cannot avoid breaking things). LLMs love language stability.

And so much more

There are so many more great features of Go that make Go a superb choice for both humans and LLMs. As long as agentic coding workflows require a human in the loop, the choice of language remains important.

As a software developer, you are responsible for the code you ship, whether you craft it by hand or let an LLM do the task. So until (and if ever) we reach the Final Tipping Point after which humans don't need to look at generated code anymore, you'd better choose a language that is easy to read and easy to review, and generally pleasant to work with.