Disposable software: what it actually means and why most people misunderstand it
Nate B Jones of AI News & Strategy Daily argues that the "disposable software" trend is real but widely misunderstood, and that applying it indiscriminately across different markets is a strategic mistake.
Summary
Nate B Jones presents a solo analysis of the disposable software trend, arguing that while the cost of generating software has genuinely collapsed — illustrated by Cursor's AI agents building a working browser in one week versus Chrome's two-year development timeline — most commentators are drawing the wrong conclusions. He distinguishes between two fundamentally different categories of disposable software: throwaway personal tools and rapidly iterated enterprise features. His central argument is that attention, not software cost, has always been the real constraint, and that cheap code generation does not change this. He further argues that the vast majority of enterprise software customers are buying reliability and peace of mind, not features, which makes the disposable software philosophy actively harmful in that context. The winning strategy for enterprise players, he contends, is to establish deep reliability first and then extend that trust into proactive AI agent capabilities — not reactive chatbots, but agents that take autonomous, correct action before users even know they need it.
Key Takeaways
FULL TRANSCRIPT
The core claim: disposable software is real, but almost nobody understands what it means
Nate B Jones: The age of disposable software is here, and almost no one understands what that really means.
Everyone's talking about disposable software. Vibe coders are talking about it. VCs are talking about it. AI-native startups are talking about it. 95% of the last Y Combinator batch shipped products with codebases that were over 95% AI-generated. Cursor jumped from a $2.6 billion to a $29 billion valuation in a year, shipping hundreds and hundreds of features generated by AI along the way. Lovable hit a hundred million in ARR in just eight months. The discourse is everywhere, but almost nobody understands what disposable software actually means, what it implies for how we organize, what it implies for builders, what it implies for product strategy.
People are pattern-matching to a vibe without thinking through the consequences. And that's very dangerous, because the consequences are significant and they're very different depending on who you are and what you're building.
So let me unpack what disposable software actually means, because once you understand it, you'll see why most of the current discourse is just wrong.
Why software cost has inverted — and what that actually changes
Nate B Jones: Here's the thing that changed. The cost of software was always the cost of engineering. That's it. That's the whole story of Silicon Valley from the 1970s through to about 2023. You needed a team of software engineers to build anything meaningful, and engineers were expensive. That expense was what made the entire venture capital model work. You needed capital to build software, so investors provided capital in exchange for equity, and the machine turned forward on that basic assumption.
That whole assumption — and the model that goes with it — are now false. The cost of software is running to zero. Not trending towards zero over decades. To be clear, it is collapsing towards zero right now. When you can describe what you want in plain English and get working code back, the engineering bottleneck just disappears. The capital requirement disappears along with it, and so does the team requirement. And when something that was expensive becomes essentially free, it just becomes disposable. That's not a value judgment. It's just economics. We don't make precious things that are cheap to produce and cheap to replace.
So disposable software is actually not a philosophy or a movement. It's a description of what happens when the cost structure of an industry inverts. Software is now disposable in the same way that digital photos are disposable — not because we don't value them, but because the cost of producing another one is approximately zero.
The browser demo: what the Cursor example actually proves
Nate B Jones: Here's a concrete example of what that inversion looks like. Two weeks ago, Cursor's CEO announced that his team used ChatGPT to build a web browser from scratch. AI agents ran uninterrupted for a week and generated over three million lines of Rust code. They generated HTML parsing, CSS cascades, a layout engine, text rendering, a custom JavaScript VM, and according to Cursor, simple websites render quite well and largely correctly. It basically works.
Now consider the comparison. Google Chrome started development in 2006 with a team that included developers hired from Mozilla Firefox. The first beta shipped in September 2008 — over two years later. Today, Chromium has 35 million lines of code and hundreds of engineers committing 800 changes per week. It took two years and a team of elite engineers to ship one beta of Chrome. It took one week and a swarm of AI agents to produce a version that's an early alpha. Essentially, that's not a small change. That's an inversion.
But the breathless coverage misses something critical. This immediate shipment wasn't free. Someone at Cursor had to decide to build a browser. Someone had to set up the task. Someone had to configure how the agents would coordinate. Someone had to run it for a week. And now, if they wanted this to be production software rather than a demo, someone would have to improve it, debug it, maintain it, keep it working as web standards evolve.
The cost of generating code has collapsed. The cost of directing attention toward a goal has not. And that distinction is going to matter a lot as we work through what disposable software actually means.
Two completely different phenomena sharing the same name
Nate B Jones: So that's the basic premise. Now here's where it gets interesting. The first thing that people get wrong is that they treat disposable software as one thing, when it's actually two completely different phenomena that happen to share the same name.
The first one is obvious: throwaway software for throwaway use cases. A one-time dashboard, a travel app for the family's upcoming vacation, a small video game you build over the weekend. This is personal software — a category that just didn't exist five years ago. You can just build the thing that you need. It would never have traditionally been software, but now it can be. Want to see a visualization? Build a widget. The category is unambiguously a good thing because it spreads the power of software to more people. It represents genuine democratization. 75% of Replit's customers never write a single line of code. They just describe what they want and get working software. It's remarkable.
The second category is more interesting and more dangerous: disposable features within enterprise products. Here's the logic. If you can ship a hundred different features based on a hundred different customer requests — because your product team, your engineering team, everybody is contributing code to AI tools — then any given feature can be changed next week based on customer response. You can ship and ship and ship and ship. There is no limit. You discover what works empirically with customers. You create a bunch of disposable features and only harden up what sticks.
Essentially, that's the Cursor philosophy. They ship constantly, sometimes multiple times a day. When vocal users complain about the instability, Cursor has essentially said, "We don't care. Changing rapidly is how you keep up." In the AI era, an AI-native company cannot hold its position in the marketplace without keeping up. And keeping up means shipping disposable software. Their phrase for this is "code is reality." If you're not touching reality — if you're in meetings, if you're planning, if you're designing — you're not doing meaningful work. They've reconfigured their entire team around this idea.
What disposable software kills: the rituals of expensive software
Nate B Jones: And that brings me to something that disposable software really kills: all the rituals that grow up around expensive software. Think of traditional understandings of product management, traditional understandings of design, traditional value on the importance of stakeholder alignment, of user research, of roadmap planning. Those processes existed because software was capital-intensive and you couldn't afford to build the wrong thing. So you planned and you researched and you held meetings and you built consensus and then you built software.
When software becomes disposable, you don't need consensus. You just build it, ship it, see if it works. If it doesn't work, you build something else. The planning layer becomes largely overhead rather than insurance. And that's different from the vision layer. You still need a compelling vision for the future of your product even in the age of AI.
Cursor has caught up with this. Their design lead gave an interview where he said the roles between designers, PMs, and engineers at Cursor are really muddy, and they don't have a roadmap because the world is changing faster and faster and there are new models dropping all the time. The company doesn't really have product managers as a distinct position. Instead, PM roles and jobs are spread across many different builders that might have different kinds of titles — some with product titles, some with engineering, some with design titles.
That's a coherent philosophy. It's a new one, but it's coherent. It's the philosophy of "code is reality." If shipping is what matters, then anything that isn't shipping is waste. Design documents are waste. Product specs are waste. Stakeholder meetings are definitely waste.
Where the philosophy breaks: developers are already struggling
Nate B Jones: Now, this does work in certain contexts. It absolutely works if you're building an AI-native product for developers. Developers have an unusually high tolerance for software variance. They understand that things break. They understand versioning. They understand regression. They understand the trade-offs inherent in moving quickly. They accept instability as the price of innovation.
But even developers are getting stretched by the pace Cursor is running at. You can read the Cursor forums. Users are frustrated by forced updates that wipe chat history, by UI changes that require reconfiguring key bindings every week, by features that work one day and break the next. One user wrote in all caps:
Forum user: "Updates make Cursor extremely unpredictable. Working with this professionally is a nightmare."
A Cursor engineer acknowledged the feedback and said they're working to minimize UI changes going forward. But the tension is structural. The disposable software philosophy does demand constant iteration. Stability demands continuity. You cannot fully maximize both of these things.
And here's the thing. If developers — the most change-tolerant population of software users on Earth — are complaining about instability, what happens when this philosophy encounters the rest of the business world?
Enterprise customers are buying reliability, not features
Nate B Jones: Because here's what people miss about enterprise software. Customers aren't buying software. They're buying reliability. When a company buys Salesforce, they're not really buying a CRM. They're buying peace of mind. They're buying something they don't have to think about, because their core competency is somewhere else. Your core competency is not CRM — if you're buying Salesforce, that's why you pay for it. Your core competency is not an HR information system — if you're buying an HR information system, that's why you're paying for it. Enterprise customers buy software precisely so they can ignore it.
And that is why enterprise SaaS contracts are multi-year deals with extensive SLAs. It's why vendors promise 99.99% uptime and staff 24/7 support lines. It's why there are dedicated account managers you can call in the middle of the night and say, "This has to be up. I have a deal that has to go through."
Disposable software is the opposite of everything these customers want. They don't want features that change every week. They don't want interfaces that rearrange themselves between login sessions. They want a product that works the same way on Tuesday as it did on Monday, that will work the same way next quarter as it does this quarter. They want a single ringable number.
The fatal flaw in "just vibe-code your own Salesforce"
Nate B Jones: And the usual response from disposable software advocates goes like this: "Nate, you've forgotten — software is so cheap now. Salesforce won't exist because we'll all vibe-code our own Salesforce."
This argument has a fatal flaw. And it's actually not about software cost. It's about attention.
Imagine you're a company chasing a multi-billion-dollar — or bigger — market opportunity. You have highly paid, highly skilled builders focused on that opportunity. Every hour they spend on core product development creates asymmetric value — the kind that justifies venture funding, builds competitive moats, compounds over time. Now imagine telling those builders: "We want you to stop chasing the billion-dollar opportunity. Instead, please vibe-code an internal CRM to save us a hundred bucks per seat per month."
The software is cheap to generate. The attention is not. Someone still has to specify what the tool should do. Someone still has to prompt the AI. Someone still has to keep an eye on the bugs the agent produces. Someone still has to maintain it when it breaks. It's not completely zero. You're essentially saying that a hundred dollars a seat — a few hundred bucks a seat — is worth your highly paid builder's time, but chasing your core business opportunity is not. That math doesn't work. The opportunity cost of diverting your best people from your core mission is incalculable. And no amount of cheap software changes that equation.
The hidden maintenance burden of AI-generated code
Nate B Jones: And there's a second layer to this that people miss. The maintenance burden doesn't go away just because the initial build was cheap. Vibe-coded software still accumulates technical debt. It still breaks when underlying APIs change. It still needs someone to debug it when it behaves unexpectedly.
The research is actually pretty damning here. AI-generated code introduces security vulnerabilities in nearly half of all coding tasks. And those vulnerabilities tend to be the deep and architectural kind that scanners miss and reviewers struggle to catch. So you haven't really eliminated the cost by switching your attention to vibe-coding a SaaS product. You've just shifted it from upfront engineering to ongoing maintenance and security remediation in an area that is not your core focus. And that ongoing cost gets paid by the same highly compensated people you were trying to free up for your core business.
The disposable software advocates want you to believe that software cost was the constraint. They're wrong — it wasn't. Attention was always the constraint. Software getting cheaper doesn't make attention more abundant.
The chasm between developer customers and enterprise customers
Nate B Jones: Here's the part that many people don't want to say out loud. The universe of companies that can actually use Cursor's philosophy — that can ship absolutely everything, move constantly, and let users adapt — is not very big. It's tiny. And it's tiny because of who their customers are.
Cursor's customers are developers. Salesforce's customers are CIOs. That's not a tiny difference. That's a chasm.
Developers can fix things when they break. CIOs will just call the account manager and look at the contract. Developers understand why updates cause regressions. CIOs just see broken workflows. Developers get value from new capabilities and are willing to tolerate instability to access them. CIOs get fired if the payroll doesn't run on the 15th. Developers choose a bleeding-edge tool knowing it might change. CIOs choose a vendor with an SLA specifically so they don't have to think about the software.
The whole point of buying Salesforce is that you're not the kind of company that wants to be in the CRM business. You want someone else to handle it. Cursor can ship disposable software because their customers are developers. Salesforce cannot, because their customers are CIOs. This is not a temporary gap that will close as AI improves. It's a fundamental difference in what the customer is willing to pay for.
And here's what really gets me. Even the developers are struggling. Cursor's own users — the most change-tolerant population we've got at scale — are complaining about instability. They're asking for the ability to disable updates. They're saying that working with Cursor professionally is difficult because they don't know what will change. If developers can't handle the disposable software philosophy at full intensity, what makes anyone think that finance or HR teams will be able to do so?
The right AI strategy for enterprise SaaS: proactive reliability
Nate B Jones: So if you're in the reliability business — if you're Salesforce, if you're competing with Salesforce, if you're trying to disrupt any enterprise SaaS category — what does disposable software mean for your AI strategy? Frankly, it means you can't think that way. You can't use it. But that doesn't mean you ignore AI. I want to underline that about sixteen different times. It means you need a different approach to AI.
I see most AI-native startups trying to disrupt enterprise markets by saying "we're AI-native" like that's enough — when it's not. If you're a startup trying to disrupt the enterprise SaaS market, you have to be reliable first. You have to prove that your product works, that it will continue to work, that data is secure, that there's a human being customers can call when something goes wrong. This is table stakes. Without reliability, no one is going to buy anything.
And then — and this is where the opportunity lies — you must extend that reliability into an edge through proactive artificial intelligence. I do not mean bolting a chatbot onto your product. Whether you are a startup or, more likely, an established player, I don't mean bolting a chatbot onto your product. A chatbot is reactive. It waits to be asked. That is not impressive anymore. Every SaaS company in 2025 and 2026 has a chatbot. The chatbot says "How can I help you?" and then you have to know what to ask it. That is not transformation. Even if the chatbot can do cool stuff, that is a help desk with a language model.
What is impressive is being proactive. If you're building sales software, the agent in your product should be your customer's most proactive BDR. It proactively analyzes calls without being asked. It proactively surfaces coaching tips before the rep realizes they need them. It proactively identifies high-value deals and takes appropriate action — maybe it updates the CRM, maybe it drafts a follow-up email, maybe it alerts the sales manager. You don't wait to be asked. The agent sees something, understands what needs to happen, and just does it.
That is a fundamentally different value proposition. Reactive AI saves time when you know what you need. Proactive AI creates value when you didn't know what you were missing.
Trust must come before proactivity
Nate B Jones: The key phrase is "proactively reliable." You've earned trust through reliability — through months or years of the product working exactly as expected — which gives you the space to take autonomous action on behalf of users. And that's the two-step: reliability first, proactive capability second. You cannot skip step one.
If you try to be proactive before you've proven reliability, you will terrify your customers. An agent that takes autonomous action on behalf of users is only valuable if those users trust the action to be correct. If they have to second-guess the agent, if they have to check its work, if they're worried it might mess something up, then the proactive capability is a liability. It creates anxiety rather than value.
This is where the market is heading in 2026 — from reactive AI to proactive agent frameworks. And proactive agents require something that disposable software can't provide: deep, sustained trust that the system will always act correctly. You have to be able to show the agent isn't endangering the business by taking action. The companies that figure out how to be proactively reliable will win the next decade of enterprise software. The companies that think "we're AI-native and that's the strategy" will wonder why customers won't trust them with anything important.
Interface simplicity as a buffer for constant change
Nate B Jones: And here's something underappreciated about how all of this — the conversation around disposable software and proactive AI — hits the interface. How we actually talk to it.
AI works better through simpler interfaces. Part of what has made Claude Code enormously successful is that it's a terminal interface. The terminal doesn't change when Claude gets better. You just get more capabilities. There's no GUI to redesign, no key bindings to rearrange, no visual elements to rethink. The simplicity creates a buffer between the product's evolution and the user's experience. So Anthropic can ship constantly — over a thousand commits in recent releases — without stressing users out with a big visible change.
This might be the implicit design principle for the disposable software era. If you want to ship disposable features, you need an interface simple enough to absorb constant change without imposing that change on users. The terminal does that really well, and a complex GUI does not. And that's why Cursor, with its rich GUI, keeps running into user complaints about instability, while Claude Code — which is shipping just as fast — doesn't hit the same friction.
And by the way, that principle of simplicity also extends to the conversation we're having on enterprise SaaS and proactive AI. If you're using proactive AI, a simpler interface is going to help a user understand that new concept of proactive agentic AI much more clearly. If they can see clearly what action was taken, and they can see clearly that it is obviously the correct action, and the agent is following a plan — that is going to make a big difference.
We see hints of that in the Claude.ai work interface, which is an agentic interface today for non-technical users. It shows the plan, it shows the artifacts the agent created, and it shows the actions the agent took. You don't have to label it "artifacts" to have that value — you can label it "documents created." The point is you're showing your work, and that helps to build trust.
Four ways the current discourse gets disposable software wrong
Nate B Jones: So let me tie this back to where we started. Everyone's talking about disposable software, but nobody understands what it really means. What it means is honestly context-dependent. It means different things for how you organize, what you build, how you compete. And the current conversation gets this wrong in four specific ways.
First, it treats all software as equivalent. That's wrong. It assumes that because you can vibe-code a vacation planning app, you can vibe-code a replacement for Salesforce. The categories are different.
Second, it ignores opportunity cost. Free software isn't free. When building it diverts attention from more valuable work, attention is the constraint — not software cost. That hasn't changed.
Third, it underestimates how much of the software market is built on reliability rather than features. Most enterprise customers are buying peace of mind. They're buying something they don't have to think about. Disposable software is the opposite of what they are looking for.
And fourth, it treats the edge case as the general case. Cursor can ship disposable software because they're building for developers who can tolerate variance. That's maybe 5% of the market. The other 95% is the rest of us, and the rest of us need a different strategy.
Two playbooks: disposable software vs. dependable software
Nate B Jones: So let's say you've figured out which game you're playing. Now what?
If you are in the disposable software space — AI-native products, developer tools, anything where your customers choose you because you're on the frontier — your imperative is speed. And you probably know that already. Not measured speed, not responsible speed — maximum speed. You cannot hold back. Your competitors won't. You are shipping at the pace that compute can scale. The models are improving every couple of weeks. If you're not shipping constantly, you're falling behind. Cursor ships multiple times a day, and so do all of the other major players in the space. The companies that will win will be the ones that fully embrace disposability and are able to scale with the gains in compute that we see at the model makers. Every interface is temporary. Every release is an experiment. And you must accept that some of your users will not like this. You must accept that your moat remains execution speed. If that sounds exhausting, it kind of is.
Now, if you're in the dependable software space — enterprise SaaS, anything where CIOs or someone like that is your buyer — the question is how you earn the right to be proactive. The opportunity isn't to pretend that you ship like Cursor. You can't, and your customers don't want you to. The opportunity is to build toward proactive AI that creates value your customers didn't know they were missing. But you have to earn that.
If you're a startup trying to break in, your job is to prove reliability. That means the boring stuff — the uptime, the security certifications, the responsive support, all of the stuff that keeps the relationship going and the lights on. Trust comes before the proactivity, even if people say they want the proactivity.
If you're an established player with existing trust, your job is to extend that trust into agentic capabilities — but do so carefully. Start with low-stakes autonomous actions where mistakes are recoverable. Let the agent suggest before it acts. Build a track record of correct decisions before you expand the scope. The goal is for customers to gradually realize the agent has never been wrong.
Salesforce as a cautionary tale for established players
Nate B Jones: This is a case where Salesforce itself — by most reporting — has bitten off more than it could chew. A lot of leaks are coming out of Salesforce now that indicate that internally, teams are very frustrated by how fast Salesforce has pushed into AI agents without correct execution that emphasizes quality. We will see how that all shakes out, but it would not surprise me to see them leaning further over their skis than they can really afford to lean, because they're so excited about AI. That is absolutely a common failure mode for established players.
You have to be able to recognize what your customers are really buying in the AI edge you're delivering. And know that if they're buying reliability and they want you to deliver AI with reliability, you have to do it reliably. There's no compromise. You can deliver the proactive AI features they're begging for, but you must do so with quality.
Conclusion: know which game you're playing
Nate B Jones: So where does this leave us? The age of disposable software is real. The hype, in that sense, is not making it up. The cost of generating software has collapsed. That changes everything about how we organize, about how we build, and about how we compete. But it doesn't change everything in the same way for everyone. And that's where most people make their mistake.
If you're building for developers or for similar audiences that are AI-native from the get-go, you can and should lean into the disposability all the way. If you're building for more stable enterprise clients, you have to lean into reliability and you have to earn your way toward an AI stance that really lifts the load off the teams of the customers you're serving — proactive AI.
The discourse in general is wrong because it assumes that the most hyped cases are the general cases — like the Cursor case, or a case where you can vibe-code your own SaaS, which I know a few CEOs are bragging about. But most teams, most software — it doesn't work that way. Disposable software advocates want you to think you can ship like them, and that you should, and that you're wrong if you don't. Most of us need to take AI seriously, but more seriously in the context that we're operating in, and less as if we are stealing or cribbing from another company's strategy serving different customers.
I see that way too often — because another company is AI-native and ships a lot, we think that strategy works for everybody. It doesn't. Know which game you're playing, and then play that game all the way.