Why Programming Languages Fail I
September 2026
Assuming artificial intelligence will become a super intelligence someday, I believe all present programming languages will be obsolete for practical use.
I know this sounds preposterous to say but whenever I see people gamify understanding their own code, claim reading code no longer matters, or build agent systems with infinite tests, I convince myself people will understand where I come from.
I don't think coding is doomed. I just think all of the previous examples are coping mechanisms that exist because we lack tools.
For the last few months, I've been building a new programming language that survives AI superintelligence. A very daunting task that present programming forced me to work on. And in my journey, I found three reasons why programming languages won't work like they used to anymore: they lack a structure that scales understanding, they don't scale searching for information and they force upon us a fixed layer of abstraction.
These were not problems when languages were used only by humans. Before, coding meant understanding what I wrote. Now that AI writes code at exponential volumes, it's easier to ask it to write and to explain code. However, in the long run this has delegated my understanding to AI. What's worse, I can't go back because coding by hand isn't efficient anymore. Describing what I want to AI always seems to be faster than writing lines of code. Which made me think a new language was impossible. It didn't matter what design rules I came up with, I always could imagine a scenario where I couldn't understand the code because of the infinite number of lines AI would write. What I wanted was a language that scales understanding as lines of code increase.
Exponential code output also means we now need to ask AI questions about our codebase. But asking questions and reading code are different. Asking AI to search and update code makes you over time incapable of finding the right code and updating it yourself. It makes you once again lend to another intelligence your understanding. Contemporary language designs again do not help here. The logic you need most likely lives in multiple files and lines of code. So if we assume our codebase is infinite then we are forced to use AI to search.
I've come to the conclusion that a language must make it easy to find where the change you want to make is. I find it curious that before AI, we had this issue too but text matching and static analysis were enough. Back then we had human level lines of code and we could trust the language to set the scope of what a human must understand.
It's obvious programming languages live in a fixed layer of abstraction. Assembly requires you to understand registers. C++ asks you to understand memory but not registers. High level languages like Python need you to think with imperative logic and not worry so much about memory. This has been the case for so long it's become a feature of language design. It's unthinkable it can be any different. What would happen if you could somehow create pointers in Python or use registers in React. Would it even make sense? Of course not. A language should have a defined layer of abstraction that a human can understand and produce human amounts of output using it. But you see the problem now? It's the same problem from before. A language with a fixed layer of abstraction is unusable in the AI era. Whatever abstraction scope you design for a language, AI will produce infinite lines of code on that level and beat you to understand it.
All three problems: understanding at scale, fast searching in the codebase and fixed layers of abstraction, need to be solved. Leaving just any one left is enough to make a new language unusable. Though interestingly after solving all three, I noticed that in theory I just needed to solve any of them to get them all.
But do these problems actually have a solution? If so, how do we start fixing them? Thankfully in 2003, Paul Graham in his essay “The Hundred-Year Language” came up with two simple design ideas that I needed to create my new language. The first idea was:
One way to design a language is to just write down the program you'd like to be able to write, regardless of whether there is a compiler that can translate it or hardware that can run it.
His second idea included a warning:
What program would one like to write? Whatever is least work. Except not quite: whatever would be least work if your ideas about programming weren't already influenced by the languages you're currently used to. Such influence can be so pervasive that it takes a great effort to overcome it. … One helpful trick here is to use the length of the program as an approximation for how much work it is to write. Not the length in characters, of course, but the length in distinct syntactic elements -- basically, the size of the parse tree.
Both together yield the simplest question: is there a way to write something short and that I'd wish to write? Turns out the answer is yes.
Thanks to Cristhian Agüero and Matias Avendaño for reading drafts of this.