The Software Apocalypse That Isn't
As Usual, We Believe That AI Agents and SaaS are in a Zero Sum Game. This Investor Behavior Really Foreshadows the Coming AI Bubble, Doesn't It?
Let me tell you something about apocalypses. They're terrific for selling newspapers. They're less terrific at predicting the future.
Right now, there’s a fever running through Sand Hill Road and the analyst desks of every major bank. The thesis goes like this: agentic coding can build software applications in microseconds, therefore no enterprise customer will ever buy a SaaS subscription again, therefore every SaaS company is dead, therefore sell everything, therefore the sky is falling. It’s a neat little syllogism. It’s also wrong. Not entirely wrong — which is what makes it dangerous — but wrong in the ways that matter.
Let’s walk and talk.
The Part They’re Getting Right
Here’s what I’ll stipulate, because I’m not in the business of pretending disruption isn’t happening while it’s kicking down the front door: highly commoditized layers of the software stack are going to get obliterated.
User experiences. REST APIs. Microservices. Metrics dashboards. Platform plumbing that is functionally identical across every professional SaaS application on the planet.
If your entire value proposition is “we wired together the same components everyone else has, but we did it first and we charge you monthly for the privilege” — yeah. You should be nervous.
You should have been nervous two years ago.
Agentic coding is going to do to commodity software what Visual Basic did to manual systems programming: except probably compress it by two more orders of magnitude.
More software is coming. Dramatically more. And the barrier to creating it just dropped through the floor.
If you’re in the business of hiring hundreds of low-cost engineers to maintain a legacy COBOL service, watch out (cough, a few firms come to mind).
In fact, I would like to remind you of the Garage Band article I wrote a while ago, where I (correctly!) noted that agentic coding doesn’t mean software is dead. Quite contrary, it means we are going to have a deluge of software. Just like we have a deluge of professionally created and recorded music!
A startup, a professional services firm, or even an internal team with a competent engineer and an agentic coding setup can now produce a working application in a timeframe that would have been absurd eighteen months ago. That’s real. That’s happening. I see it every day.
So if you’re a product manager and your roadmap is basically “more CRUD screens and another dashboard,” this is your wake-up call.
The phone is ringing. Pick it up.
The Part They’re Getting Wrong
Now here’s where the “end of SaaS” crowd loses the plot, and they lose it badly.
Every time I get genuinely wowed by a reasoning model — and I do, regularly — I also encounter another benchmark, internal or external, that reminds me what we’re actually dealing with: a spectacularly sophisticated guessing game. With backspace. The model generates, evaluates, recurses, and refines. It’s remarkable. It is also fundamentally limited.
Agentic coding systems excel when they can measure success against a specific target. Did I fix the bug? Did the test pass? Did the quality metric improve? They guess, they evaluate the guess, they guess again — burning reasoning tokens until they defeat the target. That’s genuinely powerful for well-defined problems.
But hand one of these systems genuine ambiguity? Watch what happens. Hand it a multi-repository codebase where the bug lives in the interaction between three services, two of which have undocumented side effects? Watch it flail. It’ll do what a smart but inexperienced engineer does: it’ll hack at the symptoms with tremendous energy and zero architectural insight.
I experienced this firsthand. I spent months struggling with a set of ambiguous bugs in a service. My coding agent attacked the problem with admirable enthusiasm — like a recent college grad who doesn’t know what they don’t know. It never once suggested what turned out to be the actual solution: building a new compiler. An abstraction layer that resolved the class of problems entirely.
I built that compiler myself, and — if I may say so — it’s proven to be a rather elegant and consistent solution. The agent couldn’t get there because the insight wasn’t in the code. It was in my understanding of the problem space.
And that distinction is everything.
The Memory Problem Nobody Wants to Talk About
Here’s a dirty secret about the current state of agentic development: memory is still a mess.
I don’t say this casually. I’m working on these problems professionally. Context compaction — the process of summarizing and preserving state as an agent works across sessions and repositories — is still operating like a blunt hammer. It doesn’t understand the topology of what it’s compacting. It doesn’t differentiate between a critical architectural decision and a throwaway variable name. It treats everything with the same crude compression, and the information loss is real and consequential.
And here’s the thing about software intellectual property that the “agents will build everything” crowd consistently ignores: the IP isn’t just the code and the markdown files in the repository. Before people tell me that they’ll just semantically index this knowledge, give me a call - I have experience with how well that works for context restoration.
It’s the thousands of wiki design documents. The Jira tickets capturing six months of customer feedback. The sales pipeline data that tells you what the customer actually needs versus what they said they needed in the requirements doc. The security audit from two quarters ago. The compliance review that changed the architecture.
None of that lives in the codebase. All of it is essential to building software that works in the real world. And no agentic coding system on the market today can meaningfully ingest, organize, retain, and reason across that corpus. Not Anthropic’s approach. Not Codex. Not yet.
Problems like persistent memory, rule adherence across sessions, multi-agent collaboration, intelligent compaction — these are all open research problems. Important ones. Solvable ones. But unsolved today. However, the lemmings on the Street are smoking so much of their own AI product that they believe SaaS is dead.
Wall Street has forgotten that the true winners now in the software business are those that leverage not hand-wring about agentic coding solutions to generate solutions that delight customers. This is essentially a developer productivity discussion, not a product replacement discussion. My suspicion? We’re going to see an order of magnitude leap in user experiences, quality, and capability in the software we use everyday.
So this sell off is really, truly, dumb:
Like, really? I love AI, but I’m not exactly sure SaaS is evaporating tomorrow, and is in “bank run” territory.
It made me wonder, maybe the uber feeling and sentiment in the market is that AI agents better completely replace SaaS, otherwise the AI boom is a bust?
I sincerely doubt we’re going to see hundreds of custom, self-created, CRM, HCP, or ERP systems replacing Oracle, Salesforce, and Work Day.
Just like Visual Basic, .NET, Visual C++ and MFC made it trivial for everyday developers to build apps - agentic coding is enabling even the most junior developers to now harness the power of complicated concepts like compilers, operating systems, and protocols.
The SDE 1.0 Problem
About a year ago, I called agentic coding a “SDE 0.7” — below the bar of a college hire at a major tech company. It’s clear that coding agents have now graduated. It feels like they’re an SDE 1. Maybe a strong one. They can write clean code, follow patterns, fix bugs against test suites, and ship features when the specification is clear.
But an SDE 1 doesn’t replace a principal engineer who understands why the system was designed the way it was.
However, I do see a problem in my industry, if firms shy away from investing in SDE1s in favor of AI agents, where are the next generations of principal engineers going to come from?
An SDE 1 doesn’t replace the architect who chose eventual consistency over strong consistency because they understood the customer’s latency requirements in Southeast Asian markets.
An SDE 1 doesn’t replace the product manager who realized that the feature customers were requesting would actually violate their own compliance requirements.
Intellectual property rooted in genuine insight about an industry, a problem space, or a platform — that’s not getting automated away by agents that are, at their core, doing stochastic pattern completion with a really good evaluation loop.
Remember When On-Prem Died?
Some of this “the end of SaaS” rhetoric has a familiar ring to it. When Web 2.0 arrived, everybody said on-premises applications were dead. It was obvious. It was inevitable. The cloud was the future and only the future.
That was twenty years ago.
News Flash: On-prem is still not dead. It’s not even on life support.
Why? Because the executive signing the purchase order isn’t buying code. They’re buying an outcome at a price. They’re buying an SLA. They’re buying security guarantees, compliance certification, regulatory adherence, and the ability to call someone at 3 AM when the system goes down. They’re buying the right to sue somebody if the data leaks.
Now tell me: your startup just had an agent generate 200,000 lines of code in an afternoon. Who owns the SLA? Who’s on call? Who’s tracking the CVEs? Who’s managing the zero-days that are going to start hitting that generated codebase — because they will hit it? Who’s handling the licensing audit when legal discovers that the agent pulled in a GPL dependency?
Sure, you can add agents to help with all of these topics, but ultimately agents don’t make good owners.
Customers can’t fire and hire agents. They can fire and hire humans who operate the agents.
I’ve worked on internal IT teams. The thought of maintaining hundreds of thousands of lines of generated code — with a constant stream of security vulnerabilities, compliance obligations, and legal questions — is enough to make any reasonable CTO pause.
And if you outsource that maintenance to a systems integrator — an Infosys, a Wipro — congratulations. You’ve essentially purchased a SaaS application with extra steps. The economics of SaaS versus custom agentic apps is still very early.
I’m not convinced that it always makes sense to replace a SaaS app with an agentic coded custom service.
The TCO of agentic SaaS replacements is still being settled, though that’s a debate for another day. I wouldn’t be making bets with my personal capital either way yet.
The SaaS teams which incorporate agentic mechanisms into their lifecycle will dominate, utterly destroying legacy competitors who refuse to leverage these new functions.
If software development managers want to survive, they must demand agentic usage by their engineers, and if they can’t get on board - time to move the engineer along. There is absolutely no valid excuse for not using coding agents now.
The Continuum
So here’s what I’d actually tell a product manager sitting in a conference room right now, staring at a slide deck titled “THE AGENTIC THREAT”:
Think of it as a continuum.
Some portion of your product — the commodity layers, the plumbing, the standard platform components — is going to be built by agentic coders shipping every five seconds. Accept that. Embrace it. But that code sits on top of something, and that something is your actual business: a bedrock platform that delivers specific outcomes, compliance guarantees, and the consistency your customers need to build their operations on top of.
Your job is to accelerate moving your differentiating features and intellectual property into that core platform. That’s what creates stickiness past the demo, past the MVP, past the initial deployment. That’s how year-two revenue happens.
If I were a software development manager right now, I’d take 20 to 30 percent of my team and point them at building the CI/CD pipelines, the feature flag mechanisms, and the testing infrastructure to ship with agentic coding every hour.
I’d have them running constant experiments — measuring what customers actually respond to — while maintaining a consistent, opt-in experience. Agentic coding becomes a tool in the product manager’s kit. Not the apocalypse. The toolkit.
But I would also be implementing automation and mechanistic pipelines to take this constant stream of innovation from the customer’s environment back into the product.
Developing this pipeline a couple important prerequisites:
The developer operating the coding agent actually understands the code and architecture generated.
Ideally, the most unique, differentiating, and compelling parts of what was delivered by the coding agent originated from a human (hint: it currently likely did).
Ensure that you aren’t burning tokens on features that make it look like you are evolving the product, but in reality, you’re not solving new business problems. Adding a flexible “user defined field” mechanism in today’s agentic environments is not a good use of tokens.
The agentic coding mechanism must have a comprehensive test suite to go with it that demonstrates that it works. Or it has to be manually tested by humans. Hint: you may be trading fast code for hours of human testing, especially when it comes to user interfaces.
Coding guidelines for agentic developers should be equivalent to humans. The principles have to be codified in the agent’s markdown format. Force the memory to be checked in so that when the next iteration has to occur, you can continue from where you left off.
The Punchline
More software is coming. An extraordinary amount of software. The creation cost is collapsing, and that’s genuinely transformative.
We’re in the GarageBand era of software development. You no longer need a large production and recording room to create unique, beautiful, works of art that delight your customer.
But code alone a service it does not make.
You need the insight to know what to build. You need the memory to know why you built it that way. You need the platform to guarantee it works. You need the compliance to prove it’s safe. You need the SLA to promise it’ll be there tomorrow.
I love agentic coding. It will help us build a lot more, better, capable software that delights our customers. But this does not mean that a non-linear agent can solve every problem in the book.
Do we want a non-linear large language model writing code to fill out my 1040 in April or do we want a consistent, proven, algorithm that ensures compliance with the latest IRS laws that are outside of the model’s training date?
Agentic coding will take it’s place in the same way that every other major revolution in developer productivity has.
Until an agent can do all of that — and we are years, not months, away from that — the people wandering around proclaiming every SaaS application dead are smoking a bit too much Valley dope.
Build the platform. Automate the commodity. Protect the insight.
Wise post. The recognition that reality is always more complicated that we like to think :)