How to review AI-written pull requests

Write down the intended behaviour before reading the implementation. What should change for the caller, and what must remain unchanged?

Find the handler, command, or public function that receives the input. Follow its calls rather than accepting the alphabetical order of the diff.

Read enough surrounding code to identify permissions, validation, and existing contracts. A correct function can still be wrong for the system that calls it.

Trace one ordinary input through the changed logic. Name the conditions, processing order, stopping rule, and output.

Then choose an input that challenges an assumption: an empty collection, a duplicate item, an unavailable dependency, or a value at a boundary.

For example, sequential stock allocation gives earlier orders priority. Sorting those orders changes who receives stock, even if the total allocation stays constant.

Treat an AI explanation as a hypothesis. Check it against the implementation, especially when it claims that ordering or failure handling does not matter.

List what the code does beyond returning a value: network calls, notifications, queued jobs, file writes, and changes to shared state.

Check when each effect happens. If a request fails halfway through, can it leave a notification sent but the underlying operation incomplete?

Reason through retries and concurrent requests. Identify whether repeating the operation creates duplicates, and whether two callers can overwrite each other.

Read the stored-state changes beside the logic that depends on them. Check transaction boundaries, constraints, defaults, and how existing records behave.

A new field needs more than a successful migration on an empty database. Consider records created before the field existed.

For a deployment with mixed application versions, check that old and new code can coexist. Ask how rollback would handle data already written.

If the PR changes no stored state, skip this stop. Reading order should clarify the change, not create empty ceremony.

Match each meaningful behaviour change to an assertion. A test that executes code without checking its result provides weak evidence.

Ask whether the test would fail if the new logic were wrong. Watch for mocks that remove the exact dependency or failure being tested.

Include the boundary case you traced earlier. For user-facing changes, try the flow yourself rather than relying on screenshots or passing unit tests alone.

Passing tests support a mental model; they do not replace one. Missing evidence is a reason to request a test, not to assume safety.

Compare the new behaviour with the previous version. Focus on changed permissions, exposed data, failure paths, compatibility, and irreversible effects.

Separate what you verified from what remains uncertain. Request a specialist review when security, privacy, concurrency, or accessibility exceeds your knowledge.

Use the reading path to organise your review, not to excuse skipped coverage. State any unreviewed files or behaviour explicitly.

Approve when you can explain the meaningful changes and the remaining risks are resolved. An automated approval recommendation cannot make that decision for you.