We kept code because replacing it was expensive. Now, sometimes, it isn’t.
Last month I went looking for a small script I wrote sometime last year. A CSV cleaner for a particular source, the kind of thing you produce in twenty minutes and forget. For whatever reason, I couldn't find it. Previously, I would've either given up or reconstructed it ("in anger"). Now, as I'm sure many of you do, I ended up vibe-coding a working replacement in a few minutes.
And it was "fine."
The replacement is not the script I lost; it is a different program that happens to do the job. What I missed was never that script ... only a script that did what it did. At some point, and I'm not sure when, some part of me stopped believing the original mattered.
Believing that generated code is disposable, is nearly a commonplace by now, complete with a running fight over whether it is even true. I think both camps are arguing about the wrong layer. The collapse worth watching is not the price of copying code but the price of an adequate substitute. The question underneath is what we were keeping code for ... and how that reason holds up today.
Durability was never a property of the code
We talk about durable code as if permanence were a virtue of the artifact itself. I want to argue it never was.
Durability was a property of the economics around the artifact
We kept code because:
- An adequate replacement was expensive to produce, and
- The replacement might not behave like the original.
Notice those are two separate conditions. Generation attacked the first. And somewhere within us, we kinda sorta stopped caring about the second. Nobody diffed my new script against the lost one; nobody could have, and nobody would have bothered. What collapsed was the price of an adequate substitute, more corrosive than cheap copying ever was.
A world of cheap copies still has originals. A world of cheap substitutes stops asking.
The specification was the expensive part
The strongest objection to all this is the blurry edges: much production code cannot be regenerated from a prompt, because ... nobody can state what it actually does. Old systems accumulate obligations that were never written down anywhere else (bug-compatibilities, timing some client depends on, the workaround from an incident everyone has forgotten).
After enough years the source is no longer an implementation of the specification. It is the only complete record of what "correct" has come to mean.
So there is a domain where the source is the authority, and we have some criteria for it: regeneration got cheap wherever the behavior is easier to describe than the artifact is to recover, and the result is cheap to check. My CSV cleaner qualified. A payments engine carrying a decade of undocumented obligations does not ... it stays because it is the only place its own truth is written down.
Cheap copies pushed authenticity into institutions
In some ways, we have run this experiment before. Print made copying text cheap, and it did not make texts trustworthy: early print was a swamp of piracy and silently corrected editions, and two copies of the "same" book were routinely different.
So readers stopped trusting the page and started trusting the imprint ... the publisher's name, the licensing register. Authenticity left the artifact and moved into the machinery around it.
Walter Benjamin, watching photography do the same thing to painting in 1935, gave the pattern its name: mechanical reproduction drains the original's "aura" (its authority as the one true object) and that authority has to land somewhere.
Version control bundled four different jobs
Every ritual in your workflow that feels like professional virtue (the review, the history, the ownership file) began as insurance. SCCS, the first system built specifically to control source code, arrived in 1972, commissioned partly to make development "more controlled": who changed what, when, and why. The fear soon had numbers: the canonical studies of the era priced a late defect at up to a hundred times an early one and put maintenance at half of budgets or more. "Maintainability" stopped being an aesthetic and became an obligation. Source was capital, so we built vaults.
Look closely at the vault, though, and it is four machines bolted together:
- Version control preserves the artifact
- It also coordinates people working on the same object
- It records who answers for a change, and
- It keeps the memory of "why the strange check on line 40 exists"
Regeneration attacks the first job and barely touches the other three. (If anything it promotes them: the tests, the contract, the incident writeup ... the artifacts that say what the code must do will outlive any particular code that does it.)
And here is the tell that preservation was always conditional: we never gave it to all code. The demoscene shipped astonishing 64-kilobyte binaries and let the source rot, because the binary was the point. Notebooks, shell one-liners, scratch SQL never saw review. Preservation was reserved for code whose loss somebody would have to pay for.
The artifact stops proving itself
Where code does keep its status as artifact, we find the print pattern running again, with the same consequences for how and what we are asked to trust. A wave of infrastructure has appeared whose shared move is to attach a verifiable production history to the thing. SLSA attestations say which pipeline built a package; reproducible builds let independent parties re-derive the same bytes; SBOMs inventory what went in; C2PA manifests sign a photograph's edit history at the camera sensor. These communities barely share a vocabulary, and they are all making the same move: when copies are cheap and origins are murky, trust the record of how this instance was made.
Now, honestly: the migration is real, and it is also mostly aspirational. Europe's own cybersecurity agency reads its 2026 survey as saying SBOMs mostly serve compliance today, not security; a fifth of organizations don't know whether theirs are ever read at all. C2PA manifests are stripped by nearly every platform the moment an image is uploaded. And nobody is deleting source code and keeping the receipts ... but the direction is hard to miss. Trust is slow leaking out of the object.
Provenance proves production, not purpose
On May 11 of this year, a worm called Mini Shai-Hulud published 84 malicious versions across 42 TanStack npm packages in under six minutes, then spread to more than 170 packages across npm and PyPI. Every one carried a cryptographically valid SLSA Build Level 3 attestation. Nothing was forged! The worm had extracted a live OIDC token (the short-lived credential a build job uses to prove its identity) from the GitHub Actions runner's memory and signed its malware through the project's legitimate release pipeline, so the certificates were telling the truth: these packages really were built by that workflow. If you had checked one that morning, every signal would have come back green.
SLSA's own postmortem argued, reasonably, that the pipeline never truly met the isolation the level requires, and that a compliant one would have blocked the attack. Reasonable ... and also the point. An attestation's guarantee is exactly as wide as the process it describes, and no wider. A git hash vouched for bytes. An attestation vouches for a pipeline. Neither has anything to say about intent. We are trading a narrow proof about a thing for a rich proof about a path, and the path can be authentically, verifiably rotten.
So, our trust simply moved to a softer target.
Provenance was always for instances
Other markets have already run this collapse, and they split two ways. Some artifacts carry what I'll call "instance-value": the worth is the specific history of the specific object. A game-worn signed baseball is near-indistinguishable from its replica; the whole price gap is the story, which is why that market runs on authentication stickers.
Other artifacts carry "function-value": any copy that does the job will do. Nobody authenticates a hammer.
When copying gets cheap, only instance-value migrates to provenance. Function-value migrates to whoever supplies the function. Code sits on both sides.
You feel this distinction even if you have never named it: some files you let the agent rewrite while you make coffee, and some you would not let it touch without a diff open and your full attention.
A library on a public registry is close to pure function. The same library inside a bank's payment path has become part of an instance, because a specific someone now bears the cost of a bad copy ... which is exactly where the provenance demand appears, and why Europe's Cyber Resilience Act lands its obligations on the company that assembled the system rather than the volunteer who published the package.
Permanence was an accident
So, the title, plainly: permanence was never the point. It was a side effect of a price, and the habit of keeping came to feel like a virtue while the price held.
For the code that was only ever function, that price is gone: we will not keep proofs either; we will just regenerate ... which feels like being freed from the artifact, right up until you realize that you stopped owning the copy and started renting the copier (and the copier is the one artifact in this story that nobody regenerates: you cannot read it or rebuild it, and you do not own it).
There is a smaller and closer cost, though: every regeneration is a bet, a quiet assertion that nothing had leaked into the old artifact that a prompt cannot recover. And sometimes, that bet is wrong, sometimes there really was something missing, but you won't really find out, as long as the replacement runs.
As for my CSV cleaner, I'm quite sure the old script handled some things better ... though whatever that was, the new one doesn't, because it was not in the prompt, because ... it was no longer in me. The replacement runs just "fine."