The End of Software

What happens when building dissolves as a category

Before the printing press, if you needed a written document, you hired a scribe. Scribes were skilled professionals. They trained for years. They had guilds, standards, career ladders. The good ones were well-compensated. An entire economic structure existed around the simple fact that producing written text was difficult and specialized.

Then literacy became common, and the scribe as a profession vanished. Not because writing disappeared—writing exploded. There is infinitely more written text in the world now than when scribes were a profession. What disappeared was the economic structure around the difficulty of producing it. The monasteries, the apprenticeships, the guilds, the professional class. All of it was scaffolding for a scarce skill. The skill became universal and the scaffolding collapsed.

Software is about to go through the same transition.

The current discourse about AI and software development makes an error that seems obvious in retrospect but is nearly invisible in the moment: it assumes that the shape of the industry is preserved while the productivity improves. "AI-augmented developers." "10x engineers." "PMs who can prompt." Every prediction keeps the roles intact and just changes the throughput.

This is like predicting the printing press would create "10x scribes." It misses the phase transition entirely. The press didn't make scribes faster. It made the concept of a scribe unnecessary.

Here's what the trend line actually says, if you don't flinch from extrapolating it. Six months ago, building a vertical SaaS required a team of engineers, a product manager, and a sprint cadence. Today, a single developer directing Claude Code can do the same work. Six months from now, someone who can clearly describe what they want will be able to produce the same thing without writing a line of code. Not a prototype. Not an MVP. A working product, shaped to their exact needs.

At that point, the person with the need and the person with the software are the same person. The intermediary layer—the entire professional class that existed to translate human needs into working software—has nothing left to mediate.

I've been building software this way for over a decade, though I didn't have language for it until recently. CaliforniaBirthIndex.org was built in a week. FreeRomanceBooks.org was built in an evening. A dozen other sites the same way: I had an idea, I built the thing, it either worked or it didn't. No roadmap, no sprint plan, no prioritization framework. Just taste meeting execution directly.

I could work this way because for me, execution was cheap. Fast hands plus deep fluency meant the cost of building something was low enough that I didn't need any of the organizational infrastructure other teams required. I was, in retrospect, vibe coding before there was a word for it.

But here's what I missed until this week: my model is also transitional. I still operate as a builder. I still read code, make architectural choices, tweak output, deploy to servers. The gap between intent and artifact is small for me, but it's still there. I still translate.

The trend line doesn't stop at "everyone can build like Patrick." It goes past me. It goes to the point where "builder" isn't a thing you are, the same way "literate" isn't a thing you are—it's so universal it stops being an identity. The gap between having a need and having the software closes completely. Not for me, not for developers, but for everyone.

The objection I hear most is: "Most people aren't builders. They don't want to create their own software. They want to buy a product that works."

This objection makes sense right now because right now, creating software still feels like building. Even vibe coding requires sitting in front of a tool, iterating, making decisions about implementation. People correctly look at that and say "most people won't do this." But they're wrong about the implication, because they're assuming the interaction stays that way.

It won't. The experience of creating software is converging toward the experience of asking for something. Not "build me a process serving management tool"—that still sounds like a software project. More like: "I need to keep track of which courts I've filed with and when the deadlines are." That's not a software prompt. That's a person describing a need. The fact that the response is a working application rather than a spreadsheet or a sticky note is incidental.

"Most people aren't builders" is true in 2026 the way "most people aren't writers" was true in 1400. It's a description of a temporary constraint, not a permanent feature of human capability. The constraint was never ability. It was the cost of the tools.

Consider what this means for the software industry as it currently exists.

There are roughly 4.4 million software developers in the United States. The vast majority of them are building and maintaining what amounts to custom CRUD applications—business logic, dashboards, forms, reports, data pipelines. Useful but not novel. The digital equivalent of manuscript copying: taking requirements (one form of text) and translating them into code (another form of text).

This work is valuable precisely because it is difficult. The $200k salary, the months-long hiring process, the bootcamps and the CS degrees—all of it reflects the scarcity of people who can do the translation reliably. Remove the difficulty and you remove the scarcity. Remove the scarcity and you remove the economic structure built around it.

