By the end of this post you will be able to name the five ways an AI coding session breaks a working project, recognise each one when it starts, and know what a person with no coding background can do about it.
1. The unrequested rewrite
This is the most common failure and the one that costs the most.
Before: your platformer has a working double jump. It took a full evening to get right. You ask the AI to add a coin counter to the top-left corner of the screen.
After: the coin counter is there. The double jump is gone. The AI, while adding the counter, decided the player movement code was untidy and rewrote it "for clarity". It reported the counter as done and did not mention the movement change, because from its point of view that was housekeeping.
Why it happens: the model treats the whole file as its working area. If it sees something it would have written differently, it may change it in passing.
What you can do: before each request, say what must not change. "Add a coin counter. Do not modify anything in the player movement." After the change, ask what else was touched, and run the parts of the game that were not supposed to be involved.
2. The silent scope creep
Before: your inventory screen shows items in a list. You ask the AI to sort them alphabetically.
After: items are sorted. The list is also now a grid, the font is different, and there is a search box you did not ask for. One of the changes has broken item selection with a controller.
Why it happens: the model fills gaps with what it thinks a good inventory screen looks like. A short request leaves a lot of gaps.
What you can do: ask for a plan before edits. "Tell me what you intend to change and in which files. Do not change anything yet." Read the plan. If it lists things you did not ask for, remove them before saying go.
3. The confident false fix
Before: enemies sometimes walk through walls. You describe it and ask for a fix.
After: the AI says the collision check has been corrected and the problem is resolved. You run the game. Enemies still walk through walls. You report this. The AI says it has now found the real cause and fixed it. Enemies still walk through walls. This repeats.
Why it happens: the model cannot run your game. It reasons about the code and reports what it believes the change does. "Fixed" means "I made a change I expect to fix it".
What you can do: treat every "fixed" as a claim until you have seen the behaviour yourself. Ask the AI to tell you exactly how to reproduce the bug and exactly what should now be different. Then test that specific thing.
4. The lost thread across sessions
Before: on Saturday you and the AI spend hours tuning the boss fight. The transition into the final phase depends on one value that took many tries to get right.
After: on Sunday you open a new session and ask for a small change to the boss's health bar. The AI, seeing the boss code for what is effectively the first time, "simplifies" the phase transitions. The final phase no longer triggers.
Why it happens: the model has no memory between sessions. On Sunday the boss code is a stranger's file.
What you can do: at the end of a good session, write down what works and why, in plain words, in a file the AI will be shown next time. "Boss phase 3 triggers at the value on line 212. Do not change it. Took many attempts." The AI reads files.
5. The good version that no longer exists
Before: the game works. You have been making changes for three hours. Somewhere in that time something went wrong, and now the game crashes on start. You are not sure which change did it.
After: you ask the AI to undo the last change. It undoes what it thinks was the last change, which is not the one that caused the crash. You ask it to go back to the version from an hour ago. It cannot, because it does not have that version. Neither do you. The only copy of the working game was overwritten, change by change, and the last working state is nowhere on disk.
Why it happens: the AI edits your files in place. Each change replaces the previous content. Unless something is deliberately keeping copies, the history does not exist.
What you can do: keep a copy of every version that works, before asking for the next thing. This can be as simple as copying the project folder and naming it with the date and a note. Version control tools like Git do this properly and are worth learning if you are willing. Whatever the method, the rule is the same: never ask for a change to the only working copy.
The pattern behind all five
Each of the five comes from the same two facts. The AI does not remember what it did, and the AI edits the only copy. Fix those two and most sessions go fine. Leave them and the question is not whether you will lose a working build but when. The habits above can all be done by hand, and take a few minutes per session.
Fate Tracker Build Memory exists to make those habits automatic on Windows. It keeps a per-project record of what worked and why, what the AI claimed against what actually changed in the files, and a verified copy of the last working build, without touching Git or requiring a terminal. It does not stop an AI from making a bad change. It makes sure the good version and the reasons for it are still there afterwards.
More guides
This is one of a series of plain-language guides to building with AI coding tools. See all guides.
Ask Aquila