Infinite Disposable Software
I have come to the conclusion that most software written within the next five years will be used by a small handful of users for a short period of time, and then be thrown away. This does not mean that we're headed for The Death of SaaS as some have speculated, but it doeslook like a fundamental market shift is starting that will impact the kinds of purchased software that people will engage with.
Background
As someone who's spent most of the last decade in the digital architecture space and not writing much code, I've paid very close attention to the advancements with LLMs with respect to software development over the past several years. When Github Copilot arrived on the scene, I could see how it might help speed up some boilerplating. The numbers I had in my head were that I expected that the median software developer might find themself saving 20% of their development time (bearing in mind that development time is not 100% of a developer's time.)
The tools continued to improve, and while it's not as fast or dramatic as some expected, they have progressed further than I expected they would. Advances like what we've seen with the LLM explosion usually follow an S-curve. It's notoriously difficult to identify where you are on an S-curve while you're on an S-curve. At some point after ChatGPT 3.5 came out, I felt like we were plateauing. Indeed I still believe that the LLM performance itself has not made massive general improvements since then. However the "niche" area of code generation has made significant improvement.
Attempt #1 - Impressive but Messy
The problem with any tool is often with the wielder. This has never been more true. I have learned a lot since first dipping my toe in the waters with Claude Code in the middle of last year. The thing that I built in my first week of working with it was not high quality. It was barely functional. It was impossible to maintain, and if it had a spirit animal, that spirit animal would be called Technical Debt. It was however an impressive and useful proof of concept.
I haven't done any significant development work in more than a decade, so I was truly working coding with a set of technologies that I only have superficial experience with. There were what I diagnose as significant memory leaks somewhere in the codebase, and it would not have been worth anyone's time to try to figure them out. If I left one of the web pages open on my browser overnight, I would come in to a crash in the morning. It was not software that I would want to release, or have associated with my name. It was not crafted, it was vibed into being.
At the time, I was firmly of the belief that this was the best you could expect out of the tools available, and while newer models might nudge things forward a bit, it still felt like we were on the flat top of the S-curve.
Attempt #2 - The Current State of the Art(?)
Several things came together to have changed my mind about the shape of the software future. First, the launch of Skills within Claude Code.
Skills allow the user to connect some specific instructions and potentially some scripts and other non-AI capabilities into a package that is readily reusable without cluttering context windows.
Second, I came across the Superpowers skills which Jesse Vincent kindly shared with the world and has continued to iterate on. The brainstorming skill alone has changed how I work with LLMs in a way that I certainly didn't see coming.
The improvements have resulted in a capability that I honestly didn't think we'd reach with LLM technology. With the right harness and scaffolding, fully functional applications can be built from a specification flavoured prompt. The quality of the code is possible to influence in a positive direction. I won't say that it generates the cleanest code I've ever seen, but I have definitely seen human developers who produce worse.
I rebuilt the thing that I had initially attempted, this time with a tech stack that I have even less experience in. I guided the system to make sure it was only doing the things I asked of it, and to use a more minimal set of dependencies in order to minimize risk. The webpage is significantly more stable, and it feels more solid and sane. It took me three times as long to do the work this way, but it feels like the result is closer to something I'd be ok putting into production (closer, but not there yet...)
The Four Types of Software in 2030
My thinking on the future of software is that it's quite different from the software industry that we have all become familiar with. I think there will be four main classes of software in the future.
Type One Software: Foundational
This is serious software that needs to be stable, safe, secure, auditable, mature and trusted. This class of software will not benefit as much from the new tooling because it will need to meet all of those requirements which have less to do with the coding part of software development and more to do with process. Think of things like SAP, or Excel - the software that the old world runs on.
Foundational software isn't going anywhere, but the vendors providing it are going to have some interesting market forces working on them to push more toward agility. I think some pivot in this direction is warranted, but the most successful vendors in this space will do well to keep their reputation in mind when they're feeling pressure to cut corners. After all, this software is expensive so it better be worth it in a world where everyone can build a CRUD app with a couple of hours and a $20 Claude Code subscription.
Type Two Software: The Future of SaaS
Slightly more agile software that lives in the middle and gives up some of the stability and security for that agility. You'll find a wide array of Software as a Service offerings living in this space. It will benefit from the new tooling, but it will also be a risky bet - without looking under the covers, you won't know for sure if the folks that built it take things like security and auditability into account.
The pressures here will be large, and that's why you're seeing scary articles in Forbes proclaiming The Death of SaaS. Vendors in this space will need to be leveraging solid software development practices on top of LLM tooling to justify their increasingly small monthly subscription numbers. The days of being able to ratchet up the prices on a captive audience are behind us. If your SaaS offering has had a 10x price increase in any given year, you're likely going to struggle to maintain that pricing level.
Type Three: Enterprise Custom Software
Similar to the new world of SaaS, there will be a new world for custom software within the Enterprise. The economics of building more robust software have improved significantly, but reality has maybe not been able to surpass expectations that have been set by the fourth type of software. There will still be a need for more robust point automation solutions to support unique business processes. The emergence of practically free prototyping tools will uncover a lot of demand for more solid enterprise software. My suggestion is that enterprise software leaders get good at ROI calculations.
Type Four: Infinite Disposable Software
What is infinite disposable software? It's stuff that will be built for a user base of one. It will do its job, and then it will be thrown out when no longer useful. It will not have a software development lifecycle because it will have the lifespan of a fruit fly. It will be more akin to a spreadsheet than it will be to what we conceive of as software today. We're starting to see this emerge today. Many vibe coders who have an itch to scratch, prompt their agent, come out with a solution and then feel the need to share with the world this thing that they created with negligible effort. The thing is, their target audience also has the same tools, and can create the same app to scratch the same itch if they really want to. There is no money in this software. It may have some transient value, and it may even uncover a need that will result in new solutions in the second category above in order to meet more rigorous needs around stability, security etc.
How many spreadsheets does an average Enterprise have? Would that be a useful metric to calculate? I kind of doubt it. I think we'll find people wanting to create software at a similar sort of scale. Some of those applications will become more complex and unwieldy. They will become the fabric of the Enterprise. Others will be tossed aside like a used tissue when they've served their purpose.
I believe that what we're currently seeing is a signal of what's to come. I think there will be a hockey stick like curve, and I think we're still near the toe of the blade. It's important for leaders in IT to get in front of this before we hit the exponential growth phase because otherwise we will be reacting to the escape of our horse by closing the barn door a bit late.
The Skill Gap
My journey was very low stakes experimentation to try to learn the capabilities of the state of the art tools. Where it gets really interesting is when you put it into the hands of people of varying skill levels. Someone like Simon Willison churns out a lot of amazing tools on a regular basis because he understands the constraints of the tools.
Other folks see that and vibe code up whatever itch-scratching tool of the week, then publish it out to a wide audience before having someone do a security scan on it and uncovering amazingly poor practice (Exposing secrets via unauthenticated API endpoint? What could possibly go wrong?)
So What Should We Do?
The first step is acknowledging that this is coming for us, like it or not. If people are going to be building infinite disposable software, the smart thing to do is to set up some safety guardrails to prevent some of the most egregious harms that an inexperienced vibe coder could do. Let's replace the armor piercing rounds with some nerf darts or paintballs, and see if we can't still get some value out of things.
First, ensure there is a safe and solid foundation for people to vibe code against. This may look like controlled interfaces with a level of discoverability layered on top. It may look like a set of organization-wide deployed skills that guide the disposable software toward a supportable architecture and scanning for the kinds of things that we don't want to get into trouble with - whether that's not exposing api keys, or protecting against data loss.
Next, define the process for these things to ensure people are able to share them securely with their peers, and also to be able to provide visibility into what's out there. This will help with cleanup as well as reducing blast radius if something does go wrong. If people want to play with explosives, build them a safe room to blow up in.
Once you've got the guard rails in place, the next step is to educate and share so that your stakeholders know how to take advantage of these new capabilities safely and within compliance. People want to get their job done, they're not interested in a lot of the things that IT departments care about like security and safety. If you can provide those things without getting in the way of executing the idea, they'll be more likely to follow along. If you can provide those things while making things easier for them... you've likely got a winning solution.
Conclusion
The future of software is more uncertain now than it has been since the early days of computing. As we tightrope through this rapidly changing landscape, we have to keep one eye on the transformative potential, and one eye on the stability of our foundations. The proliferation of disposable software driven by the advancements in AI and automation will likely surpass our current expectations. This shift will force us to rethink how we approach security and sustainability.
Given these coming changes, IT leaders need to stay ahead of the curve or be run over by the freight train that’s bearing down on them. It’s not sufficient to stick our heads in the sand and pretend that we can prevent people from leveraging these tools. Instead we need to position ourselves to adapt and take advantage of the situation to thrive in this new era.
Most software written in the next five years will be used by a small handful of users for a short period of time, and then be thrown away. If we do it right, we can increase the value that this software provides while still maintaining the standards of security, safety and quality that are expected of us.