Reviewing changes and pull requests

A pull request (PR) is a proposal: "here are the commits on my branch; please review and merge them." Whether the author is a teammate or an AI agent, the review is where quality is decided. You can do the core of it entirely from the command line — no platform required.

See exactly what's proposed

Before integrating any branch, look at what it actually changes:

git fetch                       # update your view of the remote
git log --oneline main..add-login   # commits on the branch, not yet on main
git diff main...add-login           # the full set of changes vs main

main..branch lists the commits that are new on the branch; main...branch (three dots, with diff) shows the combined change those commits make. Reading that diff is the review.

A review checklist

Go through a change deliberately, not just "looks fine":

• Correctness — does it do what it claims? Check the edge cases (empty input, zero, errors), not just the happy path.
• Tests — is the behaviour covered? Run them. Add the case that's missing.
• Scope — does the diff do only what it should, or did unrelated things sneak in?
• Clarity — will this read well in six months? Are names and structure sound?
• Interfaces — are the seams it touches still honoured (the contracts from the abstraction lesson)?

Reviewing AI-generated changes

This is the practical core of working with agents safely, and it's identical to reviewing a human's PR — with one emphasis: read every line. Agents produce output optimised to look right. The diff and the tests are ground truth; your checklist is what separates "looks right" from "is right." If you can't follow a change, you can't approve it — ask for an explanation, then verify it.

Where to go next

Reviewing finds problems; sometimes you need to hunt one that's already shipped. Next: finding a bad commit with git bisect.