Español

Step The Diff With Review Next File

The agent finishes. Nine files are marked as changed, and the biggest, friendliest button on the screen says Accept All. Clicking it takes one second and feels like progress. What it actually does is hand the shape of your codebase to something that can't explain its reasoning to you afterwards. Cursor ships the alternative right there in the same panel: a button called Review Next File.

What blind accepting actually costs

The failure mode isn't that agents write bad code. Often they don't. The failure mode is that you stop knowing what your code does. As one experienced developer put it after building a whole app this way, the biggest problem with indexing your entire codebase and one-shotting it is that you will not be able to understand your code, and you will lose control of it. Later, bugs surface that you would never have imagined — the kind that break in production in ways you'd have sworn were impossible.

That's a comprehension debt, and it compounds differently from ordinary technical debt. When a colleague sends a pull request, you both share a mental model: you know roughly what they intended, you can ask them why, and the diff is scoped to one stated goal. An agent's diff has none of that. It may have quietly renamed a variable in a file you didn't mention, collapsed two functions into one because that made its edit simpler, or changed a call signature and every call site. Every one of those decisions is reasonable in isolation and invisible in bulk. Reading the diff is the only place you get to find out.

What Review Next File does

After an agent run touches multiple files, Cursor surfaces a Review Next File button. It shows you, one by one, all the files that have been changed. Click it and you land on a single file's diff at line level: this line removed, this line added. You read the change, decide whether it's what you wanted, and accept that file. Then you move to the next one.

The finish condition is built in and unusually clean: when every changed file has been reviewed, the button is gone. Its absence is the signal that all your changes have been handled — you don't have to remember how many files were in the batch or keep a tally on the side.

That per-file granularity is the whole point. Accept All is a single decision about an unknown number of changes. Review Next File turns it into a sequence of small decisions, each one made with the actual diff in front of you.

How to run the loop

1. Let the agent finish its turn. Don't touch Accept All.
2. Click Review Next File.
3. Read the line-level diff for that file: what was removed, what was added, and whether the change matches what you asked for.
4. Accept that file. It's done.
5. Click Review Next File again for the next one.
6. Repeat until the button disappears. That's the batch fully reviewed.

While you're reading, the useful questions are the ones a code review of a human's work would ask, plus one extra. Does this change do what I asked? Did it also do something I didn't ask for? Would I have written it this way, and if not, is the difference a real improvement or just a different habit? The extra one, specific to agents: does this edit assume something about the rest of the codebase that I know isn't true?

Go step by step in the first place

The review loop gets much easier upstream. A prompt like "build me the entire app and let's see what happens" produces a diff so large that reviewing it honestly costs more than writing the code would have — which is exactly the situation where people give up and click Accept All. Ask for one coherent step, review it, then ask for the next. Small batches are what make per-file review sustainable, and per-file review is what keeps small batches honest.

How this differs from the neighbouring safety nets

• Review Next File is the pre-landing check. You read the change before you agree to it. It's the only one of the three that protects your understanding rather than just your files.
• Restore checkpoint is recovery after a bad edit has already landed. It reverts your files to a point earlier in the conversation. Indispensable, but by then the change happened, and restoring throws away the good edits in that turn along with the bad one.
• Running the code before you keep everything is runtime verification. It answers "does this work?" — a different question from "do I understand and endorse this change?" A diff can be wrong in ways that still run perfectly: a subtly changed default, a swallowed error, a shortcut that only holds for the input you happened to test.

Use all three. But note that only the first one leaves you knowing what changed.

Pitfalls

• Scrolling a diff isn't reading it. If you're pattern-matching on "looks fine" rather than reading what was removed and what replaced it, you're doing Accept All slowly.
• Deletions deserve more attention than additions. New lines announce themselves. A removed line — a guard clause, an await, an error branch — is the change most likely to matter and least likely to catch your eye.
• A batch too big to review is a prompt problem, not a review problem. If the honest answer to a twenty-file diff is that you won't read it, the fix is upstream: ask for a smaller step and review that instead.
• Accepting is not verifying. Reviewing every file tells you the code is what you intended. It doesn't tell you it runs. Do both.