Everyone's convinced that AI has made code disposable. They've got it exactly backwards: for the first time, computers actually depend on it.
A few months ago I wrote a piece that mulled, with some sadness, over the fact that programming languages might be over. A dramatic sentiment, but one coming from a place of watching the onwards industrialisation of the production of software.
You see this thread everywhere – people talking about how software has changed, and how the programming part of the development process is rapidly losing importance in the face of verification. There's absolutely truth in the idea that writing code matters less to developers than it used to, but all it takes is a look around the average codebase to realise that most people never really cared about writing code anyway. If they did, the quality of software in the world probably wouldn't be as mediocre as it mostly is.
But I did. I really cared about writing code the whole time.
So there's a sadness for me in this, because programming is the most edifying, therapeutic part of the job. The mechanical pleasure of thinking and finding the form of expression that best fits the problem. It's probably no surprise to anybody that I feel that way; I've written countless essays and talks about how programming makes me feel. About how the process itself drives the self-improvement cycle you need to reach a good conclusion. But it's ok – everyone doesn't have to feel how I feel.
Over the last few months, as the frontier models have got better at writing above-average code, I've been having an increasing number of conversations with friends and peers, especially in the language design communities, lamenting that even the act of programming language design might be over. I had a stark conversation recently with a friend who is likely one of the ten most successful programming language designers ever, where they were seriously questioning whether their skills were valuable to the future of software. I've had conversations about how the "best language" now is simply the one with the most training data, the one most amenable to industrialisation. About how everything ends with JavaScript.
But recently I've come to the conclusion that code is probably just as important to the industry as it ever was – and that it's about to enter an era of severe underappreciation.
The weird thing to me about people not really caring about code is that code only ever existed for people.
It's easy to thoughtlessly assume that programming languages and code are made for machines. But machines never cared about code, or code quality, or the quality of expression in software.
To understand this, we have to answer two questions:
Code itself is a constrained form of communication that programmers use to describe their process (algorithms) and their mental model (structure) of a problem space. It's notation, in the same way that a map represents a space, or sheet music guides a musician.
Many people, even most programmers, would probably do a double-take at this definition, because experientially it seems like you "write code that runs on computers" – but this simply isn't true.
The code you write is compiled or interpreted by other programs that understand the representation a specific machine or piece of hardware needs. The machines themselves literally only care about machine code; the layers of abstraction, shape, and design we lay on top of them are stripped away until only opcodes and hardware remain.
The machines never cared about software design. It was all a map for them to get to the actual implementation they needed, and the map is not the territory.
The audience? That's the easier question. You are the audience for code.
Code is a constrained form of communication, between programmer and programmer, to transmit ideas in a form that we can best understand, maintain and modify in the future.
Sometimes you are the other programmer you're communicating with, just at a different place in time – but the code was always for people, and never for the machines.
If code was always only for people, and machines are now writing an increasing amount – bordering on the majority – of it, why do I think code suddenly has greater longevity than before? Computers finally depend on the code to reach new solutions.
Where previously humans did the heavy lifting of forming new solutions, representing them in code, and compiling them to something a computer understands, the code itself is now a load-bearing part of the software generation process.
Language models require exactly the same structures, designs and signposts in software that humans do, precisely because they were trained on codebases written by and for humans. Their statistical models expect the things that we expect, and those models are only high quality because of the vast amounts of human-provided data they were trained on.
For the magic trick to work, they need the same pre-conditions. This means that everything good language design and good software design reached for over the last three decades is more true than ever – that structures and syntax which elegantly express a problem space, that are easy to modify and extend, are also much easier for a model to make sense of.
The models share some of our constraints but not others – they are context sensitive, context constrained, and thrive on clear communication. The act of programming was always about elevating those particular signals.
When I've spoken to people about this comforting thought, they've often asked the obvious question: "what if a programming language comes along that's more appropriate for models?" This isn't inconceivable, but the models are precisely as good as they are because of the quantity of training data available to them.
Any "new model-centric language" effectively throws away three decades of training data for machine-generated speculation, and immediately shuts the door to trivial human oversight – which I'm not sure is a good trade-off given how good the models already are at working with our existing languages. There's simply no point anchoring to a lower level of abstraction (which really is just assembly language) when higher-order ones become more information dense.
Almost by chance, we've arrived at a place where the only thing that makes models good at programming at all is that they're trained on a huge corpus of information designed for human consumption – to work around the limitations of human memory, another characteristic we share with the models themselves.
You can see this play out in real time with your favourite model today. If you don't guide the kind of designs you're doing and engage in pure vibe coding, the resulting systems quickly spiral into unmaintainable mulch, while talented programmers driving the models can produce work that looks human-authored, and that can continue to be co-evolved into information-dense representations of solutions.
You wouldn't vibe code a life support machine, but you'd use AI to take some of the grunt work out of your design process.
The other place I think traditional deterministic techniques and programming languages are evergreen is in the verification and testing of software – precisely the place where people will be tempted to move fast and loose, because historically it's the lowest-quality corner of all of engineering: QA.
There's plenty of conversation at the moment about using natural language to verify the behaviour of systems, because this stuff almost always works. Somewhat controversially, when we're dealing with an increasing amount of non-determinism in software, I believe that almost always working isn't enough.
I'd much rather have an entirely vibe coded implementation coupled with a traditionally programmed set of verification tests than a bunch of markdown spec files.
We've seen this dream before in the BDD community with Gherkin, and the idea that non-technical people would specify, in human language, the expected behaviours of a system. Gherkin was always a failure, because it relied on a lossy translation back to executable software. The human language was never the actual code that executed; we still used a programmer to translate intent into code that verified something – and at worst, this became a place where bugs in verification could trivially hide.
We shouldn't replicate the failure of Gherkin, this time by letting a statistical model rarely but occasionally make the same mistakes.
Allowing the big non-determinism machine to be the driver of verification is a mistake. Instead we should prefer using the models to generate deterministic tests that ground them in repeatability.
Anything that always has to be right shouldn't be vibes.
At the recent ThoughtWorks Future of Software Engineering retreat there was a lot of conversation about "the organisational knowledge fabric". I'm not sure whether that term will stick, but it represented an emerging idea that there's a corpus of organisational knowledge that needs curating for models to process most effectively.
It exists somewhere between a corporate wiki, structured data, and programming, and possibly needs a new job role to curate, freshen, and maintain it – some kind of corporate-librarian role.
But the more I think about it, perhaps it's all just still code anyway?
While we could invent a new form of semi-structured documentation that's more trivially authored by laypeople to capture intent, I think we probably already have those things. It's markdown.
And the rest is software, in programming languages that still need to get better.
Because finding new ways to contain the ideas we capture to describe the behaviour of systems stays important for as long as we want humans to operate those systems.
Programming is dead. Long live programming.