There’s an intuition that code sitting untouched in a repository is being preserved — that because nobody edited it, it still means what it meant when it was written. The intuition is wrong in a specific way, and the error is worth naming. Code isn’t a self-contained artifact. It’s a set of claims about an environment: that this hostname resolves, that this credential is valid, that this queue exists, that this directory is writable, that this alert reaches somebody who knows what it means. The text of those claims is frozen. The things they refer to are not.

The mechanism is unremarkable once stated. Every day, ordinary work moves the environment: a service gets renamed, a bucket policy tightens, a certificate rotates onto a new issuer, a team reorganizes and an alias stops resolving to anyone, a base image drops a binary that a script quietly assumed. None of these changes are careless — most are improvements, made by people doing exactly their jobs. Each of them silently invalidates some subset of the claims embedded in code somewhere. The question is which code finds out.

Here the asymmetry between hot and cold code becomes sharp. The common path is continuously re-validated by reality, and it gets that for free. If the hostname it uses stops resolving, you know within seconds — not because you tested anything, but because the code ran and reality disagreed with it. Every execution is an assertion against the current environment, and the ones that fail become incidents that get fixed. Hot code is therefore not merely better understood; it is continuously repaired, by a process nobody schedules and nobody gets credit for. The rare path receives none of this maintenance, and receives it silently. Its claims go stale at exactly the rate the environment changes, and the first evidence anyone gets is the day it finally executes.

This makes the failure mode worse than “there might be a bug in there.” A bug is a mistake at authorship, and at least someone had a wrong idea you can reconstruct. Decay is different: the code was correct, remained textually identical, and became wrong anyway. Nothing in the version history marks the moment it broke, because the break didn’t happen in the version history — it happened in a DNS zone, an IAM policy, a rotation schedule. You can read the file carefully, understand it fully, agree that it’s right, and still be looking at something that will not work.

Which is why reading is such a poor defense here, and why the usual instincts underperform. Review checks the code against your model of the environment, and your model is a memory of how things worked when you last had reason to care. Static analysis checks the code against itself. Neither one resolves a hostname, presents a credential, or verifies that the pager route lands on a human. The only thing that tests a claim about the environment is making the claim to the environment — which means the fallback has to actually fall back, the restore has to actually restore, the alert has to actually page someone, in the current world rather than the remembered one. Anything that stops short of contact is checking the frozen half against a frozen model.

The practical consequence is a shift in what a codebase’s dormant regions represent. They aren’t a settled reserve you can draw on when needed. They’re a set of unverified assertions whose confidence decreases every quarter, at a rate set by how fast everything around them changes — which, in an actively maintained system, is fast. The uncomfortable version: the healthier and more actively improved your infrastructure is, the faster your untouched code rots, because improvement is the environment moving. Cold code isn’t stable. It’s just quiet, and quiet is the one signal that never tells you anything.