
Is software still the point?
Walk into any software company, or any software engineering department at a university, and you’ll find the same unspoken belief: The software is the point. It’s the boundary object, the thing everyone gathers around, the carrier of value, the deliverable that money and careers attach to. We argue about languages, architectures and code quality as if the code itself were the asset.
For fifty years, that was a reasonable assumption. Code was expensive to produce, so it was worth treating as precious. My question is whether that assumption has quietly stopped being true, and whether most of the industry simply hasn’t noticed yet.
In the 1980s and 90s, hand-written assembly gave way to high-level languages and optimizing compilers. Assembly code didn’t disappear; it’s still down there, executing. But it stopped being something humans wrote, read or valued. It became generated output: emitted when needed, trusted because the compiler was trusted and otherwise invisible. A whole category of craft, and of pride, evaporated in a generation.
My claim is that source code is now the assembly, and AI is the compiler. What we today call “writing software” is about to become what “writing assembly” became: an implementation detail, generated on demand, rarely inspected by a human.
I didn’t want this to stay a thought experiment, so I ran a real one. I sat down with Claude and, for one of the main products of a company I work with, we rebuilt a vertical slice of real functionality from scratch. In a bit over an hour, we had recreated a significant part of their primary product (more than ten percent of it) working.
Let that sit for a moment. More than ten percent of a company’s flagship product, in about an hour, by one person and an AI. That company’s entire self-image is still organized around its software and the hundreds of people who write and maintain it. Its org chart, its valuation story, its sense of what it is. All of it assumes the code is the hard, valuable, defensible part. The experiment made me wonder how much longer that assumption survives contact with reality.
I clearly wasn’t going to resolve this alone, so I spent a long hike arguing about it with a good friend. The whole way up and the whole way down. He pushed back hard, and the pushback is the interesting part. His point was essentially: Fine, a vertical slice in an hour, but that’s the easy 10 percent. Try regenerating the gnarly, load-bearing, safety-relevant, decade-old heart of a real system from scratch and see how far you get. He’s right that there’s a threshold somewhere. The question is where it is, and that turns out to be the whole game.
The crux isn’t whether AI can write code. It obviously can. The crux is: How large, how critical and how complex does a system have to be before it can no longer be reliably regenerated from scratch by an AI?
What struck me on the hike is that those three axes, ie size, criticality and complexity, don’t move together, and we tend to blur them. A large system can be simple and low-stakes. A tiny one can be fiendishly complex and safety-critical. Each axis pushes the regeneration threshold in a different way, and figuring out where the frontier actually sits on each is, I think, one of the genuinely open engineering questions of the next few years.
So, here’s where I’ve landed, at least for now. I think we’ll see a gradual migration in what the durable artifact even is. Away from code and toward what I’ve started calling contract-and-evaluation.
The contract is the intent: what the system should do, its interfaces, its quality attributes, the bounds it must stay within. The evaluation is the mechanism that continuously checks if the contract is being honored. Once an AI can satisfy a responsibility through code, a model call, an external service or an off-the-shelf component, the realization becomes fungible. A swappable implementation detail. What you keep, version, argue over and defend is no longer the code; it’s the contract and the evidence that it holds.
And this transition won’t arrive all at once. It’ll start where it’s safe, ie small, simple, low-stakes systems that are cheap to regenerate and easy to check, and creep upward toward the large, the complex and the critical. My friend’s “gnarly heart” is the last thing to fall. It may take a long time, but the direction, I’m increasingly convinced, is one-way.
If I’m right, then the thing our whole industry treats as the prize, the software, is quietly demoting itself to a byproduct, and value is relocating to intent and evidence.
