The end of software,
again?

The crash and the shift
were different things.

The dot-com crash and the move to SaaS often get told as one story, but they weren’t. Markets wiped out a lot of tech jobs between 2001 and 2003; around the same time, software started reaching customers as a service instead of something you installed. The employment drop shows up clearly in the BLS numbers: U.S. computer systems design employment fell from about 1.30 million in 2001 to 1.12 million in 2003, then climbed to 1.53 million by 2011.²

EC2 arrived in 2006. The App Store followed in 2008.³⁴ They opened new ways to build and distribute products, well beyond running existing ones more cheaply.

My reading of that period is that those shifts made individual engineers much more effective, which is the same claim people make about AI now. You stopped racking your own servers, configuring machines by hand and writing every piece from scratch. Managed infrastructure and open source libraries meant a small team could ship what used to need a large one. That extra capacity mostly went into building more software rather than building the same software with fewer people. That doesn’t prove the same employment outcome will happen with AI. It does make me skeptical of treating today’s amount of software as a fixed quantity.

But “more software overall” hid real losses underneath. Once AWS made renting a server the default, most new companies never needed a data-center or hardware-ops hire. As the web and later JavaScript took over delivery, demand for classic desktop software engineers fell too. New kinds of work appeared, but that doesn’t mean the people who lost their jobs could easily move into them.

Customers don’t keep
the same expectations.

Imagine that building software becomes ten times more efficient. A company could use that to maintain the same product with fewer people. But a competitor could use it to make a product that previously made no economic sense. This is close to Jevons paradox: making something more efficient can increase total consumption of it rather than reduce it.⁹

Once people experience something better, the baseline moves. The bar rises toward better outcomes: software that fits their workflow, handles more of the boring work and feels much less frustrating to use.

The assumption I don’t buy is that we’ll use dramatically better tools to build exactly the same things.

The real question is how much more useful software people will want, and pay for, once the possibilities change, not just how fast we can produce it.

Once people get software that adapts to them and completes workflows instead of describing them, that becomes the new minimum, and companies built around AI will push it forward faster than incumbents can follow. Some will need fewer engineers for today’s backlog; others may need more people capable of building things that aren’t on any backlog yet.

AI could be a much bigger shift.

SaaS changed delivery. Cloud changed infrastructure. AI reaches directly into implementation, so I don’t think this is simply the same transition with a new name.

I think a strong engineer with product judgment can take on work that previously needed a team, especially when building something new. But a 10× speedup on a task is not a 10× speedup across an entire company. Reviewing decisions, securing systems and owning the result still count as work.

I wouldn’t put a universal number on it. Even METR’s February 2026 update explains why selection effects and parallel agents made its newer productivity estimates unreliable.⁵

The disruption is also not hypothetical for everyone. In February 2026, Block announced major job cuts and cited AI as part of its rationale.⁶ Many companies have reached for similar language since. I’d treat most of it carefully: plenty of these teams overhired during the pandemic, and AI is a convenient explanation for a correction that was already due. A stated reason tells you how a company wants to be read, not how much work AI actually replaced.

Learn to own more of the product.

The opportunity I see is getting better at understanding a problem, deciding what to build, giving agents useful context and checking whether the result actually works.

Product judgment, taste and a willingness to talk to customers are part of that work too. That only works when they have the agency to make decisions across that whole process.

That’s because code generation is getting cheap while verification isn’t. Simon Willison puts it simply: the job is no longer just to produce code, but to deliver code you’ve proven works.¹⁰ That means testing it, reviewing it and taking responsibility for the result. William Huster argues that verification can become the limiting cost as systems grow more interconnected.⁸ His proposed “verification complexity barrier” is a useful model for thinking about that risk: architecture and tests can ease the constraint, without making responsibility for correctness disappear.

A recent exchange between Miroslav Uďan and Honza Javorek captured this well. Miroslav wrote about building a production SaaS with Claude Code in five weeks despite not considering himself a programmer. Honza’s response was that the process Miroslav described (automated tests, monitoring, backups, security, APIs, versioning and careful rules for the agent) was software engineering, even if he wasn’t writing the code himself or calling it that. I think that distinction matters. AI can take over much of the implementation work, but you still need to understand the underlying principles to build reliable software.

I’d start with a small, real problem and take it through the whole process with AI: deciding what to build, implementing it, testing, reviewing and shipping it. Companies need to give people time to learn that process, rather than simply expecting the same work from a smaller team.

One concrete shift: the investment in advanced CI pipelines, thorough automated test suites, complex monitoring, documentation (now also through skills) or staged rollouts is becoming easier to justify on smaller teams. When an agent can generate a large diff in minutes, even a team of two or three needs a reliable way to check a lot of code before shipping it.

Build through it.

I don’t think the fear a lot of people feel about this is irrational. The dot-com-to-SaaS move and the cloud-and-mobile shift both grew the total amount of useful software work, even though neither felt that way partway through.

I build AI tools at Macaly, so I’m not a neutral observer.

My best guess is we’ll spend the next few years finding out just how much more software people actually want, and what new kinds of work emerge around it.