The job boards. The recruiting industry. The bootcamps. The FAANG career ladder. The technical interview complex. The conference circuit. The certification programs. The Agile consultancies. The entire ecosystem exists because turning human needs into working software required a professional class of translators. That's the monastery. And the printing press is already in the building.

The transition is already visible if you know where to look.

I keep hearing the same story from staff engineers at mid-size software companies: their junior developers have negative value. Not underperforming—negative. The juniors require management and hand-holding to produce work that's worse than what the senior engineer can get from Claude Code nearly unattended. The entry-level role—the first rung of the entire professional ladder—is collapsing first.

But the logic doesn't stop at juniors. If AI output is better than junior output today, it'll be better than mid-level output soon, and better than senior output after that. The staff engineer directing AI is a transitional role, the same way the head scribe overseeing a team of monks was transitional after the printing press arrived. You still needed someone who understood the craft—for a while. Then you didn't.

The people I know who are most clear-eyed about this are the best engineers. They can see what AI can do today. They can plot the curve. They know where it goes. The people in denial are the ones whose identity is most wrapped up in the craft—who experience writing code the way a calligrapher experiences lettering. The work is genuinely beautiful. It's also genuinely doomed as an economic activity.

So what survives?

Infrastructure. Someone still needs to build and operate the substrate: the cloud platforms, the AI models, the networking fabric, the database engines. You're not generating your own Cloudflare from a prompt. This is real engineering and it persists. But it's a tiny fraction of current software employment—the difference between "people who build printing presses" and "people who copy manuscripts."

Network-effect platforms. The value of a social network or a marketplace is the other people on it. You can generate your own Twitter clone, but it's worthless without the network. These survive as businesses, though the software that runs them gets radically cheaper to build and maintain.

Ongoing intelligence. As I argued in More Software, Fewer Software Businesses, the unit of value is shifting from static code to dynamic reasoning—AI that thinks continuously, not software that was built once and sits there. This is genuinely new and doesn't reduce to the old model. But it's not "software" in the way the industry currently means it. It's something else.

Everything below that line—every CRUD app, every dashboard, every vertical SaaS, every "form plus database plus business logic" tool, every reporting system, every internal workflow application—is the manuscript. There will be more of it than ever. It just won't be a product anyone sells, because the people who need it can conjure it from a description.

I want to be precise about what I'm claiming. I'm not saying software disappears. Software explodes. Every person will have software tailored to their specific needs, the way every person now has documents tailored to their specific communications. There will be orders of magnitude more software in the world.

What disappears is the industry of producing it for other people. The professional class, the product companies, the organizational apparatus. The $600 billion that enterprises spend annually on software development. Not because the software isn't needed anymore, but because the cost of producing it falls so far that it no longer supports an industry.

This has happened before. Farming used to employ 90% of the population. Now it employs 2% and produces more food than ever. The food didn't disappear. The jobs disappeared. The output exploded while the employment collapsed, because technology made the per-unit cost of production negligible.

Software is food. Not the metaphor people usually reach for, but the accurate one. Essential, ubiquitous, produced in unimaginable quantities—and requiring almost no one to make it.

I notice that even writing this essay, I want to hedge. I want to say "of course some software engineering roles will persist" and "the transition will take longer than people think" and "there will always be a need for people who truly understand systems." And those hedges might be true in the short term. But they're the same hedges scribes would have made in 1460. "Surely there will always be a need for people who can write a truly beautiful manuscript." Yes. In museums.

The people reading this who write software for a living are going to have one of two reactions. Some will feel the truth of it in their gut—they've been watching the trend, they've seen what Claude Code can do, they've done the extrapolation themselves and arrived at the same place. Others will list reasons it won't happen: AI can't handle complex systems, it doesn't truly understand, it makes mistakes, it can't do novel research. These objections are all true today. They are all becoming less true at a rate that should terrify anyone whose career depends on them remaining true.

The question isn't whether this happens. The trend line is too clear and the economic incentives are too strong. The question is whether it takes five years or fifteen. And in either case, the thing to do is the same: stop building an identity around the production of software and start building one around the things that remain durably human—taste, judgment, the ability to know what should exist. The creative act of seeing what's missing in the world.

The software was never the point. The point was always what the software was for.