In 2023, John D. Cook wrote an article titled Solved problems becoming unsolved . His point was direct: Once a problem is considered “solved,” people’s attention may move elsewhere; but that does not mean the software built to solve it will remain usable forever. Environments, dependencies, and user needs keep changing. Links break, and programs can gradually become impossible to build. Some problems, then, become unsolved again.
That’s a solved problem. So nobody knows how to solve it anymore.
– John D. Cook
By 2026, vibe coding and agentic AI have significantly lowered the barrier to “building software.” Describe a need, generate code, revise it repeatedly, spend more tokens, and you can get a working tool—or even a product. This is an astonishing advance in AI and its applications.
But as building and production become easier, I can’t help noticing something else: Some tools may be used only a few times, then left unmaintained and forgotten, eventually becoming digital orphans. Code, data, and experience that could have accumulated as assets may instead be set aside as obsolete clutter.
This brings to mind the consumer habits that became more common after industrialization and mass production: When something breaks, replace it; after using it for a while, buy a newer one. The analogy is not exact, but it may remind us that as the cost of making things falls, our habits of using and discarding them may change as well.
Marketing often classifies consumer goods according to how people buy them: convenience goods, shopping goods, specialty goods, and unsought goods. But this classification describes purchasing behavior, not how long a product lasts, and it cannot directly tell us whether software is worth maintaining.1 For software, a more practical question might be: Is it a short-term, low-risk tool that can be replaced after use, or an asset that carries important workflows, data, and knowledge, and needs someone to look after it over time? The former can be intentionally lightweight; the latter calls for testing, documentation, access controls, dependency management, and maintenance responsibilities to be considered from the start.
I’m not saying that generating software quickly is a bad thing. I’m just wondering: If we know that some problems “solved” through vibe coding may become unsolved again, might that change the way we use AI? Perhaps not every small tool needs to be kept for the long term. But before building one, we can at least consider how long it needs to last, who will be affected if it fails, and whether anyone will be willing to take it on.
Things are easy to build, but that doesn’t mean anyone will keep looking after them.
There is no standard answer. Still, knowing that a solution may have an expiration date may be enough to change how we think about “building” in the first place.