Journal · The AI Architect · 2026-08-20
Save a good version before you change it. Label the moment — "works, before the redesign" — so you can step back.
Save a good version before you change it. Label the moment — “works, before the redesign” — so you can step back.
The real tension isn’t about backups. It’s about trust — specifically, whether you trust your future self to remember what “good” felt like once you’re three hours deep into a redesign that isn’t working. You will not remember. Not because you’re careless, but because the version of you who is frustrated and half-convinced the whole thing is broken has a different memory than the version of you who was calmly satisfied an hour ago. These are, functionally, two different people making judgment calls. The tension is that we treat our own past confidence as retrievable information, when it’s actually a feeling that evaporates the moment things get hard.
Confidence doesn’t leave a trace
When something is working, you rarely stop to document why it’s working. It just feels obvious. The button does the thing. The function returns the right value. The essay’s third paragraph finally says what you meant. That obviousness is real, but it’s not stable — it lives in your head, not on the page. Once you start changing things and the obviousness disappears, you’re left trying to reconstruct a feeling from memory, usually while also trying to fix whatever broke. Those two tasks fight each other. You end up half-debugging, half-guessing whether the thing you’re chasing ever actually worked or whether you’re misremembering.
This is why the label matters more than the save itself. Most people who lose good work still technically had a copy — an old file, a version in some folder, a browser tab they didn’t close. What they didn’t have was a fast way to know that this specific copy was the one where things were fine. Digging through five unlabeled versions to find the good one, while stressed and short on time, defeats the purpose of having saved anything at all.
Try this: before you touch a piece of work you’re happy with, save a copy and name it in plain language describing the state, not the date. “Works — before adding the search feature.” “Reads clean — before I try the shorter opening.” Skip version numbers; they tell you nothing about what you’d be stepping back to.
The redesign has an opinion, and it’s not neutral
Once you’re mid-change, you’re no longer a neutral judge of the original. The redesign has convinced you, at least a little, that the old way was flawed — that’s usually why you started. This creates a quiet bias: even if the new version is worse, you may not see it clearly, because admitting it means admitting the detour cost you something. A labeled checkpoint fixes this by giving you an external reference that doesn’t care about your investment in the redesign. It just sits there, unbothered, saying “this is what worked.”
Stepping back to that checkpoint isn’t defeat. It’s closer to what a good editor does — reads the draft, then reads the earlier draft, and asks plainly which one does the job better, without worrying about whose feelings get hurt. You can only do that honestly if the earlier draft still exists in a form you can quickly return to and compare against, not one you have to reconstruct from a mash of half-finished changes.
Labeling is a decision, not a chore
People resist this step because it feels like admin — an interruption before the real work of changing things. But the label is actually a decision point disguised as busywork. Writing “works, before the redesign” forces you to notice, right now, that you consider this a good state. That noticing is valuable on its own, independent of whether you ever roll back. It turns a vague sense of things being fine into a concrete claim you made, at a specific time, that you can hold yourself to later.
Try this: make the label a sentence, not a tag. Not “v3” but “layout works on mobile, before restructuring nav.” A future reader — often you, a week later — needs the sentence, not the shorthand.
None of this requires new tools or discipline you don’t already have. It requires one pause, before the change, where you say out loud or in writing: this is good, here’s why, and here’s where it lives if I need it back. That pause is cheap. Not taking it is what gets expensive, usually right when you can least afford it.
I go further into this in the book — how it connects to the broader habit of designing so you can always retreat to solid ground, and why that habit changes how boldly you’re willing to experiment in the first place.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.