A while back, my mother, a talented software engineer, asked me a somewhat strange question about programming.

"Are we just stuck at Python now?"

She meant this in the context of: now that LLMs are writing more and more code, and thus humans are writing less and less, are we even going to bother continuing to improve on languages or making new ones for particular use cases? Or are we going to continue using C (Bell Labs, 1972), Java (Sun Microsystems, 1995), Python (CWI, 2000), and its peers until the end of time? After all, the corpus of training data for these frontier models is tightly bundled to the existing code scraped from Github repositories and StackOverflow posts.

My initial intuition was no, there's no reason why that would be the case. Certainly, the aforementioned leanguages are constantly undergoing new changes to improve security, reliability, etc, which already dispels any notion of a purely static, unchanging languagescape. But what about new languages?

Well, I claim that the next natural evolution in programming languages is already here, and it's English.

English is the New Python

This may be a somewhat simplistic view of programming languages and their trends, but if we think about the progression of languages: Fortran, COBOL, Assembly, Lisp, C, C++, Java, Python, the general direction is moving from lower-level to higher-level languages.

Many of you will know this already, but by lower-level, what I mean is that it sits closer to the hardware; for instance, in assembly you're literally assigning registers, in C you would compile to assembly but still need to manage your own memory. A higher-level language like Python hides all that away under many layers of abstraction, and provide us convenient functionality without having to live in pointer management hell. For many hardcore, old-school programmers, something like Python is already heretical and more vibes-based than anything else.

With the widespread adoption of LLMs, English has essentially become the next natural abstraction, with the LLM serving as a sort of non-deterministic compiler to some other language (Python, Typescript, Java, whatever). The middleman language then eventually gets translated to machine code.

There is a twist here, in that the phrase non-deterministic makes English as a programming language fundamentally different from those that came before it. Of course, there's always excellent mechinterp work being done, but the standard engineer is treating the model like a black box, similar to how we perhaps think of a C compiler. But the C compiler will always return the same output when given the same code, and if you wanted, you could go find out exactly what that output is for any input and how the compiler arrived there.

English is, therefore, the first influential programming language that is entirely nondeterministic, whose output is subject to the whims of the latest frontier weights. It is both utterly uninterpretable and the most human-readable language to date. In the modern world, it's tempting to believe that the skills needed to debug a nasty memory leak or to build a simulated CPU or to write a quine in Lisp are as obsolete as the punchcard programmers of years past. But I feel strongly that being a competent engineer is more important than ever.

Education and experience is more important, not less

There's a sentiment I see floating around quite a lot on X (formerly Twitter) nowadays, which is that taste is king, and there's no more engineering moat because anyone can just build anything using Fable or GPT 5.6 or <insert new frontier model here> (provided you're a US citizen, I suppose).

As with most absolute statements, this one is only partially true. What I view as the core of engineering — the ability to turn the thoughts in your head into a durable solution in the world — is something that still requires a fundamental understanding of how your system works. You might be able to "taste is king" your way into a nice personal website, but you aren't going to be able to design a system that can serve millions of users.

I think a lot about Berkeley's EECS/CS program. At the risk of sounding like an EECS shill, I do think the 61 series is exceptionally well-structured to teach you the *concepts* behind programming and not any particular language itself. CS61A is in fact often derogatorily referred to as an "IQ Test" because of this lack of focus on things "everyone can learn," like how to write a for loop in Python, and strong emphasis on creative problem-solving and a fundamental understanding of how an interpreter works. Which, for the record, I think everyone can learn, but which takes considerably more effort than learning the syntax of an arbitrary language.

This is particularly important in the modern era, because LLMs enable you to solve the same problem in many different ways, not all of which are conducive to long-term reliability. I found this out the hard way during my first major end-to-end fullstack project. As a new hire, I was assigned a relatively simple feature (or at least, that's what we thought at the time), and a coding agent wrote it up for me in very little time at all. It worked perfectly, first try. Then, several things happened:

  1. I had a sort of "come to Jesus" moment where I was like fuck, there's no reason for me to have a job.
  2. My tech lead looked at the PR, and respectfully told me that many of the decisions in the code were questionable.
  3. I rederived the feature from first principles, wrote some docs, solicited feedback, and had an agent tackle the code, and the result was much, much better.
  4. I realized that doing that was my job, and it was a necessary and nontrivial one.

In refining the core decisions for the agent, I'd cut multiple files, reorganized some messy logic, ironed out some product kinks and edge cases, and overall made the code more readable and maintainable, for both humans and agents.

This process of holding a project's context in your mind, designing the architecture, making organizational decisions— this has always been the point of programming. It's just that now we're using English instead of Python. And at least for now, you can't get there with all taste and no experience.