When I was ten, I connected MSX computers to each other through sound. Those machines had real limits, and working inside them taught me to think about problems in a different way. The language and the machine were not just tools. They shaped the ideas I could have.
I keep coming back to that, because I think the way we write code now is pushing in the opposite direction.
The assistant has favourites
An AI coding assistant is not equally good at every language. It is good at the languages it has read the most, and it has read a lot more of some than others. In the part of The Stack, a public corpus of code, that one study used, there were about 64 GB of Python and around 1 GB of OCaml. The difference shows in the results. In that study, the same model wrote correct code on the first try about 30% of the time in Python and about 7% of the time in OCaml.
Same model, same kind of task. The only thing that changed was the language.
That gap is not a secret, and developers feel it every day without looking at any benchmark. In one language the assistant finishes your thought. In another it guesses, invents functions that do not exist and writes code that looks like Python with different brackets.
The loop
Once you see the gap, the rest follows. If the assistant is better in Python and TypeScript, people choose Python and TypeScript. More code gets written in them. That code becomes public, and the next model is trained on it. The next model is even better at those languages, and the gap grows.
Robert Merton called this the Matthew effect: to those who have, more is given. He was writing about science, but it describes this loop well.
We can already see it in the numbers GitHub publishes. In August 2025 TypeScript became the most used language on GitHub by number of contributors. GitHub connected part of that to AI: typed languages make code written with agents more reliable. That is a good reason. It is also exactly how the loop works. The choice that suits the assistant becomes the choice that wins.
Here is the kind of thing that makes typed languages attractive with an agent. A payment response can come back in three shapes, and only one of them has a transaction id. An assistant writing JavaScript will happily return Processed ${"res.transactionId"} and ship "Processed undefined" to production. In TypeScript the compiler stops it on the spot, and the agent has to handle every case.
type PaymentResponse =
| { status: "succeeded"; transactionId: string; amount: number }
| { status: "requires_action"; redirectUrl: string }
| { status: "failed"; errorCode: string; retryable: boolean };
function handlePayment(res: PaymentResponse): string {
// return `Processed ${res.transactionId}`;
// error TS2339: Property 'transactionId' does not exist on type 'PaymentResponse'.
switch (res.status) {
case "succeeded":
return `Receipt: ${res.transactionId} (${res.amount} EUR)`;
case "requires_action":
return `Redirecting to ${res.redirectUrl}`;
case "failed":
return res.retryable ? "Retrying payment..." : `Error: ${res.errorCode}`;
}
}So choosing a less common language now has a new cost. OCaml, Racket, Elixir or Zig always meant fewer libraries and fewer people who know them. Now it also means a worse assistant. Nobody forbids those languages. They just become a little more expensive every year, and I wonder how many of them will still be a real option for a team in five years.
Languages are ways to think
This would not matter much if languages were only syntax. But they are not. Each one carries a way of thinking about problems.
Paul Graham described this with what he called the Blub paradox. A programmer who knows only an average language, Blub, looks at weaker languages and sees what they are missing. When he looks at more powerful ones, he does not see power. He sees strange code. You cannot miss an idea you never learned.
I know this from human languages too. Today I am bilingual, and I think in both Spanish and English. I do not choose which one. My brain does, depending on the subject: some things come to me in one language and some in the other. I even dream in both.
I also write poetry in both languages, and that is where the difference becomes impossible to ignore. When I try to say the same feeling in the other language, it does not come out the same. It is not a lack of words. Each language gives the feeling a different shape. That is why a translated poem is always an approximation and never the same poem.
Programming languages are much simpler than human ones, but the principle holds. The language you think in decides which ideas come easily, and which never come at all.
That is my real worry. A language with pattern matching, or with no mutable state, or with macros, changes how you split a problem before you write the first line. If everyone writes in the same few languages, and an assistant suggests the most common shape of code in those languages, we get the statistical average of software. Not wrong. Just average. And over time we forget there was another way to design it.
What I am going to do about it
I am not against the speed. When I write a TypeScript service, I use an assistant and I am glad to have it. For production work, choosing the language your tools handle well is a sensible decision, and I would make the same one.
But I want to keep some curiosity at the edges. A small project in a language the assistant handles badly makes me do the thinking myself again. That is not a waste of time. It is the same lesson the MSX gave me: limits change the way you think.
Use the standard language for speed. Keep a corner for the others. The ideas that the next average will need usually come from there.