code-review-and-quality

Review a pull request by first understanding its intent, then checking tests, then walking the implementation across five axes: correctness, readability, architecture, security, and performance. Label every finding with a severity such as Critical, Required, Nit, or Optional so the author knows what must change.

A code review checklist should cover correctness against the spec, edge case and error handling, test adequacy, naming and readability, architectural fit, input validation and secret handling, and performance risks like N+1 queries. It should end with a verification step confirming tests pass and the build succeeds.

A pull request of around 100 changed lines is ideal and reviewable in one sitting, while 300 lines is acceptable for a single logical change. Changes near 1000 lines should be split using stacking, file-group, horizontal, or vertical splitting strategies.

Request changes when there are Critical issues like security vulnerabilities, data loss, or broken functionality, or unresolved Required findings. Approve when the change improves overall code health even if imperfect, since the standard is continuous improvement rather than perfection.

AI-generated code needs more scrutiny, not less, because it is confident and plausible even when wrong. Apply the same five-axis review, verify tests actually test behavior, and never rubber-stamp with an unexamined approval.