The age of disposable software was supposed to arrive with AI. It didn’t. What arrived instead is worse — and harder to see.

There’s a strange inversion happening in software engineering right now, and most people are too busy shipping to notice it.

For decades, the constraint was supply. Good engineers were scarce, so demand for software always outpaced the ability to build it. That scarcity shaped everything: how companies hired, how products got prioritized, how “build vs. buy” decisions got made. If you wanted software, you either paid a lot for someone to build it, or bought something generic off the shelf and molded your workflow around its limitations.

AI flipped this. Now almost anyone can describe what they want and get a working version in an afternoon. Supply of “software creation capability” has exploded. But demand for generic software—the kind you’d sell to a thousand strangers—hasn’t grown nearly as fast. What we’re left with is a glut of bespoke tools, each built by one person, for one person, rarely touched by anyone else.

The tempting read is that we’ve entered an age of disposable software—cheap to make, cheap to discard, no different from a napkin sketch. That read is wrong, and the way it’s wrong is the actual story.

Creation as a Psychological Act

Here’s the part nobody wants to say out loud: a lot of this creation isn’t really about solving a problem. It’s about fulfilling something.

For most of software history, building something required capital, a team, months of grinding, or specialized skill most people didn’t have. There was a whole class of people—non-engineers with great ideas—who had to sit on the sidelines and watch. Now that barrier is gone, and what rushes in isn’t just utility. It’s catharsis. It’s agency. It’s the deferred satisfaction of finally being able to make the thing instead of just imagining it.

This is why so much of what gets built goes unused by anyone except its creator. The act of creation was the point. The tool itself is almost incidental—a receipt for the experience of building it. We’re watching millions of people simultaneously discover what it feels like to be a founder, a hacker, a craftsperson, and most of them stop the moment the itch is scratched.

It’s easy to mistake this for evidence of disposability—so much gets built, so little gets kept. But look closer, and the things that do survive expose the illusion.

The Debt Nobody Sees Coming

People don’t actually throw away things that work. Call something “disposable” and you imply consequence-free. In practice, the opposite happens.

Someone conjures a script that automates their weekly report, and it works—so they keep using it. Then it becomes load-bearing. Three months later an API changes upstream, the script breaks silently, and the person who built it has no mental model for why. They didn’t write it; they described it. Debugging a system you never understood is a different skill than building one, and most people who generate software never develop it.

So the AI gets asked to fix it. Sometimes that works. Often it spirals—the AI patches a symptom, introduces a new bug, the user re-prompts, and now three layers of unreviewed patches sit on logic nobody fully grasps, including the “author.” This is a new flavor of technical debt: not sloppy code written by someone in a hurry, but invisible code that was never truly authored by anyone at all. The reliance is real even when the ownership isn’t. Disposability was never really the endpoint—dependency was.

The Missing Middle

There’s a second gap in the clean “generic infrastructure vs. personal shim” story, and it shows up the moment more than one person is involved.

Software isn’t only a tool; it’s a coordination device. If I generate a bespoke CRM shaped exactly around my sales process, that’s great for me—until my manager needs to pull a report, or a coworker needs to cover my accounts while I’m out.

Generic software is inefficient by design, and that inefficiency is a feature: standardization is what lets ten people work off the same system without translating between ten private dialects of “how this works.”

Hyper-customization solves the individual’s friction and reintroduces friction at the team level. What likely emerges isn’t a clean binary of enterprise infrastructure below and personal shims above—it’s a middle layer of negotiated standards: shared schemas, shared APIs, shared “contracts” that let personalized tools interoperate even though no two people’s tools look the same underneath. The generic layer doesn’t shrink to just databases and auth; it expands to include whatever thin protocol layer lets a hundred bespoke tools still talk to each other. Think less “everyone builds their own CRM” and more “everyone builds their own interface to a shared data contract.” The standardization moves down the stack, not away entirely.

Taste Isn’t Free of Technical Understanding

The other place the “disposable” framing breaks down is the assumption that the future differentiator is pure taste—knowing what to ask for and recognizing good output.

That’s necessary, but it quietly assumes something it shouldn’t: that judgment and execution are separable. Right now, there’s a wide and very real gap between noticing an output is wrong and being able to get the AI to fix it. When a bug is shallow, taste is enough—you can tell something’s off and re-prompt your way to a fix. When a bug lives in the interaction between three subsystems, taste without technical grounding just produces more confident-sounding wrong answers, faster.

So “taste-haver” probably isn’t quite the right frame. The people who thrive won’t be the ones with good aesthetic judgment alone—they’ll be the ones who retain enough of a mental model of how computers actually behave to know when the AI is confidently wrong, and precise enough in their own thinking to diagnose it rather than just re-describe the symptom. Judgment without a model of the underlying system isn’t taste. It’s just guessing with better vocabulary.

What Happens to the Engineer

Given all this, the role of “software engineer” doesn’t cleanly bifurcate into “platform engineer” and “prompt curator.” It’s closer to a gradient, with value concentrating at both extremes and thinning in the middle.

At one end: platform engineering, building and maintaining the trustworthy, generic, load-bearing systems—and increasingly, the interoperability contracts—that everyone’s personalized tools sit on top of. This gets more valuable, not less, because it’s the bedrock everything else depends on.

At the other end: something closer to systems-literate judgment—not writing every line of code, but retaining enough of a real mental model of how software behaves to catch the AI’s confident mistakes, debug the dependency nobody else can see, and know when “good enough” output is actually a landmine three months out.

What thins out is the middle: engineers whose value was mostly “I can translate requirements into working code,” with no particular depth of judgment and no particular ownership of foundational systems. That’s the segment execution-as-a-commodity eats first.

The Real Shift

The interesting thing isn’t whether hyper-customization happens—it’s already happening—but what the illusion of disposability was covering up all along.

For the individual, part of the original instinct still holds: a tool built for exactly one person, for exactly one problem, is often worth building even if it’s never “kept” in any formal sense—the value was in the making, not the maintaining. But the moment that tool starts doing real work, disposability quietly ends and dependency begins, whether anyone notices or not.

For the industry, this isn’t romantic at all. It’s a hard reallocation of value: away from the generic execution layer that used to be scarce, toward the trust layer that makes personalization safe to build on, and toward the rare people who can tell the difference between software that merely runs and software that will still be running—correctly—six months from now. Catharsis explains why people build. It never explained what survives, and it certainly doesn’t explain what quietly starts depending on what they built.