The first edit was the good kind. Six files each carried the same 33 lines of near-identical code. I replaced them with one definition used six times. Net result: 126 lines gone and one place to fix things instead of six.
Then the notes lied to me
The handover document from the session before described that block as eighteen lines. It was thirty-three. Its fingerprint of the file matched nothing on disk.
Nobody had done anything wrong. The document was written, then the file moved on, and nothing forced the two back together. That is drift, and on a long project it is constant. You are not just maintaining the software. You are maintaining everything that describes the software, and the second job is invisible until it bites.
The fix was unglamorous: check the file's fingerprint at the start of every session, before trusting a single word of the notes.
Then the product renamed itself
On 9 May, Generations became Genacy. One word. I assumed a find-and-replace.
It took eleven separate decisions. The brand name changes. The company name does not, yet. The domain changes. The database tables keep the old name, because renaming those is a migration and a migration is a risk. The private twin is still called Generations, because that is the feature's name, not the company's. And so on, eleven times.
The lesson is not about renaming. It is that the same word means different things in different places, and only a human knows which is which. This is precisely the kind of job where an AI will do exactly what you asked and leave you with a mess.
The first time stopping paid for itself
Mid-way through a change, Claude stopped and asked. A toggle was passing its state to the save function before the state had changed, so the wrong value would be saved. It had found it while tracing, before writing anything.
That became a standing rule: when something does not look right, stop and surface it rather than carrying on. It costs a minute. It has saved days.
The bug that nobody had hit yet
On 10 May, working on the password screen, Claude ran a trace before touching anything — essentially, pretend to load the whole file from the top and see what happens. The simulation failed at line 1483: something was being used before it existed.
I read it three times before it clicked. Two sessions earlier I had added three declarations after a block that referred to them. In JavaScript that is fatal on a cold load — but only on a cold load.
Every test entered the module through a side door: click a button, open a form. All the side doors worked. The front door was on fire and nothing had tried the front door. The suite was green and would have stayed green for as long as nobody loaded the page fresh.
So: passing tests are evidence the tests pass. They are not evidence the code works. There is no substitute for simulating the whole load, cold, the way a real person's browser does it.
