Use boring languages with LLMs — Jacob Young

Skip to main content

Use boring languages with LLMs

Apr 20, 2026

I'm Jacob - I run<br>Sancho Studio<br>a software consulting group, we help companies with technical<br>leadership, strategy, and security.

I keep coming back to this idea that consistency compounds. I’ve noticed it acutely as a consultant working on multiple different projects in the last two years. Large language models amplify inconsistent technology and quietly reinforce consistent ones . The languages and ecosystems that suffer from the most fragmentation produce the worst agentic output, and the ones with the strongest conventions produce the best. I think this effect will increasingly determine which tool survives in the paradigm of massive models trained on large corpuses.

Even if code is cheap, running inference is a gamble. It’s impossible to know if at any moment the model will make a decision to install a package or produce a bizarre coding pattern from 2019. If we consider that we’re gambling with tokens, we should bet on the set of embeddings which represent strongly consistent and reinforced model weights to produce median output. For software development this is actually ideal as the median program is typically doing the basics: processing information, reading/writing files, responding to network requests, etc.

Before AI, engineers complained about languages which reinvented themselves on what felt like an annual basis. These complaints were real but mostly aesthetic and symptomatic of a frustration that humans needed to maintain or keep up with needlessly changing ecosystems.

If we look back, the 2024 State of JS survey describes a relatively fragmented ecosystem. For a human, fragmentation is annoying. For a model trained on the public corpus of all of it; fragmentation is something closer to a problem which needs to be solved in reinforcement learning or agent harnesses (e.g. Claude Code leaked and showed us that Anthropic hard-coded some bias for JavaScript frameworks).

Python is the same story but sung in a different key. Asking a simple question like “which package manager are you using?” produces a matrix of language versions, package manager version, and OS compatibility which I find to be completely mind-numbing as a technical lead.

Should one use pip, poetry, or uv? Does your toolchain matter, or are you cross-compiling? How do you know if a Python package silently has a link to a C dependency? Are you using async, or have you reached for a task queue instead? Django or FastAPI?

xkcd 1987

From a model’s standpoint, there are simply too many ways to write any of this, and the corpus reflects every one of them in roughly equal weight unless recency bias is introduced at training time. What this means is straightforward to me and should be to you as well… Languages and ecosystems with low variance in their training corpus are represented better and executed more reliably by coding agents. In higher dimension vector spaces, cosine similarity in the training data is the substrate on which the model’s attention and MLP layers learn to predict the next token. A consistent corpus produces consistent inference tokens.

This pattern holds in other languages. Inference on Rails projects produces more consistent output compared to generic JavaScript backends in agentic work, not because Ruby is a better language in some Platonic sense, but because there is essentially one Rails. There are at least a dozen production-grade JavaScript frameworks offering different Venn diagrams over the same default features. Convention over configuration was a win for human programmers because flexibility is overrated and constraints are liberating. Twenty years later the same is true for machines, and arguably more so. The model just is solving for which outcome is most likely…

Go embodies this principle best and almost by accident. For years Golang resisted the conveniences and higher-level expressions that programmers kept demanding (generics in particular) and the resistance was deeply unpopular among working developers. I was one of those developers; I have written hundreds of thousands of lines of Go, and as a programmer I found the language often infuriating.

I know some of the people on the Golang team and admire their headstrong commitment to the future of programs. I have come to think Google produced, mostly inadvertently, the best language in the world for this moment. Out of the box, Go gives an agent a set of advantages no other mainstream language provides in the same combination.

The concurrency model is the first of these. Goroutines are a far more tractable primitive for coding agents than threads, callbacks, async/await, or any of the colored-function regimes that dominate elsewhere. They are simple, type-safe, and ubiquitously used in the corpus the model was trained on. There is no question of what color your function is, because the question does not exist.

results :=...