An Era of Disposable Software
It started as an informal race. A few weekends ago, we were having a family game night. My wife thought it would be fun to play Family Feud. Her first instinct was to reach for a trusted PowerPoint version she's used for years and start modifying the slides. I wondered if I could build something better with Claude Code in the same time it took her to edit the slides. I was wrong. I finished first.
In a little over an hour, my 11-year-old son and I built a fully-featured Family Feud game. Custom theme music, questions loaded from a spreadsheet, dual-screen setup so he could host from a separate device. It was exactly what we needed for one night of family fun. Then we threw it away.
That experience solidified a concept I had been thinking about. A new category of software is emerging.
For most of my career, I based the build-vs-buy decision on cost. Development is expensive, but maintenance is where the real cost lives. The ROI had to be there otherwise I'd look for an alternative solution even if it didn't exactly fit my problem.
In many ways, I now see software in one of two categories: shippable (production software we release, maintain, and support) and disposable (stuff we make, use, and throw away when we're done). Shippable code powers the mission critical applications and infrastructure we all depend on. That's not changing.
Disposable code lives in low stakes environments. It may enable a single task, have a limited shelf life, or serve a minimal audience. Use cases include design mockups, experiments, exploration, prototypes, hobby apps, utilities. You generate code to do a thing, you do the thing, you throw it away. The Family Feud game served a single purpose, for a small group, for one night.
As the tooling becomes more capable, and best practices to effectively steer coding agents and the underlying model continue to emerge (explore, plan, implement, verify), the range of what's possible, and able to be considered as disposable, continues to expand.
Disposable code can also accelerate learning in service of shippable software. Historically, it has been a costly mistake to build the wrong thing. When we accelerate the process of experimentation, investigation, and evaluating a proof of concept: building and throwing away at times is faster than speculating. The code gets discarded, but the learning carries forward, de-risking and informing the production implementation.
Others have explored and demonstrated unique use cases of disposable software. Simon Willison built a conference schedule management app while having coffee with a colleague, all from his phone. I've built bespoke applications to facilitate error analysis in my evals work.
It's not just engineers who can benefit. I can see technical managers, PMs and other team leads whipping up interactive dashboard apps for presentations rather than spreadsheets and pivot tables.
As I move forward, one of the questions I ask myself before investing in a software purchase or subscription: is the cost model and risk profile such that I can just build this with an AI agent for myself?
Some software demands durability. And steering LLMs to build software, even disposable software is not something anyone can just do. I'm not a proponent of vibe coding (creating software you don't understand). Recent advancements in the capabilities of coding agents and frontier models is impressive; however, real dangers remain around security, quality, and cost. The slop game is real. However, I feel this category of disposable code is emerging and likely here to stay.
