Here’s a simple test you can apply to any software system you work on:
Imagine deleting the entire implementation.
Not refactoring it.
Not archiving it.
Not putting it behind a feature flag.
Deleting it.
rm -rf src/
If that thought makes your stomach drop, pay attention. That reaction is telling you something important.
It’s not telling you that you’re reckless.
It’s not telling you that you lack discipline.
It’s telling you that you don’t know what would survive.
Fear Is a Signal
Most engineers experience deletion as existential. Code feels like the thing. It’s what we write, review, version, deploy, and debug. Losing it feels like losing the system itself.
But that fear is not inevitable. It’s contingent.
There are systems where deleting the implementation would be inconvenient but not terrifying. You might lose time. You might burn compute. But you wouldn’t lose understanding.
The difference is not bravery or craftsmanship.
It’s where meaning lives.
What Are You Actually Afraid of Losing?
When people say, “We can’t just throw the code away,” what they usually mean is something more precise:
We don’t know exactly what behavior is required.
We don’t know which failures are unacceptable.
We don’t know what invariants must always hold.
We don’t know how to tell if a new version is correct.
We don’t know which bugs are intentional fixes for forgotten edge cases.
Those are not code problems. They are evaluation problems.
Code becomes precious when it is the only place knowledge lives.
Code as a Stand-In for Understanding
For most of software history, treating code as durable was reasonable.
We treated code as permanent because the labor to produce it was the bottleneck. Rewriting was expensive. Re-validation was risky. Implementations accumulated meaning over time. Structure, tests, comments, bug fixes, and tribal knowledge fused into something you learned not to disturb.
That made sense when production was the constraint.
Today, the bottleneck has shifted from production to validation.
Generation is cheap. Confidence is not.
When regeneration is easy, code stops being an asset and starts acting as a cache: a materialized view of understanding that is useful while current, disposable when stale.
The danger appears when the cache becomes the source of truth.
The Deletion Test, Defined
The deletion test is not a recommendation. It’s a diagnostic.
Ask yourself:
If I deleted this codebase and regenerated it from scratch, what would I rely on to decide whether the result was correct?
If the honest answer is “the old code,” then the old code is doing work it shouldn’t be doing.
It’s acting as:
the specification
the test suite
the documentation
the bug database
the definition of correctness
That’s not robustness. It’s entanglement.
Oracles, Not Artifacts
If you delete the code but keep your property-based tests, your contracts, your invariants, and your operational signals, you haven’t actually lost the system.
You’ve lost an artifact.
What matters is whether you still have an oracle: a way to mechanically distinguish “correct” from “incorrect” without referring to history.
Production telemetry can tell you that something changed.
It rarely tells you whether it should have.
Without explicit evaluations, runtime behavior tells you what happened, not whether it was right.
Why This Matters Now
This isn’t a tooling fad. It’s an economic shift.
When generating new implementations is cheap, the cost of uncertainty dominates. Keeping code around because you’re afraid to delete it becomes a liability, not a safety measure.
If you don’t know how you would evaluate regenerated code, regeneration is reckless.
If you do know, regeneration is conservative.
The deletion test tells you which world you’re in.
When Deletion Is Boring
Notice the inversion this forces.
The question stops being “How do we write safer code?”
It becomes “What must exist so that code can be replaced safely?”
That question is harder. It requires deciding what truly matters and making it explicit, testable, and durable. It requires relocating rigor out of the implementation and into the system around it.
Most teams don’t do this because they haven’t needed to.
The deletion test makes the cost visible.
The goal is not to delete everything.
The goal is to build systems where deletion is boring.
Because when deleting code is boring, regenerating it is safe. And when regenerating code is safe, code stops being the thing you’re afraid to lose.
If you want software that can survive regeneration, start by asking what would survive deletion.