Coding is over. But the specs still need to be written
Last week I had the privilege to join Henrik Føhns in a conversation (in Danish) about software agents in general, Open Claw, but also more specifically coding agents.
There's no question in my mind that the time when we write code in programming languages is ending. In that way we're on the cusp of the biggest revolution in computing in 50 years. Bigger than the mobile turn. Bigger than the internet - although of course completely dependent on the latter.
But as I sit and think about this and follow the conversation about this - I think there's something that a lot of people have completely backwards. As I listen to the general chatter I get the idea that people are misled by the quick vibe demos. When you sit down and quickly vibe something up - the first sensation is "whoa - I just had to do this and then the computer did all that!" which amplifies this core misunderstanding that the typical piece of software is extremely wordy and very long for what it does. The idea is this quick little nugget and then you have to do all this work to make it run inside the computer.
Nothing could be further from the truth.
Programs are short. Not long.
I'm a recovering mathematician... and one of the things you learn quickly in mathematics is that all of the abstruse notion is not some kind of crazy technical obstacle but actually an absolute necessity to be able to say anything interesting.
The notation is dense and lets us work in abstractions without which we would not be able to even state the claims that mathematicians are trying to prove.
A software program is a kind of mathematical notation and shares the same quality. Programs are short for what they do, not long.
Let me give you a worked example
Recently Drew Breunig had a puzzling idea. If software is free - the bots just write it on demand - then why publish software at all. So he published a new software library with no code at all. Just instructions for the bots on how to write the software. The library is 500 lines of specification and another 500 lines of tests.
As prep for writing this piece I pulled down the library and asked Claude to implement it. It did so in 250 lines of python. Yes. The code is A LOT shorter than the spec.
Bored of vibes
Recently my esteemed collague Toni Petrina shared an essay with the provocative title AI makes you boring - a reflection of sorts on all the quick vibe coding projects everyone's doing - and how super boring these low investment projects that we're flooded with, are. It's a super real risk - even in professional software development. If you let your work deteriorate to fast prompting with no feedback loop on quality the software will be bland, and more worryingly - so will you. But well run AI-driven development projects also don't work like that. Pre-AI construction the symbolic realization of the spec was super hard work - so you made sure you only had to do that once with extensive prep work. Post-AI construction is free so the workflow is different: You build a first quick version of the software based on an early or simplified version of the spec - and then you keep going and iterate, iterate, iterate in a process reminiscent of the Pixar story-building technique called plussing. You keep building on the system - refining and adding to the spec. As you do so the spec grows faster than the the code. When you're done the software captures a massive amount of ideas because you produced a massive amount of feedback during this work. The software wasn't free at all - you just paid for it with feedback and detailed specs and tests, not lines of code.
You basically went through an evolution like this
The software grew really quickly as all of the 'fixed costs' of software accrued rapidly. App setup. Structure. And you build a really quick germ of an idea. But then over time you kept writing, and writing, and writing and correcting and safeguarding and all of a sudden you'd written a spec the size of the software system.
The asymptotic relationship between specs and code
This leads us to Dahl's first law: The ratio of spec lines to code lines converges over time to a number higher than 1.
Code might be over. But software construction very much is not.