The last save wins
Some people run more than one AI session at a time. One session fixes a bug, another writes documentation, a third tidies up a report. Each one is competent on its own.
The trouble starts when two of them touch the same file.
The notes that kept reverting
On one software project, the AI sessions kept a shared set of written notes: a running log of what each session had done that day, decisions that had been made, and things still waiting on someone. The idea was sound. On that project, each new session started with no memory of the previous day’s work, so the notes were its memory.
Then lines started vanishing. A status update written in the afternoon was gone soon after. Someone would restore it, and later in the day the same thing would happen to a different line. From the outside it looked like the notes were “reverting” on their own.
Nobody was deleting anything. When one session finally investigated properly, it found more than one cause, and none of them involved an error message.
Several sessions were rewriting the same file. Each session that wanted to add a line to the daily log did it the obvious way: take a copy of the file, add its line to the copy, then save the whole copy back over the original. If two sessions did that a few minutes apart, the second one saved a copy that had been taken before the first one’s line existed. The first line was erased, silently, by a session that never knew it was there.
One session raced itself. It sent the instruction to edit a file and the instruction to save that file at the same moment, as a batch. Sometimes the save ran first and uploaded the version from before the edit. The session reported the edit as done, because from its point of view it was.
There were two copies of the notes. Two copies that were supposed to stay in sync had drifted apart, so a line could be present in one and missing from the other depending on where you looked.
Each cause on its own could pass for a fluke. Together they explained why lines kept going missing.
Why restoring the line was not the fix
The first response, more than once, was to put the missing line back. That fixed the instance. It did nothing about the class. The next collision erased something else, and the cycle repeated until someone asked a different question: not “what happened to this line?” but “what lets any line disappear?”
Database engineers have a name for the first problem: a lost update. Two writers each read the same starting point, each make a change, and the last one to save wins. The earlier change is not rejected or flagged. It simply stops existing. It can happen whenever more than one AI session writes to the same file and nothing in the setup prevents it.
The habit: one writer per file, add rather than rewrite
The fix on that project was a short set of rules, and they apply to almost any setup with parallel AI sessions:
- Give each session its own file. Instead of one shared daily log, each session writes its own log, named after the session or the area it works on. If only one writer ever touches a file, there is nothing to collide with.
- When a file truly has to be shared, add to the end of it. Never copy, edit, and save the whole thing back. A true append adds a line without rewriting what is already there, so it is much less likely to erase someone else’s line. You can tell your AI exactly this: “append to this file; do not rewrite it.” Be aware that asking for an append is not a guarantee. Some tools and file-syncing setups carry out an “append” by rewriting the whole file, which brings the original risk back. That is why rule 1 is the sturdier fix.
- Edit, then save, then check. Do not let a session fire off a change and its save as one batch. Make the change, save it, then read the file back and confirm the change is there before moving on.
- Keep one copy that counts. If the same notes live in two places, decide which one is the real one and treat the other as a read-only view.
None of this needs technical skill. It is a sentence or two in the instructions you give your AI sessions.
The check: collide on purpose
You do not need to wait for a real note to disappear to find out whether your setup can lose one. Try to make it happen, on a throwaway file.
Create a scratch file with nothing important in it. Open two AI sessions. Give both the same instruction at the same time: add a line to that file, each with a different, easy-to-spot word in it. Wait for both to say they are finished. Then open the file yourself and look for both words. Repeat it a few times.
If one word is ever missing, you have found your lost update before it cost you anything real, and the rules above are worth adopting now.
If both words are there every time, that is encouraging but it is not proof. The two saves may simply never have overlapped. Treat a clean result as “not caught yet”, and keep the rules anyway if more than one session writes to the same place.
Run the check once more after you change how your sessions work, because a new tool or a new way of syncing files can quietly bring the problem back. And when something you wrote “reverts”, resist the urge to just put it back. Ask what let it disappear. That question is the same one at the heart of reviewing anything an AI produces: the visible symptom is a sample, and the cause is the thing worth fixing. Our guide covers that way of reviewing in more detail.