AI Coding Agent Changed Too Much Code

When a run goes wrong, resist the urge to re-prompt and hope. Narrow it to one symptom first, then make the smallest change that tells you whether you guessed right.

1. 1Stop the run and save the current diff.
2. 2Check whether the task was too broad or missing files.
3. 3Read the failing command, log or review comment out loud.
4. 4Start a smaller run with one clear done state.
5. 5Run the narrowest check before asking for more changes.

Save the diff before you do anything else. Even a run that went badly usually has an edit or two in it that were right, and if you throw the whole thing away you'll just pay for that work again. It's also far easier to read than the transcript when you're trying to work out where things went sideways.

The instinct is to re-prompt, harder. Look, it almost never works. If the agent has already misread the task, adding "please be careful" to the same prompt gives it precisely nothing it didn't have the first time. What actually changes the outcome is new information: the file it never opened, the error text you paraphrased instead of pasting, a boundary tight enough that the ambiguity disappears. When the second attempt fails the same way as the first, that's the prompt telling you something, not the model.

Most of these failures trace back to a gap the run never closed. Usually the agent missed the context that mattered, the prompt never set a boundary, or nothing checked the result before it landed.

Switch to ask mode. The over-edit often starts when you ask agent mode a why question. Ask why some clicks were being dropped and agent mode will take it upon itself to debounce-fix the handler - even when you liked the existing batch behavior and only wanted the explanation.

1. 1Hit undo-all to revert the change you didn't ask for.
2. 2Re-ask the same question in ask mode.
3. 3Read the explanation, then decide for yourself whether to make the edit.

Restore a checkpoint. Agent saves snapshots of your codebase during a session and creates them automatically before making significant changes, capturing the state of every modified file. Click a checkpoint in the chat timeline to preview your files at that point, then restore to revert them. There is also a Restore Checkpoint button on previous requests, and a + button when you hover over a message.

Restoring reverts all modified files to that state, and that is the bit worth pausing on. If a couple of the edits buried in there were the ones you wanted, copy them out somewhere before you restore, because the restore does not ask which ones you liked.

Checkpoints are stored locally and sit outside Git. Cursor's own guidance is to use them only for undoing Agent changes and to use Git for permanent version control, so a checkpoint is a session-scoped safety net rather than a commit you can hand to anyone else.

Which is the argument for committing before a broad run, even a throwaway commit nobody will keep.

Cursor's documented answer is to go back to the plan. When Agent builds something that does not match what you wanted, revert the changes, make the plan more specific about what you need, and run it again. Cursor says that is often faster than fixing an in-progress agent and produces cleaner results. ⇧+⇥ from the chat input rotates you into Plan Mode.

That advice has a boundary, though, and it is the part I'd expect people to over-apply. Cursor also says that for quick changes, or work you have done many times before, going straight to Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. is fine. Replanning a one-line fix is ceremony. The judgement is whether the task had more than one reasonable shape, because that ambiguity is what the plan removes.

For larger changes Cursor's framing is that the hard part is figuring out what change should be made, and delegation comes after that. That lines up with how this failure usually reads on inspection. The agent rarely executes badly. It executes a wider task than the one you were holding in your head, and the plan is where that gap shows up while it is still cheap to close.