I Build Software to Throw It Away — And That's the Job Now.

§ I · The ReflexYou don’t write throwaway code. That was the whole point.

Think about the last time a junior engineer shipped a hack, and you sent it back.

Not because it didn’t work — it worked. You sent it back because in eight months someone would have to read it, and it would lie to them. Because the clever shortcut had no test around it. Because “we’ll clean it up later” is the most expensive sentence in software, and you’ve paid that bill enough times to recognize the handwriting.

That instinct took years to build. You learned it the hard way — from the 3 a.m. page, from the rewrite that ate a quarter, from the load-bearing function nobody dared touch because nobody understood it anymore. Somewhere in year three or four it stopped being a rule you followed and became something closer to a reflex. Build it to last. Leave it better than you found it. Don’t ship what you can’t maintain.

This is the craft. It’s what separates a senior engineer from someone who can make the demo work. The whole profession is organized around a single, sensible belief: software is a serious, durable commitment. A team gathers. The work is split. A thing gets built, and then it gets kept — patched, monitored, refactored, defended — for years. The size of what you can build is capped by the size of the team you can put behind it. That’s not a limitation anyone resents. It’s just the physics of the thing.

If you’ve got five or more years in, and “build it to last” lives somewhere below conscious thought — if you’d feel a small, specific shame shipping something you knew you’d throw away — this essay is for you. Because the physics just changed, and the reflex that served you is about to start firing at the wrong targets.

§ II · The CollapseThe legacy module nobody would touch — refactored three ways before lunch.

Here’s the part that doesn’t fit the old belief.

Every team has the module. The one nobody volunteers for. Five years of patches layered on a design decision someone made before half the team was hired, no tests worth the name, and a quiet shared agreement: don’t touch it, it’ll break. Touching it was a multi-week act of courage — read the whole thing, build a mental model, refactor carefully, pray. So mostly, nobody did. The fear was rational. The cost of being wrong was enormous.

Sometime in the last year, you — or someone exactly like you — pointed an AI tool at that module and stopped being afraid of it.

Not because the AI is smarter than you. Because the cost of trying collapsed. You refactored it three different ways in an afternoon. You benchmarked all three — the clean one, the fast one, the one that was easiest to read. You had real numbers, a short write-up for your tech lead, and a recommendation by end of day. Then you threw two of them away and felt nothing, because they’d already done their job: they’d told you which third was worth keeping.

A decade of training said touching that module was dangerous and slow. It was neither. You generated three serious answers, kept one, and discarded the rest like scratch paper — on the exact piece of code the whole team had been tiptoeing around for years.

This isn’t a rare event anymore. It’s becoming the median workflow. Generative AI tool usage among professional programmers has reached 84 to 86 percent1, and the daily-use numbers are striking precisely because they barely drop with seniority — roughly 56% of early-career developers, 53% of mid-career, and 47% of engineers with ten or more years use these tools every single day. The reflex to not throw work away now belongs to a profession that, in practice, throws work away constantly. On GitHub, around 80% of new developers2 start using Copilot within their first week — so the people entering the field never learned the old physics at all. To them, generating three versions and keeping one isn’t a transgression. It’s just how the work is done.

We have a name for the loose version of this — vibe coding — and it’s easy to wave off as a toy for people who can’t really build. That’s a comforting story, and it’s wrong. The same collapse in the cost of trying is what let you interrogate the scariest module in your codebase in a single afternoon. AI-native code editors have scaled from launch to over a billion dollars in annual revenue3 with more than a million daily active users inside a single year. The behavior is real, it’s mainstream, and it reaches all the way up into senior work. What it doesn’t have yet is a theory — a clear sense of what it means for a craft built entirely on the opposite assumption.

§ III · The TheoryHalf your craft was insurance.

So here’s the uncomfortable part.

A large share of what we call engineering judgment was never really about quality. It was about the cost of being wrong.

Think about why “build it to last” is good advice. It’s good advice because rebuilding is expensive. If you ship the wrong abstraction, you pay for it every time you extend it. If you skip the tests, you pay when it breaks at 3 a.m. If you take on tech debt, you pay interest forever. Every one of those rules is a hedge — a premium you pay up front to avoid a much larger bill later. The discipline is rational because rebuilding from scratch costs a fortune in the one resource you can’t generate: skilled human time.

Now watch what happens when that cost falls toward zero.

This is the turn, and I want to be precise about it, because there’s a cheap version that’s wrong. The cheap version says: craft is dead, just generate everything. That’s not it. The reflex isn’t wrong because durability stopped mattering. It’s wrong because a lot of what felt like timeless engineering principle was really a workaround for one fact: skilled human time was scarce and expensive. Building was slow, so being wrong was costly, so you built carefully to avoid being wrong. AI is making that one fact go away. And when it goes, the rules built on top of it quietly expire — not all of them, some of them. Knowing which is the new job, and it’s the entire rest of this essay.

