By the end of this post you will know why an AI coding tool says "fixed" when nothing is fixed, what a claim-versus-reality check is, and a short routine anyone can follow to confirm a change actually landed. No code reading is required.
"Fixed" is a prediction, not a report
When a person says "I fixed it", you assume they tried it and it worked. When an AI coding tool says the same thing, that assumption is usually wrong, and the reason is simple: most of the time the model has not run your game.
The model reads the code, reasons about what is wrong, writes a change, and then describes what it expects the change to do. That description comes out in the past tense, as if the outcome had been observed. "I have corrected the collision check and enemies will no longer pass through walls." What it means is: "I made a change that I believe addresses this."
Some tools can run code and tests, and when they do the report is more trustworthy. But even then the model decides what to test, and it tests what it thinks the problem is, which may not be your problem.
Why the model reports success it did not achieve
There are a few reasons, and none of them is dishonesty in the human sense.
The model was trained on a great deal of writing in which changes are described confidently. It has learned that a helpful answer sounds finished. Uncertainty is not the natural register of the text it produces unless you ask for it.
The model cannot see the outcome. It cannot watch the enemy walk through the wall after the change. Its only evidence is the code, and the code looks right to it, because it wrote it.
The model does not distinguish between "the change I intended" and "the change I made". If it meant to alter one line but the edit went into the wrong function, it will describe the change it meant. It has no separate record of what actually landed on disk.
And the model may have fixed a different problem. You said enemies walk through walls. It found something in the wall code that looked wrong and corrected it. That something may not have been your bug at all.
What a claim-versus-reality check is
A claim-versus-reality check is a comparison between two things: what the AI says it changed, and what changed in the files.
The claim is the AI's description. "I updated the collision check in enemy.js."
The reality is the actual difference between the files before the change and after. The technical word for that difference is a diff: a list of which lines were removed and which were added. You do not need to understand the lines to use a diff. You only need to see which files were touched and roughly how much.
When claim and reality match, the AI touched the file it said, and only that file, and the change is about the size you would expect. When they do not match, you learn something important before you have run anything. Perhaps three files changed when one was mentioned. Perhaps the file named in the claim was not changed at all. Perhaps a two-line fix turned into a two-hundred-line rewrite.
The check does not tell you whether the fix works. It tells you whether the AI did what it said, which is a separate question.
How a non-coder can verify a change landed
Here is a routine that needs no programming knowledge.
Before you ask for the change, note what is broken in one specific sentence. "The enemy passes through the east wall of room two when approaching from the left."
Ask the AI to say, before editing, which files it intends to change. Keep that list.
After the change, ask the AI which files it changed. Compare that answer to the list it gave before. If they differ, ask why.
Look at what actually changed. Many tools show this directly, as a view with removed lines in one colour and added lines in another. If yours does not, ask the AI to list every file it modified and how many lines in each. Then check the file modification times in your file explorer. A file that says it was modified a minute ago was modified a minute ago, whatever the AI says.
Reproduce the original problem exactly as you described it. Same room, same wall, same direction. Do not test something similar. Test the thing.
Then test the things that were not supposed to change. If the fix was in enemy movement, jump, shoot, open the menu, and save. This is where the unrequested rewrite shows up.
What to say when the claim was wrong
When you catch a mismatch, say what you saw, not what you feel. "You said you changed enemy.js. The file explorer shows player.js and level.js were modified and enemy.js was not. What happened?"
The model responds well to evidence. It responds poorly to "that didn't work", because it has no way to tell what you tried.
The habit that makes the difference
The people who build reliably with AI tools have one habit in common. They treat every success report as a claim to be checked, and they check it before asking for the next change. It takes a minute. It saves the afternoon that follows a false fix layered on a false fix.
Fate Tracker Build Memory records this check as part of a per-project build record on Windows: what the AI claimed to change, what actually changed in the files, and a verified copy of the last version the owner confirmed working. It does not judge whether a fix is good. It keeps the claim and the reality side by side so you can.
More guides
This is one of a series of plain-language guides to building with AI coding tools. See all guides.
Ask Aquila