Review the complete change, not the generated code

Why it matters

A generated patch may compile while changing behavior outside the request. A useful review starts with what should change and what must remain unchanged, then connects those requirements to the diff, checks and integration conditions.

Read the evidence

GitHub’s review documentation separates comments, approval and requested changes before merging. Semantic Versioning explains version changes in relation to a declared public API. These are process and compatibility tools; neither a green check nor a version label proves that a particular change is safe.

How to use this resource

Apply this proposed protocol to one small, reversible change. Review generated and handwritten changes against the same acceptance criteria.

• Write one acceptance example and one behavior that must not regress.
• Inspect touched files, configuration, dependency versions and unrelated changes.
• Run checks that exercise the requested behavior, including an expected failure case.
• Compare the dependency’s release notes with the API you actually use.
• Save the tested revision and a practical rollback or recovery plan.

Limits and evidence

This is an engineering checklist, not a completed code audit. Tests only cover what they exercise; passing a build does not establish accessibility, security or correct production behavior. Deployment, destructive migration and access changes need their own authorization and checks.

Put it to work.

• Match every change to a requirement.
• Test a regression as well as the happy path.
• Review configuration and dependencies.
• Record the tested revision and recovery steps.

Go to the source.

Original material, with its own scope and publication date. This note is an explanation, not a CooScope performance test.

1. GitHub Docs — Pull request reviewsLink / source review: 2026-10-04
2. Semantic Versioning — Specification 2.0.0Link / source review: 2026-10-04