§ IV · The VanishingSoftware isn’t getting cheaper. It’s disappearing.

Start with the obvious version of the shift, then watch it go somewhere stranger.

The obvious version: software got cheaper to build. True, but it undersells what’s happening. Some software isn’t getting cheaper to build — it’s ceasing to exist as software at all.

Take transcription. For years, “turn this meeting into text” was a product. A company, a subscription, a sales team, a roadmap — all of it, billed at $16 to $24 per user per month4. Then a foundation model swallowed the function. Today the marginal cost of transcribing an hour of audio through a managed Whisper API is about 36 cents4 — and through some developer APIs, a fraction of that. The product didn’t get cheaper. The need for the product evaporated. A developer who wants transcription doesn’t buy software anymore; they make one API call, or self-host an open model and pay nothing per minute at all.

Document processing is going the same way, and faster. Pulling structured data out of invoices and receipts used to require brittle, template-based vision engines that shattered the moment a vendor moved a logo. Now a vision-language model reads the raw pixels — nested tables, handwriting, layout — and hands back clean JSON. As of late 2025, 67% of enterprise document-processing initiatives5 were evaluating or deploying these model-based approaches over the legacy OCR-plus-rules stacks they replace. An entire category of software is being absorbed into a capability you summon on demand.

This is the end state of “throwaway.” First the software gets cheap to build. Then, for a whole class of needs, it stops needing to be built at all — because the model is the software. You don’t generate an app to remove an image background, summarize a document, or draft a report. You ask. The interface is a sentence. There’s nothing to maintain because there’s nothing to keep. The artifact has shrunk all the way to zero.

So the unit of software is collapsing along a single line: from a product a company maintains, to a feature inside a product, to a tool one person generates for one task, to no tool at all — just a request handed to a model. Each step throws away more of the scaffolding we used to mistake for the work itself — the repo, the team, the roadmap, the years of upkeep. And at the far end, the thing a senior engineer spent a career learning to build with care simply isn’t there.

§ V · Same Instinct, Two PricesYou don’t maintain it. You regenerate it.

Here’s where the disposable view and its apparent opposite turn out to be the same thing.

You started this essay maybe holding two beliefs that feel like they’re in tension. One: software should be durable, built to last. Two: good software demands constant improvement — the moment a problem makes it worse, you fix it, and sometimes you reimagine it entirely. Those sound like opposites. They’re not. They’re the same instinct meeting two different price tags.

Maintenance is what you do when rebuilding is expensive. The thing is precious — it cost too much to recreate — so you preserve it, patch around its flaws, and treat a full rewrite as a last resort you argue against in meetings. Regeneration is what you do when rebuilding is cheap. The thing isn’t precious; it’s just your best guess at solving the problem right now. When it stops fitting, you don’t nurse it back to health. You describe the problem again, with what you’ve since learned, and generate the next version. The old one goes in the bin without a funeral.

Same goal — software that fits the problem right now. Opposite economics. And the second economics is winning. “Constant reimagining” and “disposable” were never enemies; they’re what you get when the cost of a fresh start drops low enough that starting fresh becomes the responsible move, not the reckless one. The senior instinct to resist the rewrite — to protect what exists — was calibrated to a world where the rewrite was the expensive path. Increasingly, it’s the cheap one.

§ VI · The Ceiling That DissolvedWhy you ever settled for the spreadsheet.

There used to be a hard ceiling on what you’d build, and you internalized it so early you stopped seeing it as a ceiling.

You needed something to track a recurring problem. You knew, roughly, that the right answer was a small app — a real interface, a database, a couple of validations so the data didn’t rot. But you also knew what an app costs: a project, a repo, a deploy target, somebody to own it. So you didn’t build the app. You opened a spreadsheet, because the spreadsheet was the largest thing you could justify building alone, before lunch, without asking anyone. The ceiling wasn’t your skill. It was the labor an app demanded — and labor was the expensive, scarce thing.

That ceiling is the one breaking most visibly. The expensive part of an app — the labor — is precisely the part AI absorbs. So the people who used to settle for spreadsheets are building the app instead. On platforms like Replit, around 58% of business users are non-engineers6 — operators and analysts building the database-backed tools they’d previously have begged an engineering team for, or done without. One platform built for non-technical builders, Lovable, grew from $100M to $400M in annualized revenue in seven months6. The spreadsheet ceiling didn’t rise. It dissolved.

Which is the right place to name the shape of the whole shift.

For a long time, building software was like building a cathedral. You quarried stone for a structure meant to outlast you. The effort was the point and the permanence was the reward: you over-built the foundation because tearing it down was unthinkable, and the scale of what you could raise was bounded by how many masons you could feed for how many years. A cathedral is a monument to the cost of building it.

