disposable software: software is now just paper plates

SubscribeSign in

disposable software: software is now just paper plates<br>every piece of software shipping in 2026 has a shelf life of about 3.8 months.

Auren Hoffman<br>Jun 18, 2026

91

16<br>14

Share

the engineers building it know it. the founders shipping it know it. the customers buying it know it. no one is pretending otherwise.<br>we are building software the way i wrote code in my college computer science classes. to last the project, not to last forever. just long enough to get the grade and then deleted.<br>this is the new default and it massively changes what software actually is.<br>and this is a good thing.

AI is just going to get even better at code

a year ago the best AI coding tools could finish a function. today it can read an entire codebase, plan a change, edit dozens of files at once, run the tests, fix what breaks, and ship a working version of whatever was asked for. that did not exist twelve months ago.<br>the engineer typing the code used to be the bottleneck. that is gone. describe what you want in plain english and a working app shows up. one human plus one model ships on a saturday what used to take a team a quarter.<br>anything that takes a week to ship today will take a day to ship by december.<br>so what is the point of building it to last?<br>the dixie cup parable

in 1907, a guy in Boston named Lawrence Luellen invented a one-piece pleated paper cup. he was worried about germs spreading from the shared tin cups chained to public water fountains and on passenger trains. he originally called it the “health kup.” it got renamed dixie in 1919 after a doll company that happened to share his building.<br>dixie did not displace fine crystal. no one was drinking out of crystal goblets at the train station. dixie displaced the shared tin cup -- communal infrastructure that everyone hated using but nobody wanted to pay to replace.<br>paper cups did not win because they were cheap. they won because the maintenance cost of the alternative -- washing, sanitizing, tracking down a cup that walked off -- went from “annoying” to literally spreading disease.<br>software is in the same moment. legacy code was never loved. it was tolerated because the alternative was expensive. now the alternative is a prompt.<br>the disease is not germs. the disease is engineering hours spent maintaining stuff a model can rewrite for free.

the average codebase used to last 6-8 years

before AI coding, the average software program had a lifespan of 6-8 years. and a lot of the core code the internet runs on is 30 years old. enterprise systems above a million lines of code lasted 12-14 years, partly because they were too painful to replace.<br>now the lifespan looks more like 9 months. the model gets better. the workflow gets easier. abstractions move up the stack. whatever shipped last quarter is suddenly the legacy version.<br>rewriting used to be terrifying because the real value of an old codebase was the corner cases of every weird customer condition, every undocumented patch, every workaround that turned out to matter. that hard-won wisdom was the asset and starting over meant rediscovering all of it the hard way.<br>that risk is gone. AI can read the old code, surface every corner case, and reproduce them in a clean rewrite in days. the wisdom is portable for the first time.<br>building for the project, not for forever

this is the part that took a while to internalize.<br>in college nobody refactored their problem set. nobody wrote test coverage for it. nobody documented it. you built it to compile, you turned it in, you got the grade, you never opened the file again.<br>of course, security still matters. of course stability still matters. but a LOT of the legacy code was neither really secure or really stable. disposable software, written responsibly, can be very secure.<br>every working engineer in 2026 is back in problem-set mode. build the thing, ship it, model gets better, build it again. the artifact has the same lifecycle as a college assignment.<br>this is not bad engineering. this is RATIONAL engineering. the cost of doing it the “right” way -- writing for maintainability, documenting decisions, keeping a clean architecture -- is now higher than the cost of just regenerating the whole thing in 6 months. when the input price changes, the optimal behavior changes.<br>june code is obsolete by december

if a week of work today becomes a day of work by december, everything shipped in june is already 80% obsolete by the time it deploys.<br>there is no point streamlining something about to be torn down. no point writing style guides for code nobody will ever read. no point pretending you are building a cathedral when what you are actually building is the third draft of a sandcastle on a schedule with the tide. code no longer needs comments that will be read by humans.<br>the software industry spent thirty years optimizing for the wrong constant. the constant was never “code is expensive to write.” it was “code is...