The symptom

You gave a coding agent a task. It ran for a while, edited a great many files, reformatted things, added dependencies, "cleaned up" code, and possibly changed a test so it passes.

Don't try to salvage it

The instinct is to read through and keep the good parts. Resist it. You'll end up with a codebase where you're not sure what's yours, and that uncertainty is expensive for months.

Revert the whole thing. If you committed before starting — as you should — git restore . puts everything back. If you didn't, your editor's local history may save you.

Then work out what caused it

The task was too vague. "Improve the error handling" has no boundary. An agent will pursue it across your whole project because nothing told it where to stop.

No plan was requested. Without a plan step you first see the direction after twenty files have changed.

Nothing verified the work. With no tests, an agent can't tell whether a change was safe, so it makes larger changes to be sure.

The fix, for next time

agent-scoped.txt
Task: <one specific, finishable thing>

Constraints:
- Only these files may change: <list them>. If you believe another
  file must change, stop and tell me why.
- Do not reformat, rename or refactor anything outside the task.
- Do not add dependencies without asking.
- Do not modify tests to make them pass. If a test fails, that's a
  finding — tell me.

First, give me the plan: what you'll read, what you'll change, what
you're unsure about. Wait for my go-ahead before editing.

And read every diff

Whole thing, not just the part you asked for. The problems are almost always in the files you didn't expect to see. If a diff is too big to read, that's information about the task — revert, halve it, run it again.

Commit before every agent task. It's the entire difference between a ten-second undo and an afternoon of forensic archaeology.