Cursor
Checking Cursor output before you commit
Cursor's value is that it writes in your repository with context. That same context means a plausible-looking change can reach three files before you have read one.
Take it apart before you sign it off.
A review sequence for agent edits
Start with the file list. If it touches more than the prompt described, stop and ask why before reading further — an unexpected file is the cheapest finding you will get all day.
Then read the entry point, trace one realistic failure, and verify the dependencies. That covers most of what actually breaks, and it does not require reading every line of a large diff.
What stays a human decision
Whether the change belongs in this codebase at all is not a checkable property. Neither is whether the abstraction is the right one. Both are judgement, and both are worth an hour of a senior engineer's time on anything that will live for years.
What Cursor output typically gets wrong
Invented API surface
A method or option that reads correctly and does not exist on the installed version — the defect review tends to approve.
Swallowed failure
Try/catch wrapped around a whole function, returning a default so the page renders while the request is broken.
Scope creep
Refactors in files the prompt never mentioned, which nobody reviews because they were not expected.
Example credentials
A key pasted into a constant so the call would work locally, then committed with the change.
What it produces
- Multi-file edits that touch unrelated modules
- New dependencies added to solve small problems
- Tests written against a mocked version of the API
- Example values committed with real-looking keys
One file
The findings are the same whoever wrote it.
Paste the output and the console returns what the rules observed, with severities you can argue with.