We spent seventy years making code more readable. I think we might be at the top of that curve, and what comes next isn’t what anyone expected.
The ladder
The history of programming languages is a story about readability. The power of richer languages. Enhancing our ability to communicate thoughts clearly, with sophistication. Every generation made code a little more legible to the people writing it.
Machine code was binary. Ones and zeros. The machine understood it perfectly. Humans understood it barely, painfully, one bit at a time.
Assembly gave us mnemonics. MOV, ADD, JMP. Still close to the metal, but at least you could read the instructions without a reference sheet. A human could look at a block of assembly and, with effort, follow what was happening.
C gave us structure. Functions, variables with names, control flow that read top to bottom. You could write a complex program and another programmer could pick it up and understand it. Not easily, maybe, but reliably.
Then the higher-level languages arrived and the leap wasn’t just readability. It was expressiveness. Python, Ruby, JavaScript. These languages let you express wildly sophisticated constructs in a handful of lines. A list comprehension in Python replaces a dozen lines of C. A decorator wraps complex behavior in a single readable annotation. Advanced language constructs and rich syntax meant you could review something complex at a glance. The code didn’t just get easier to read. It got more powerful per line. You could hold more of the system in your head because the language was doing more of the work.
Each step up the ladder served the same purpose: make it easier for humans to write, read, and reason about what the machine is doing. The entire arc of programming language design has been a climb toward human legibility.
The top of the ladder
I think we’re standing at the top now. And the top is English. I say English because it’s what I speak, but the point applies to any human language. The top of the ladder is natural language itself.
CLAUDE.md files. Prompts. Natural language specifications. Descriptions of what you want, written in the same language you use to talk to a colleague. “Build a REST API that handles user authentication with JWT tokens and rate limiting.” That’s not pseudocode. That’s an instruction that produces working software.
English is the logical endpoint of the abstraction ladder. You can’t get more human-readable than human language. And English isn’t just readable. It’s syntactically richer than even the deepest programming language ever designed. We can invent new terms on the fly and they carry meaning immediately. We have cultural expressions, idioms, metaphor. We can write feelings literally. We can convey intent, priority, and nuance in a single sentence that would take dozens of lines of code to approximate with enums and config flags.
No programming language has ever come close to that expressiveness. Python is elegant, but it can’t say “make it feel snappy” or “this should work the way Stripe’s API works” or “prioritize clarity over performance except in the hot path.” English can. And increasingly, an AI agent can take that English and produce working software from it.
If you’d told a programmer in 1960 that one day the programming language would be English, they’d have said that’s science fiction. If you told them the year would be 2026, they might have believed you.
What happens after the top
Here’s where it gets interesting. Every step up the abstraction ladder existed because humans needed to read and maintain the code. Assembly was for humans. C was for humans. Python was for humans. The code got more readable because the human was always in the loop, writing it, reviewing it, debugging it, handing it off to the next developer.
But now the human writes English. The agent writes the code. And then, increasingly, another agent reviews it, tests it, modifies it, and maintains it.
So who is the code for?
If agents are the ones reading and maintaining the code below the English layer, there’s no evolutionary pressure for that code to stay legible to humans. For seventy years, readability was a survival trait. Unreadable code got rewritten or abandoned. But if the reader is an agent, readability means something completely different. The agent doesn’t care about elegant variable names. It doesn’t need comments explaining the business logic. It doesn’t benefit from the things that make code pleasant for a human to read.
For the first time in the history of programming, the trend toward human readability could reverse. Not because anyone decided to make code harder to read. But because the audience changed.
What agent-optimized code might look like
This isn’t a prediction. It’s an observation about pressures.
If agents are writing code for other agents to consume, the code will optimize for what agents need: token efficiency, patterns that are easy for models to parse and modify, structures that fit cleanly into context windows. Variable names might shorten, not because the agent is lazy, but because a compact representation is faster to process and carries the same information. Comments might disappear. The agent doesn’t need a reminder about why this function exists. It can infer that from context. Abstractions might shift toward whatever representation lets the next agent pick up the work fastest.
None of this is about making code worse. It’s about a different set of optimization pressures. Human-readable code optimizes for scannability, maintainability by people with varying levels of context, and the ability to onboard a new developer. Agent-readable code might optimize for entirely different things. Things we don’t even have names for yet, because we’ve never had to think about what makes code easy for a non-human to work with.
The result might look less like Python and more like something in between. A representation that’s too dense for a human to comfortably read but perfectly clear to an agent. Not machine code. Not source code as we know it.
The two layers
What I think emerges from this is a bifurcation. Two distinct layers of programming that coexist but serve completely different audiences.
The human layer is English. Prompts, specifications, CLAUDE.md files, natural language descriptions of intent and constraints. This is where developers work. This is where architecture decisions live, where business logic gets defined, where “what should this system do and why” gets articulated. English is where humans are most expressive, most precise in the ways that matter to them: intent, nuance, priority, tradeoff.
The machine layer is whatever the agents produce underneath. Today that’s Python, TypeScript, Go. Languages designed for humans that agents happen to write. But if English can reliably compile all the way down to working software, then every layer between English and the machine code is arguably just an extra step. Python is an intermediary. A useful one, for now. But an intermediary.
Maybe those intermediate layers evolve into something more meaningful. Not source code in the way we think of it today, but something new. A representation that still gives humans peace of mind, that can be somewhat deterministically verified as correct or incorrect, that we can audit and reason about when we need to. But it probably doesn’t look like the code we write today. It might be more like a proof than a program. More like a contract than an implementation. Something that says “this is what the system does and here is why it’s correct” without requiring you to read every line of the implementation to believe it.
Developers don’t read assembly today. Most never have. And yet they trust that their Python compiles to something correct because the layers between them are reliable. The same thing might happen one level up. You write English. Something you can verify sits in the middle. Machine code runs at the bottom. And the layer we spent seventy years making readable becomes the layer nobody reads. Not because it’s gone, but because it’s no longer where the work happens.
The view from the top
We climbed the abstraction ladder for seventy years. Machine code to assembly to C to Python to English. Each step made software more accessible to humans. More readable, more expressive, more powerful per line.
English might be the last rung. Not because we’ll stop improving how we build software, but because you can’t make a programming language more human-readable than human language. The ladder doesn’t go higher. It just… levels off.
What happens below that layer is one of the most interesting open questions in software right now. What the agents write, how they optimize it, whether it stays legible to us. The answer will shape what it means to be a developer in ten years. Whether “understanding your system” means reading the code, reading the spec, or reading something that doesn’t exist yet.
It’ll be exciting to see how this evolves.