Daniel's been turning over the long view on programming. His prompt goes something like this. We've passed the inflection point where machines write code as well as humans, probably better. The entire human programming era, measured against history, is half a blink of an eye. So the long arc might be: humans tinkered with controlling hardware, then very quickly handed the keys to machines. And if that's the frame, he wants to know why we created all these languages in the first place. Is the plurality just humans disagreeing about things history will regard as trivial? Will the AI coding era make that plurality a relic? Could everything converge on one unified language? Is rationalization inevitable? And how does programming actually evolve from here?
That's a lot of questions, and they're all the right ones. Let's start with the uncomfortable one. Why did we need all these languages in the first place?
Because we couldn't agree on anything and we liked it that way.
There's more to it than that. The New York Times Magazine ran a piece back in March that framed this as a genuine inflection point. Machines are now arguably better at writing code than humans. Not faster, not cheaper. Better. And once you accept that premise, you have to re-examine everything. Why did we build the tower of Babel? What was it for?
The usual answer is that different languages are good at different things. Python for data, C for systems, JavaScript for the browser. But that's the polite answer.
It's the answer that assumes languages were designed for technical efficiency. They weren't. They were designed for human cognitive ergonomics. COBOL was created in nineteen fifty-nine because the Department of Defense wanted a language that read like business English, so managers could understand what the programmers were doing. FORTRAN came out of IBM in the mid-fifties because John Backus wanted mathematicians to write code that looked like their formulas. Lisp was John McCarthy's attempt to formalize symbolic reasoning on paper, and the implementation in code came almost as an afterthought.
So each language was a theory about what humans needed to think clearly about computation.
And the theories differed because the humans differed. A mathematician and a business analyst and an AI researcher do not think the same way. The language was the bridge between their cognition and the machine.
Which is why the plurality isn't trivial disagreement. It's not like we had one perfect language and then a bunch of people got grumpy about syntax.
Well, some of it was grumpiness about syntax. But the deeper driver was that languages are tools for human thought, and humans think differently. Static versus dynamic typing isn't a petty squabble. It's a genuine philosophical dispute about whether you want the machine to catch your mistakes before the program runs or whether you want the flexibility to discover the shape of your data as you go. Compiled versus interpreted. Object-oriented versus functional. These are real cognitive models.
And then the economic layer piled on top. Once a language had a library ecosystem and a talent pool and corporate investment, it became a moat.
Python's dominance in AI is the textbook case. It's not the fastest language. It's not the most elegant. But the ecosystem accreted around it. NumPy, TensorFlow, PyTorch. If you wanted to do machine learning in twenty twenty, you used Python because that's where the tools were, and the tools were there because everyone used Python.
A self-reinforcing loop that had nothing to do with the language's technical merits.
Right. And this is where the AI coding inflection point changes the calculus. Because all of those reasons, the cognitive ergonomics, the philosophical disputes, the ecosystem moats, they all assume a human is reading and writing the code.
So what happens when the reader is no longer human?
That's the question. And the key data point, for me, is something Anders Hejlsberg said in January. Hejlsberg designed TypeScript. He's been thinking about programming languages for decades. And his take on AI coding was...
He called it a big regurgitator of stuff someone has done.
A big regurgitator. And that reframes everything. If AI learns from existing code, then the training corpus is the real substrate. The languages are just surface texture.
Say more about that. The training corpus being the substrate.
When an AI model writes Python, it's not thinking in Python. It's predicting tokens. It has seen billions of lines of Python in its training data, so it knows that after def and a function name and a colon, the next line is probably indented and starts with some operation. But that's pattern completion, not understanding. The language is an input-output format. It's not a cognitive medium for the machine the way it is for a human.
So the AI doesn't care whether it's writing Python or TypeScript or COBOL. It cares what's in the training data.
It cares about the statistical distribution of tokens. And that's the fundamental shift. For a human programmer, the language shapes how you think about the problem. A Lisp programmer sees recursion everywhere. A Java programmer sees objects and inheritance hierarchies. The language is a lens. For the AI, there is no lens. There's just the next token.
Which makes the plurality question urgent in a way it wasn't before. If the AI doesn't need the cognitive support that languages provide, why maintain all of them?
That's the rationalization argument. If AI is the primary code writer, the human-cognitive reasons for language plurality evaporate. What remains is the training corpus constraint and the execution environment. The AI is good at what it's seen, so switching costs are real but they're not cognitive. They're statistical. And languages map to runtimes. That's a hardware and performance question, not a human-readability question.
So we could end up with one language not because it's best for humans but because it's the most efficient token space for the models.
The New York Times piece noted something interesting here. AI coding assistants are already converging on a kind of model-native style. It's not quite any existing language. It's the thing the model reaches for when you don't constrain it. And if you look at what Code with Claude produces, which the MIT Technology Review covered in May, you see this in practice.
What did that demo actually show?
Anthropic's Code with Claude handles multi-file coding tasks end-to-end. You give it a prompt, it plans the changes, it writes the code across multiple files, it runs the tests, it iterates. The human writes a prompt, the AI writes the code. And here's the thing. The language choice becomes an implementation detail. The human doesn't say use Python or use TypeScript. The AI picks whatever fits the task, or whatever it's most confident in, or honestly, whatever it's seen the most of.
So the language is already disappearing from the human interface.
It's dropping below the level of human concern. Which is exactly what you'd expect if the long view Daniel's proposing is right. The human programming era as a brief transition between hardware control and AI control.
Half a blink of an eye.
And in that view, programming languages are like Latin. Once the universal medium of scholarship, now a niche for specialists. The question isn't whether plurality survives. It's whether any human language survives as more than a legacy artifact.
Hold on. There's a counter-pressure here that we're skating past. Hejlsberg's point cuts both ways.
The training data problem.
If AI regurgitates what humans wrote, then human-written code is the fuel. A unified language would freeze the corpus. The diversity of languages is what gives AI models their breadth.
And it's the strongest argument against rationalization. If every AI model were trained only on code written in one language, the models would be narrower. They'd have seen fewer patterns, fewer problem-solving approaches, fewer edge cases. Plurality might be a feature for model training, not a bug.
So we're caught between two forces. The AI doesn't need language diversity for its own cognition, but it does need diversity in its training data to be any good.
Which suggests a middle path. What actually emerges is probably not one language. It's a lingua franca for AI-to-AI communication, with human-facing languages persisting as a thin compatibility layer.
The AI writes in whatever it wants internally, and we get a translation.
Code with Claude already works this way. The human writes a prompt. The AI writes the code. The human never sees the intermediate representation, if there even is one. The language choice is an implementation detail. And if that's the template for the AI-first era, then the plurality of human languages becomes something like... you know when you look at a modern web application and there are fifteen different languages involved, but the user just sees a button?
The user doesn't know or care that the button was rendered by JavaScript calling a Python API that queries a database written in C.
The languages are still there, but they've become infrastructure. They're not the thing you think in anymore.
So the rationalization isn't that we pick one language and kill the rest. It's that the languages stop mattering.
They stop being the interface. And that's a bigger shift than consolidation. Consolidation would mean we all agree to use Rust or something. This is the languages becoming invisible.
Like how most people don't know what language their phone's operating system is written in.
And they shouldn't have to. That's the point. Programming languages were always a compromise. They let humans express intent in a way machines could execute. But the compromise was never elegant. It was always a translation layer between human thought and silicon.
And now we're adding another translation layer on top. Human thought to prompt to AI to code to execution.
Which is absurdly inefficient if you think about it in terms of steps, but it works because the AI handles the middle steps in milliseconds.
Let me push on something. You said the AI doesn't think in Python. It predicts tokens. But that's true of everything the AI does. It doesn't think in English either. It still produces English that's coherent and useful. So the fact that it doesn't think in Python doesn't mean Python is irrelevant.
That's fair. The language matters for output quality. If you ask an AI to write a poem, the language you ask in shapes the poem. If you ask it to write code, the language you ask for shapes the code. But the difference is that with code, the output is going to be read by another machine.
The compiler or interpreter.
Right. And the AI could, in principle, output directly to bytecode or machine code. It doesn't need the human-readable intermediate step. The only reason it outputs Python is that Python is what's in the training data and Python is what the existing toolchain expects.
So if we rebuilt the toolchain from scratch, assuming AI as the primary code writer, we might not include human-readable languages at all.
We might not. The NYT piece gestured at this. The model-native style that's emerging isn't quite any existing language. It's the thing the model reaches for when it's optimizing for correctness and efficiency rather than human readability. Give that another five years and it might look like something no human would willingly write.
A language that's optimized for token prediction efficiency rather than human cognition.
And that's where Daniel's long view really lands. The human programming era produced this extraordinary flowering of languages. Hundreds of them. Each one a different idea about how humans should think about computation. And if the AI era makes all of that a legacy layer, then the languages become fossils. Not dead, exactly. Still running in production. Still maintained. But no longer the place where the thinking happens.
The fossils of a cognitive age.
The age was what, seventy years? From FORTRAN in the fifties to Code with Claude in twenty twenty-six. Seventy years is half a blink of an eye in the course of human history.
Which makes you wonder what we'll think of as programming in another seventy years.
Probably something closer to specification. You describe what you want the system to do, in natural language, with constraints and examples, and the system figures out the implementation. The implementation language is an internal detail you never see.
We're already most of the way there. The prompt is the specification.
And the code is the compiled output. It's just that the compiler is a large language model instead of a deterministic program.
Which is unsettling if you think about it too long. A compiler that might hallucinate.
Well, traditional compilers have bugs too. They're just deterministic bugs. The difference with AI is that the bugs are stochastic and harder to reproduce.
That's supposed to be reassuring?
It's not. It's just the reality. But the trend line is clear. AI code generation is getting better and more reliable. The MIT Tech Review piece showed Code with Claude handling multi-file refactors that would take a human engineer hours. And it did them in minutes, with test coverage, with documentation. That's not a party trick. That's a shift in what programming means as an activity.
So where does that leave the human programmer? The one who still thinks in Python or Rust or whatever?
I think my old take holds up here. Conceptual knowledge becomes more valuable as AI-generated code becomes common, not less. Knowing what to build, knowing why to build it, knowing how to verify that what was built is correct. Those are the skills that matter when the typing is done by a machine.
The architect versus the bricklayer.
More like the editor versus the writer. The AI writes the draft. The human reviews it, refines the specification, catches the edge cases, makes the judgment calls. The language the AI wrote in is almost incidental.
Unless something goes wrong and you need to debug it.
That's the wrinkle. Debugging AI-generated code in a language you don't know is a nightmare. So there's still pressure to keep the languages human-readable and familiar. At least for now.
At least for now.
It is. Because the timeline is the hardest thing to predict. How fast does the model-native style diverge from human-readable languages? How fast do the toolchains adapt? How fast do organizations decide they don't need their code to be human-readable because the AI maintains it?
The last one is the big one. Organizations have decades of code written in human languages. COBOL is still running major financial systems. That doesn't go away just because the new stuff is AI-generated.
No, but it becomes a legacy maintenance problem. And legacy maintenance is expensive and boring, which means organizations will pay to have AI handle it. And if the AI is handling it, the pressure to keep it in COBOL rather than translating it to something the AI prefers...
The AI translates it.
And then the human-readable COBOL is gone. Replaced by whatever the AI finds more efficient. And nobody notices because the system still works.
Until it doesn't.
Until it doesn't. And then you need a human who understands the AI's internal representation. Which might be nobody.
That's the nightmare scenario.
That's the scenario that keeps senior engineers up at night. But it's also the scenario that the market will probably sleepwalk into because the cost savings are enormous and the risk is diffuse and long-term.
Alright. Let's pull back to Daniel's questions directly. Will the plurality of languages continue to serve a useful purpose?
In the short term, yes, because the training data requires it and the existing toolchain expects it. In the long term, the plurality stops mattering because the languages become infrastructure rather than interfaces. They're still there, but humans don't interact with them directly.
Could all programming be done in one unified language?
Could it? Yes. Will it? Probably not, because the training corpus is diverse and the models are trained on that diversity. A unified language would require a deliberate effort to converge, and the incentives aren't aligned for that. What's more likely is that a de facto standard emerges from whatever the models are most fluent in, and everything else becomes a legacy translation problem.
Is rationalization inevitable?
Rationalization in the sense of fewer languages that humans actively write? Yes. Rationalization in the sense of one language to rule them all? No. The middle path is more plausible. A handful of languages persist as human interfaces, and underneath them is a much more fluid AI-native layer that humans never see.
And how does programming evolve from here?
The activity of programming becomes specification and verification. You describe what you want, you verify that what you got is correct, you handle the exceptions and edge cases. The typing, the syntax, the language choice. All of that becomes an implementation detail handled by the AI. Programming becomes a management task rather than a craft task.
Which is either liberating or terrifying depending on why you got into programming in the first place.
If you got into programming because you love the craft of writing elegant code, this is a hard moment. If you got into it because you love building things that work, this is the best moment in history.
I suspect most people are somewhere in between.
Most people are. And they'll adapt. Humans are good at adapting. The programmers I worry about are the ones who've spent twenty years mastering a specific language and framework and now find that the AI can do in thirty seconds what they do in a day.
That's a real displacement.
It's already happening. The MIT Tech Review piece was clear about that. The demo wasn't a toy. It was multi-file refactors with test coverage. That's real engineering work. And it's only going to get more capable.
So we're in the half-blink transition. The moment where the keys are being handed over.
And the question is whether we hand them over deliberately or just wake up one day and realize the handover already happened.
That's a cheerful thought.
It's an honest one.
Hilbert, you've been making a face for the last ten minutes. What's that mug?
Hilbert: It's from a company called DataBridge. Went under in two thousand one.
DataBridge. I don't know that name.
Hilbert: Nobody does. We built a translation layer between COBOL and a proprietary language called DataFlow. Two companies merged, neither wanted to give up their codebase, so someone had to write the bridge by hand. I was the someone. Eighteen months of my life.
You were a programmer?
Hilbert: Language localizer. Different thing. I didn't write new code. I mapped one language onto another, line by line, making sure the behavior matched. COBOL on one side, DataFlow on the other. The translation layer was called the Rosetta Stone internally. This was the swag.
You kept the mug.
Hilbert: I kept the mug. The point is, rationalization already happened once. In the nineties, the industry consolidated from hundreds of languages to a handful. My job disappeared not because one language won. It disappeared because the market stopped caring about the differences.
The languages didn't merge.
Hilbert: They didn't merge. They just stopped mattering. Companies picked Java or C plus plus or whatever and the rest became legacy. Nobody sat down and designed a unified language. The market just moved on.
So you're saying we're overthinking this.
Hilbert: I'm saying you're describing the same thing that already happened, just with a different mechanism. Last time it was market consolidation. This time it's AI. The result is the same. The languages don't disappear. They become someone else's problem.
The Rosetta Stone. That's a good name for a translation layer.
Hilbert: It was a good name. The code was terrible. We had forty thousand lines of mapping rules, half of them wrong, and a test suite that passed because the tests were written against the mapping rules, not against the actual business logic. I still think about that sometimes.
What happened to DataFlow?
Hilbert: Nobody remembers DataFlow. That's the point. It was a real language. Thousands of companies used it. Now it's a footnote. The AI era's unified language will be someone's DataFlow. An abandoned project that the training data happened to include.
That's a remarkably specific prediction.
Hilbert: It's not a prediction. It's a pattern. The thing that wins is never the thing people expect. It's the thing that was lying around when the switch flipped.
Do you still have the mapping rules?
Hilbert: Somewhere. In a box. Probably on a hard drive that doesn't spin up anymore.
That's a museum piece.
Hilbert: It's garbage. But it's interesting garbage. The thing I learned from eighteen months of mapping COBOL to DataFlow is that the differences between languages are mostly cosmetic. The hard stuff, the business logic, the edge cases, the assumptions about what the data means. That's the same in every language. The syntax is just the wrapper.
Which is exactly the point you two have been making for the last twenty minutes.
Hilbert: It is. I've been waiting to say that.
You could have jumped in earlier.
Hilbert: I was enjoying the conversation. And I wanted to see if you'd get there. You got there.
The languages are surface texture.
Hilbert: Always were. The AI just makes it obvious.
That's a hell of a detail to end on. Let's zoom back out.
The open question, I think, is what happens to the human programmers who still think in these languages. If human languages become a legacy layer, the people who are fluent in them become legacy specialists. That's a viable career for a while. Legacy COBOL programmers made good money for decades. But it's not a growing field.
And the next inflection point might not be language unification at all. It might be the emergence of a genuinely new formalism. Something model-native that no human reads fluently. Something that's optimized for the way AI models represent and manipulate code internally. We don't have a name for that yet, but the NYT piece saw the early signs of it.
The blink-of-an-eye image sticks with me. The human programming era as a brief transition. Seventy years of humans writing code, and then the machines take over, and the languages we built become fossils of a cognitive age. Not dead, not useless, but no longer where the thinking happens.
And the thinking moves up a level. To specification, to verification, to judgment. The things humans are still better at. For now.
For now.
Thanks to Hilbert Flumingtop for producing, and for the coffee mug archaeology.
This has been My Weird Prompts. If you want to send us your own weird prompt, email the show at show at my weird prompts dot com.
We'll be back soon.
