The blog was quiet for a few weeks. I wasn't; at least not entirely. And of everything I read, built, and argued about over the summer, one idea kept pulling at me until I couldn't put it down. I want to think out loud about it here, before the new series starts, because it sits underneath everything that series will say.

Here's the provocation, stated as plainly as I can: in a few years, nobody will write software, and nobody will care about it. Not "less software," not "AI-assisted software." Software as the artifact we fuss over, the thing we hire around, protect, refactor, and treat as the crown jewels, is on its way out. It will be generated when needed and otherwise ignored, the way almost no one thinks about the assembly code their compiler generates.

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 summer 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 summer 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%. 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 "can AI 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, i.e. size, criticality, 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, i.e. 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 10%" is the last thing to fall, not the first. 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. That kind of quiet relocation, where a technology moves the ground under an entire discipline while everyone stares at the old center, is exactly what I want to spend the fall writing about.

So that's the turn. Starting next week I'm running a 14-part series, Machines That Think, on AI leaving the world of software and moving into the physical one, such as chips, robots, factories, grids, labs. The first post starts at the very bottom of the stack, with the compute substrate everything else depends on. The thread I've pulled on here, that the durable artifact is becoming contract-and-evaluation rather than code, will keep resurfacing throughout.

Jensen Huang put it more bluntly than I would: "It is our job to create computing technology such that nobody has to program, and that the programming language is human." He's selling the picks and shovels, so he would say that, but I think he's right. It’s good to be back! Tell me where I'm wrong!

Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com, LinkedIn (linkedin.com/in/janbosch) or X (@JanBosch).