Empirical saved my ass.
Two weeks of work, gone in a single refresh. I knew it had to be somewhere. The AI didn't believe me until memory backed me up, and pointed right at it.
I refreshed prod for the seventh time tonight and saw the homepage we'd replaced two weeks ago.
Not a small drift. The old layout. The old hero. The phrasing we'd stopped using. All of it, sitting there, like the last two weeks of work simply hadn't happened.
I refreshed again. Same.
Ruling out the obvious things
Cache, surely. I hard-refreshed. Cleared site data. Opened it in incognito. Opened it on my phone over LTE. The old homepage, every time.
Deploy, then. The deploy logs were clean. No rollback. No failed build. Nothing in the last hour, nothing in the last day.
git status on main. git log showed everything I'd expect to see. HEAD was where it should be.
So I sat with it for a minute. The homepage looked like it had two weeks ago. The git log said it shouldn't. Both of those things couldn't be true.
I knew the work was real. I'd been in it every day for two weeks. The problem was that nothing in front of me could vouch for it. Every system I'd already checked said the opposite, and I was about to ask an AI to help me find something using the exact same evidence that had just told me it didn't exist.
A question, half rhetorical
I asked Claude Code about it, mostly because I didn't know what else to try.
I wasn't trying to recover anything. I wanted to orient. Was prod stale? Was I going crazy? Was this a deploy artifact I didn't have telemetry for?
It said it would check, and reached for memory before doing anything else.
The detail that didn't fit
The memory said the recent public-site pass had applied a shared public-surface class to the homepage, blog index and post, pricing, docs, and other public routes.
Then the agent did the thing that mattered. It compared that against what was actually rendering and said the contradiction out loud.
That changed the question entirely. We weren't asking "is the cache stale?" anymore. We were asking "where did the work go?"
The push
Here's the part I almost didn't say out loud, because I didn't fully trust my own memory of it. I knew the rework was bigger than the homepage. Pricing, docs, install, the blueprints page, the auth shell. Not just /.
So I pushed:
"but we also reworked all the pages not just the homepage, that's lost as well???"
Memory said yes. The rework had touched every public page except /heartbeat. None of it was in the current checkout.
Where it actually was
This is the part of the story I wasn't expecting.
The work wasn't on a branch. It wasn't in a stash. It wasn't on a tag. It was sitting in an unreachable WIP commit. The kind of commit that gets garbage-collected the next time you run git gc, and nobody ever knows.
The site came back. Every page I thought was gone, rendering exactly the way it had been the morning before.
What actually happened
I want to be precise about what just happened, because the recovery is not the interesting part. The shape of it is.
If you'd asked me at 11:38pm what the worst-case version of this story was, I'd have said this:
"I lost two weeks of work to my own sloppy git."
That's the version where you go to bed defeated, wake up at 6am, and spend a day reconstructing what you can remember.
The version that actually happened was: a memory query held the scope of the work I'd done, and used it to contradict the current state of the filesystem. Twice. The second one verified directly against the recovered tree, not inferred from the visible page.
Memory was holding the receipts. Not as context. As evidence.
That's a use case nobody puts on a landing page.
You pitch memory for tone, for writing style, for "Claude remembers your stack." Reasonable. Demo-able. Safe. You don't pitch it for the night two weeks of UI work appears to vanish, and the only thing that knows what you actually built is sitting in memory. You can't even script that demo. The use case only exists in the moment you need it.
Why it worked
Three things, looking at it the next morning:
It outlived the branch.
Git was confused. The filesystem was confused. Memory wasn't. Recall and source-of-truth have completely different failure modes, which is exactly what made cross-checking them useful.
It carried scope, not just facts.
“We reworked these eight surfaces” is the kind of statement you can use to contradict a checkout. A single fact can't do that. Scope-level memories are the ones that catch entire missing rollouts.
It re-entered the loop at the right altitude.
Not as a hint. Not as autocomplete. As ground truth to test the current state against. Memory was the second opinion in the room, and the only one not also looking at the broken checkout.
The takeaway
You don't think of memory as a recovery tool until you watch it become one.
And then you can't think of it any other way.
Empirical saved my ass on this one.
Start having Empirical save your ass too.
It takes less than 5 minutes to wire up. You might find hard to guess use cases that are clutch.