In LLMs and programming language diversity I argued that LLMs seem likely to increase the diversity of programming languages, in two main ways:
- LLMs make it easier to implement and test new language toolchains
- LLMs can learn new languages at scale faster than the population of human programmers
One way to think of the consequences might be to imagine the process of new language adoption over the last 20 years — basically no mainstream success apart from Rust and arguably TypeScript — and imagine that the process runs a bit faster. Maybe someone comes up with a language which popularises algebraic effects, or which has a more GPU-friendly concurrency model, and rather than taking 15 years for this to catch on, it happens in 5. Maybe these new languages produce safer or faster code, and so safety or performance-sensitive applications are rewritten in these languages. This is certainly possible, but it would be just like the last cycle, only faster.
But if we think that LLMs are going to produce deeper changes in how code gets written, then this scenario is at best incomplete. This scenario also suggests that LLMs will behave like human programmers, just faster and more flexible. This also seems like it could be true, but might under-sell the possibilities.
Assuming model intelligence (acknowledging that this is a nebulous concept) continues to increase, and token cost at a given intelligence level continues to fall, then code is going to get ever-cheaper to write. It may even become abundant, in the sense that if a problem can be solved by writing code, there’s a good chance that an LLM will write that code.
As we know from the Jevons Paradox, increasing the efficiency of some service can make new uses for that service viable. If programming becomes an order of magnitude or two cheaper, along with the management of the processes around it, then we ought to expect a lot of code to be written which would not be worth paying humans to write. Because of this, we ought to expect that code to look and act quite different to human-authored code — it will serve different purposes, evolve in different ways, and be discovered and distributed by new mechanisms. And, relevant to my previous post, it may well be written in new and different — maybe very different — languages.
For an example of something fairly outlandish by today’s standards, imagine that agentic applications communicate using zero-knowledge proofs or other cryptographic protocols. The language we use to describe and compose these proofs will be different to regular programming languages. But whereas this is an obstacle to the human programmer, the LLM will overcome it much more easily. Morever, custom protocols might even have custom DSLs, with session types for protocol safety; LLMs could jointly compose new protocols on-the-fly, or even whole new languages if the scale and scope of the protocol grows large enough.
This has a kind of paradoxical effect on human programmers, I think: the less like human programs these LLM-authored programs are, the less humans and LLMs are competing with each other. If we find that there’s some new type of program which LLMs are good at writing, but humans are not, then human programmers ought (for self-interested competitive reasons) to want to see LLMs getting employed to write those programs, instead of human-style ones!
Of course, the longer-term effect would likely be to transform the nature of our computing platforms entirely, and with it the role of the human programmer.