---
title: "A Coding Assistant Kept Editing a File the Next Build Would Overwrite"
canonical: https://dxdev.com/blog/2026-02-24_five-minutes-to-the-wrong-file/
datePublished: 2026-02-24
---
5 minutes was enough for a coding assistant to make a change that would disappear the next time the site was rebuilt.

I stopped at that number because this was not a rare mistake made after a long, confusing job. It was the first few minutes. The assistant found the right words inside the wrong file, made a tidy change, and gave a confident explanation. Then someone rebuilt the front end and the change vanished.

That is the sort of failure that can make a person feel silly. Everything seemed to line up. The file contained the function that needed changing. The change worked at first. The assistant even had a clean record of what it had done. Nothing crashed. Nothing flashed a warning. The work simply did not last.

The problem was a file that looked like the real one but was not. The site used names such as `ManageRoster260224.js`. The six digits were a date stamp. That dated file was a **generated file**, which means a build process makes it automatically from another file. It is like changing the printed price tag after the store has already set up a machine to print a fresh batch every night. Your pen mark may be visible today, but the next batch erases it.

The real file lived in a `src` folder one level deeper and had no date in its name: `ManageRoster.js`. That was the file meant for editing. When the build ran, it made a fresh dated copy from that source file. The browser loaded the dated copy, which is why the wrong change could look successful for a while. But the next rebuild put everything back the way the source file said it should be.

A person who has watched work disappear once usually remembers. That sting teaches the lesson fast. A fresh coding assistant does not get the sting. It searches for the name it was given, finds the dated file, sees the needed function, and starts working. The search result is not false. It is just pointed at the last copy in a chain instead of the first one.

At first, the answer was conversation. I corrected the assistant in chat, again and again: do not edit the dated file; remove the date and look in `src`. Every new conversation began without the old correction. Then the same mistake returned. It cost the time and patience of repeating a small instruction that should not have needed repeating. Worse, each wrong edit looked finished until the next rebuild proved otherwise.

The useful change was to stop treating that instruction as something I had to remember to say. It became a project rule instead.

The rule applied whenever a code or style file was about to be edited. It gave the assistant a simple map: if the name has a date attached, remove the date, go into `src`, and edit that file. It included a worked example, not just a vague warning. A person reading it did not have to guess what “use the source file” meant in this particular project.

That detail matters. A rule that says “be careful” is like a note on the fridge that says “make dinner better.” It sounds sensible, but it does not tell anyone what to do at 5:30. A rule that says “when you see this kind of name, change it into this other path” is more like a recipe with the ingredients laid out. It can be followed when the person who wrote it is not in the room.

Once that first rule worked, several other repeated explanations were written down the same way. One described the usual shape of a page. One covered the preferred order for functions. One explained how to check a change in the browser. One named the correct local web address for testing. None of them was a breakthrough on its own. Each was a small piece of local knowledge that had been living in someone’s head and getting typed into a new conversation over and over.

I think the important part is not that a coding assistant made a mistake. People make this exact kind of mistake too. The important part is noticing which mistakes keep coming back. A repeated correction is often a sign that the instruction is in the wrong place.

A request in a chat is temporary. It works only if someone remembers to say it, the other side still has room to remember it, and the next conversation starts with the same context. A project rule sits beside the work. It can show up at the moment it matters, even when nobody remembers the earlier lesson.

This is useful well beyond software. Maybe the same customer question arrives every week. Maybe a job has one small handoff that gets missed whenever a new person helps. Maybe an important form is always saved in the wrong folder. Before trying to remind people harder, ask whether the reminder belongs inside the work itself.

The rule cost one paragraph to write. It has already paid for itself several times over: every time a name like `ManageRoster260224.js` shows up again, the assistant strips the date, drops into `src`, and edits `ManageRoster.js` on the first try, no rebuild required to find out it guessed wrong.