I was talking about this with my friend Jan, and he pointed out a few things I hadn’t noticed. But before we get to the point, let’s get our thoughts in order.
Over the past few decades, code has been a scarce resource — as I wrote in another post — and the software industry built an entire house of cards on top of that scarcity. Take the structure of commercial software: it’s generic, with customization options ranging from basic settings all the way to full-blown advanced customization. Entire languages were even developed inside applications — some visual, some not — to let end users write and implement their own specific features: the so-called DSLs (Domain Specific Languages).
The logic went something like this: building an application with a general-purpose programming language — C++, C#, Java, you name it — is expensive. So let’s build generic applications that can be modified in one precise direction, within precise boundaries, and give them languages with a syntax limited to that single purpose.
These advanced customization capabilities, in turn, created an entire market of consulting firms whose job is to navigate those customizations and help customers take a generic application and bolt on the missing piece. In practice, knowledge is split like this: a generic software product, built for a particular purpose, that defines the guidelines of the problem; the customer’s own knowledge of their problem and their context; and a consultant in the middle trying to bridge the two.
This model has plenty of implications, and most of us have seen it succeed and fail. But there’s one non-obvious aspect I want to surface: software maintenance. The more features you add and the more customers use the product, the harder maintenance gets — until adding new features becomes nearly impossible. Every change risks breaking a customization some customer added, one the vendor doesn’t even know about. How is a software vendor supposed to modify or update its product without breaking customizations it knows nothing about? The result: vendors have to charge more and more to add features to the generic product — features the end customer never asked for, and that threaten to hurt them with every release. And the customer knows it: any update that doesn’t include something they actually need can only break software that, for them, is working just fine.
So that’s where things stand today. But if you’ve made it this far, you already know where I’m going: what happens to this model when the cost of code approaches zero?
Some people object that the real cost of software was never the code itself — it’s figuring out what to build, verifying it, maintaining it. Fair enough. But I work in a large enterprise and I see the numbers every day: what used to take fifty people, one person does today. And that’s not a number I pulled out of thin air. Here’s the thing: the house of cards isn’t made of “the cost of software” in the abstract — it’s made of revenue tied to headcount. Staff augmentation, time-and-materials consulting, teams sold by the dozen. If the bottleneck shifts from “writing code” to “knowing what to ask for and verifying you got it,” it’s still a one-person bottleneck, not a fifty-person one. And you don’t build a consulting firm with thousands of employees on a one-person bottleneck.
Others will argue that when software gets cheaper, the world just demands more of it — economists call it the Jevons paradox — so the work won’t disappear. Maybe. But even then, that work will take a completely different shape, and the structure that sells headcount dies anyway. So yes, the house of cards falls. Just maybe not in the way you’d expect.
The end customer could, in theory, build a fully custom solution in-house, but that exposes them to two problems. First: their business isn’t software, so taking on a job that’s not theirs makes no business sense. Second: complete knowledge of the software they’re using is distributed across three players — the software vendor, the systems integrator, and the customer. On its own, the customer is a three-legged stool missing two legs.
And this isn’t just theory: someone has already run this experiment, with practically unlimited money. Banks. They bought entire software companies and put them to work building software for them. The result? Old, inefficient software and hundreds of people on the payroll. There’s a line attributed to Henry Ford: if I had asked people what they wanted, they would have said faster horses. Banks digitized the processes they already had instead of reimagining them: they’re full of lame faster horses, and I have yet to see an automobile. They dug their own hole; it’s just not obvious yet, because these things take time — and meanwhile, they have the money to paper over the problem. And notice: their failure wasn’t about the cost of code. It was a failure of thinking. Which means zero-cost code won’t save anyone from that mistake — it will just let you build your own disaster faster and cheaper. The lame faster horse of 2030 will be generated, not written.
So the real question is: how will these three players behave in the age of AI? Sure, there are cases where, because the software needs very little customization, only two players are involved — the vendor and the customer — but those scenarios are pretty interesting too. For a moment, though, let’s set them aside.
The customer is thinking: perfect, I can build my own software and worry about maintenance only when I need to — or cut it dramatically. Basically, Excel on steroids. And here I have to confess that after thirty years in software, I do have an answer on Excel’s balance sheet, and it isn’t kind: Excel solved small problems and created enormous ones. I’ve lost count of how many times someone has asked me to “turn this spreadsheet into a real application.” Behind that request there’s almost never a new need — there’s an attempt to hide a big failure: the failure to recognize where their own limits were. I know, we all have that one spreadsheet we’re attached to, the one that was genuinely useful — but that’s just our personal view. And I know this take won’t win me any friends, but much of this article’s argument rests on exactly this quirk of human nature.
There’s one crucial difference, though, between the old Excel and what’s coming. Whoever writes a spreadsheet, for better or worse, understands the formulas they wrote: their failure is organizational — growth without control. Someone who has AI generate their software, on the other hand, may not even understand the system they’re running. The new Excel inherits the old one’s vice and adds a worse one: total opacity. Nobody truly understands the artifact.
The software vendors, for their part, are starting to think: great, we’ll cut costs and earn more. If AI handles the customization, we won’t even need systems integrators anymore, and we can cut those long implementation cycles down to zero. But here, too, the challenge is big, because all that “bridge” knowledge — between a vendor used to thinking generically, at a high level, and the customers’ specific problems — is not easy to replace. Besides, when something becomes abundant, all sorts of distortions appear. I still remember the early 2000s, when building a website became something anyone could do: the result was that a page built by your nephew became indistinguishable from a major e-commerce site (okay, Amazon back then was a far cry from what it is today, but you get the idea). And that problem, twenty-plus years later, still isn’t solved.
The systems integrators, meanwhile, will start thinking they can do without the software vendors. But even in this case — which in theory sounds like the most feasible one — practice is a very different story. I won’t go into the details to keep this from getting tedious, but the considerations aren’t far from the ones above. I’d say we’re somewhere in the middle.
I’m sure there will be customers who manage to pull it off on their own — after all, a successful spreadsheet does exist here and there — and the same goes for the other two players. And there will be disasters: you don’t need to be Nostradamus to predict that, but it’s the price of every great change. Maybe the prophecy isn’t the point, though. The point is that code will stop being the scarce resource this world has organized itself around. Which raises the real question: what is the new scarcity? And which of the three players is positioned to own it?
Thank you, Jan Morath, for always inspiring me
Leave a Reply