ManageRoster260224.js Looked Right and Was the Wrong File

Five minutes was enough for a coding assistant to make a change that vanished the next time the site was rebuilt.

That number matters because the mistake came in the first few minutes, with no long, confusing job behind it. 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 was gone.

It is easy to feel silly after something like that, because everything had lined up. The file held the function that needed changing. The change worked at first. The assistant even had a clean record of what it had done. Nothing crashed and nothing flashed a warning. The work just did not last.

The file that looked real

The site used names such as ManageRoster260224.js, where the six digits are a date stamp. That dated file is 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 one folder deeper, in src, with 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. 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 it. A fresh coding assistant gets no such sting. It searches for the name it was given, finds the dated file, sees the needed function and starts working. The search result is accurate, but it points at the last copy in a chain instead of the first one.

Correcting it in chat, again and again

At first, our answer was conversation. We told the assistant in chat to leave the dated file alone, remove the date and look in src. Every new conversation began without the old correction, and the same mistake came back. It cost us time and patience to repeat a small instruction that should not have needed repeating. Worse, each wrong edit looked finished until the next rebuild proved otherwise.

Putting the instruction beside the work

The change that helped was to stop treating that instruction as something we had to remember to say. We made it a project rule.

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 instead of a vague warning, so nobody reading it had 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, we wrote down several other repeated explanations 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.

What a repeated correction tells you

People make this exact kind of mistake too, so the assistant’s error is not the interesting part. What matters 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 and can show up at the moment it matters, even when nobody remembers the earlier lesson.

You can use this 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 always gets saved in the wrong folder. Before reminding people harder, ask whether the reminder belongs inside the work itself.

The rule took one paragraph to write, and it has already paid for itself several times over. Whenever 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 is needed to find out it guessed wrong. If you keep giving a coding assistant or a new colleague the same correction, write it down as a rule that sits with the work, and include a worked example.

dxdev LESSON · paste into your AI coding agent
LESSON: A correction you keep typing into chat belongs in a project rule that shows up when the mistake is about to happen
SOURCE: dxdev.com/everyday-ai/five-minutes-to-the-wrong-file
WHAT HAPPENED: A site kept dated generated files such as ManageRoster260224.js, which a build process creates from source files with no date in the name, such as ManageRoster.js in a src folder. A coding assistant found the function it needed in the dated file, edited it, and explained the change with confidence. The next front end rebuild regenerated the dated file and the change vanished. Correcting the assistant in chat did not last, because every new conversation started without the correction.
THE RULE: An instruction that has to be repeated to every new assistant session belongs in a written project rule that names the pattern and gives a worked example, not in chat.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any generated, built, or compiled file (dated bundles, minified output, build folders) sitting where an assistant or teammate can find and edit it by searching for a function name.
  2. Any naming or folder convention that separates source files from generated output but is not written down in a rule file the assistant loads.
  3. Any correction you have given an assistant more than once in chat that has no matching entry in your project rules.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.