Stop asking the agent to fix it
A button stops working. You tell the agent: fix it, the button is broken. It changes something, the button starts working, and the list next to it breaks. You ask it to fix the list. The button comes back. By evening the app works worse than it did in the morning and you no longer remember which version was the working one.
The model is not what is at fault here. The shape of the request is. Fix it is permission to rewrite. The agent cannot see what was already working and was not to be touched: as far as it is concerned the whole project is equally open to change, and it changes everything within reach because you never said otherwise. What it breaks is not the thing it was fixing, but whatever was standing next to it.
The first thing that changes the outcome is separating diagnosis from repair. Do not ask for a fix. Ask for the single most likely cause and a way to confirm it, and say explicitly that no code is to be changed in this message. A cause stated out loud can be checked in a minute, and about half the time it turns out not to be the one you assumed. A repair made after a confirmed diagnosis lands on the first attempt.
Second: boundaries. When you do ask for the change, name the file and the function, ask for the smallest possible edit, and say plainly that nothing else is to be touched. Wording like change only this function and edit nothing else in the project sounds excessive, and its absence is exactly what turns a one-line correction into a rewrite across three files. Ask to see what actually changed before you accept the result.
Third: a point to return to, before every attempt. The commit is not for the sake of history, it is so that a third failed iteration does not cost you the thing that worked this morning. Without it you lose more than the original state: you lose any way of telling which attempt broke the thing next door, and that is the part that takes longest to work out afterwards.
Fourth, and the most useful: the sign that it is time to stop. If after two or three attempts the symptom shifts but does not go away — it moved, it happens less often, it turned up on a different screen — then the cause is not where it is being looked for. The next twenty attempts will not find it. They will spread one problem across the project, and instead of one broken place you will have five slightly broken ones, each of which looks almost fine on its own.
Two different situations are worth telling apart here. A bug is one broken place and you know which one. The aftermath of ten repairs is the same logic sitting in four places in four versions, with the app behaving differently depending on which screen you came in through. The second does not yield to prompting: the work there is not changing behaviour but reconciling the differences, and that requires seeing all of them at once first.
A word on credits and time. The fix-it loop is expensive not because each attempt costs something, but because past a certain point the attempts stop being attempts at the original problem. You are no longer solving it, you are compensating for the previous edit, and every step increases the distance back to the state where everything worked.
In practice it comes down to one rule: the agent should get a narrow task with a known cause, not a symptom. The symptom is your job. The cause is at least half your job too. What is left for the agent is the edit, and it does that well, right up until you also ask it to guess what broke.
If your app has already been through a few of those evenings, none of this will help. These habits prevent the drift; they do not undo the drift you already have. That takes a person reading the whole project and listing the places where the same thing is done in more than one way — dull work, but finite, and done once.