Review an AI-assisted code change as a change, not a speed claim

Make the proposed change reviewable

Start with the problem, expected behavior, and files intentionally changed. Remove unrelated formatting and generated noise. GitHub's review guidance says small, focused pull requests are easier to understand, safer to merge, and better at preserving useful history. That matters more when code was generated quickly: a large patch can hide accidental scope even if every line looks plausible.

Ask for a short change note: why this approach, what assumptions it makes, what was tested, and where the reviewer should focus. If the assistant produced a summary, verify it against the diff. Do not accept a summary as a substitute for reading the changed files.

Review in a risk-first order

1. Scope: compare the requested change with every modified file.
2. Behavior: trace main paths, error paths, and boundary inputs.
3. Tests: run existing relevant tests and add a regression check for the bug or requirement.
4. Secrets and permissions: inspect logs, config, fixtures, workflow files, and new access.
5. Dependencies: inspect manifest and lock-file changes, versions, purpose, and security signals.
6. Maintenance: check naming, duplication, comments, and fit with local conventions.

GitHub advises reviewers to inspect files individually and use dependency review for manifest or lock-file changes, while still reading the source diff because automated dependency views may not parse everything. Its secret guidance recommends minimum credential permissions and warns that log redaction is not guaranteed for every transformed secret. In practice, search the diff for tokens, private URLs, copied production data, and permissive workflow settings even if secret scanning is enabled.

Require evidence matched to the change

Passing tests do not prove the requirement is correct, but failing or absent tests remove an important signal. Review the test itself: an assistant can write a test that merely restates its implementation or misses the original failure.

Keep speed claims outside the merge decision

A fast first draft may still create review and repair work. The merge decision should use correctness, risk, readability, and evidence. If the team wants to study productivity, measure the whole task separately with the workflow pilot scorecard. The existing coding-study note explains why one measured context should not become a universal claim.

Use the review result to improve the process: recurring unnecessary files suggest tighter prompts or smaller assignments; missing tests suggest a better acceptance template; repeated dependency surprises suggest stronger automated checks. Do not turn one accepted patch into proof that the tool is broadly productive.

Leave a clean record

The final review should say what was checked, which tests ran, what remains uncertain, and who accepted the risk. If the patch changes generated artifacts, deployment files, or data migrations, call those out. Reject or split changes whose scope cannot be reviewed confidently. The goal is not to prove that a person or model wrote good code. It is to make one proposed change understandable enough to accept, revise, or decline.