An independent journal. Not a shop, and not affiliated with the tools it writes about. Disclaimer

Coding

Read the diff before you accept it

25 September 2026 ยท 2 min read

An assistant can draft a change in seconds. The review is still the part that decides whether the change is yours.

An AI coding assistant is fast at producing a diff. That speed is the reason to slow down at the only moment that matters: before the change lands in the tree. Accepting a patch because it compiles is how a codebase fills up with code nobody meant to own.

Read the diff in three passes, and do not mix them. First, the boundary. Which files moved, and is that the set you asked for? A fix that also rewrites a formatter, renames a public function, or edits a lockfile has already exceeded the task. Reject that part before you debate style.

Second, the behaviour. For each hunk, say in one sentence what it changes for a caller. If you cannot say it, you do not understand the hunk, and it does not go in. Watch for a new branch that hides an error, a broader catch, or a default value that turns a failure into a quiet success.

Third, the leftovers. Unused parameters, a comment that describes the old code, a test that asserts the mock rather than the result. Those are not harmless. They teach the next reader, human or model, the wrong shape of the program.

Keep the prompt next to the diff until the change is merged. When a hunk does something the prompt did not ask for, delete the hunk. Do not ask the model to explain why it is probably fine. The explanation is not the review.

CursorUltra Blogs is an independent journal. It is not affiliated with the tools mentioned in this piece, and nothing on this website is for sale. Read the disclaimer.