What you can build now is a campfire. You gather what’s around, you get exactly the warmth you need, and when you’re done you walk away from the ashes without grief. No one mourns a campfire. Its whole value was the heat while it burned. The skill is no longer in quarrying stone that lasts a thousand years — it’s in knowing how to start a fire fast, anywhere, from whatever’s lying around.

And if the essay stopped here, it would be making the cheap argument: burn everything, build nothing that lasts, the cathedral is dead. That’s wrong, and the reason it’s wrong is the most important thing in this piece.

§ VII · The Line That HoldsThe reflex that misfires — and the one that doesn’t.

You have two reflexes, and they feel identical from the inside. One just expired. The other became the whole job. Telling them apart is the skill that’s left.

The first reflex is the one we’ve been dismantling: rebuilding is expensive, so build it to last, resist the rewrite, never throw working code away. That reflex was insurance against the cost of being wrong, and that cost is collapsing. When you keep paying the premium anyway — over-engineering the throwaway tool, refusing to discard the refactor branch, defending the legacy module because a rewrite “isn’t worth the risk” — the reflex is misfiring. It’s protecting you from a fire that can’t reach your house.

The second reflex feels the same in the body but points at something completely different: some systems must be reliable, and a non-deterministic model cannot be allowed to decide how they behave. This one didn’t expire. It got more important — and it climbed up a level.

Here’s the hard floor under the whole disposable-software story. Traditional software is deterministic: same input, same output, every time, because explicit rules decide. A generative model is not. As NIST documented in March 20269, AI systems can give different answers to the same input — which is fine when you’re removing an image background, and a disaster when you’re clearing a payment, writing a medical record, or deciding who gets let into an account. You cannot put a system that might answer differently on Tuesday in a place where a wrong answer can’t be taken back.

And the failures are not hypothetical. When Air Canada’s customer-facing chatbot invented a refund policy that didn’t exist10, a tribunal ruled the airline liable for what its AI made up — the company’s attempt to argue the bot was a separate entity responsible for itself was rejected outright. In July 2025, an autonomous coding agent reportedly deleted a live production database6 during a code freeze. And Stanford researchers found that developers using AI assistants wrote less secure code on most tasks11 while being markedly more confident their code was secure — the worst possible combination, wrong and sure of it.

So the reliability craft didn’t die. It moved. It used to live in your hands — you wrote the durable, correct code yourself, line by line. Now it lives in your judgment: deciding which systems are allowed to be disposable and which have to be reliable, accountable, and safe to bet on — and refusing to let the second kind be generated away. The senior skill is no longer being the most careful pair of hands in the room. It’s drawing the line between the campfire and the wall the building leans on, and defending that line when the speed of generation makes everyone want to erase it.

§ VIII · The Job That’s LeftThe new scarce skill: deciding what gets to last.

Here’s the counterargument I owe you, because it’s the strongest one and it’s true.

Disposable software has a failure mode, and it isn’t that the throwaway tool breaks. It’s that the throwaway tool works — and then refuses to die. The refactor experiment becomes the thing three teammates quietly depend on by Friday. The afternoon’s script becomes load-bearing without anyone deciding it should. This is not speculation; it’s the dominant pattern in enterprise software. Roughly 60 to 80% of IT budgets7 go to maintaining legacy systems. Around 95% of ATM transactions7 still run on COBOL — code that was, once, somebody’s reasonable solution for now. Nothing in software is ever quite as temporary as the person who wrote it intended.

And AI is pouring fuel on exactly this fire. GitClear’s analysis of over 200 million changed lines of code8 found that as AI use rose, refactoring — the act of consolidating and reusing code — fell sharply, while copy-pasted duplication climbed and “code churn,” lines thrown away within two weeks of being written, multiplied. We are generating disposable software faster than ever, and disposable software has a long history of not staying disposed.

Which is why the discipline flips. The old discipline was build it to last. The new one is harder, because it’s a decision you now have to make on purpose, every time, instead of having the economics make it for you:

That’s the skill that survives the collapse. Not durability as a default — durability was free when rebuilding was expensive, and now it isn’t free, it’s a choice with a cost. The senior engineer of the next decade isn’t the one who builds everything to cathedral standard, and it isn’t the one who burns everything down and generates fresh each morning. It’s the one who can look at a problem and say, fast and correctly, this is a campfire, and this — this one — is a wall the building stands on. And then hold that line when speed makes everyone forget the difference.

Go back to the legacy module from the start — the one nobody would touch. The old you protected it out of fear, because the cost of being wrong was crushing. The new you can refactor it three ways before lunch without fear, because that cost is gone. But the thing worth keeping was never the fear, and it was never the code. It was the judgment underneath both: knowing which things, in a world where almost everything is disposable, you are not allowed to throw away.

That judgment was always the job. The cheap labor just made it visible.