Code reviews that actually change outcomes

There is an old engineering truism: submit a 10-line pull request and you will receive twenty comments debating variable naming; submit a 1,200-line pull request and you will receive a single "LGTM 👍" within three minutes.

In most engineering organizations, code review operates as a theatre of compliance rather than a quality filter. Reviewers burn mental energy correcting formatting discrepancies that a deterministic linter should have blocked in CI, while architectural flaws, race conditions, and missing database indices sail into production unnoticed.

The mechanics of review fatigue

Human working memory degrades rapidly when tracking context across more than 250 lines of diff. Beyond that threshold, review turnaround time increases exponentially while defect detection rates drop to near zero.

# GitHub Actions PR Size Enforcement Workflow
name: PR Size Guard
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-size:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Calculate non-generated diff lines
        run: |
          CHANGES=$(git diff --shortstat origin/${{ github.base_ref }}...HEAD | awk '{print $4 + $6}')
          echo "Total changed lines: $CHANGES"
          if [ "$CHANGES" -gt 350 ]; then
            echo "::error::PR exceeds 350 lines ($CHANGES lines changed). Split into smaller stacked PRs."
            exit 1
          fi

If a code review comment can be generated by an automated static analysis tool, it does not belong in human review.

The four tiers of constructive review

High-leverage engineering teams structure review feedback around explicit tiers of severity:

• [Blocker]: Fundamental correctness, security vulnerabilities, or data loss risks (e.g., non-atomic database writes). Must be resolved before merge.
• [Architecture]: Structural concerns that will impede maintainability (e.g., leaking persistence abstractions into domain entities).
• [Question]: Sincere curiosity to understand the author's rationale without implying a mandatory rewrite.
• [Nitpick / Optional]: Minor stylistic preferences. The author is explicitly empowered to ignore or merge without revision.

Stacked pull requests over monolithic branches

Building large features without creating 1,000-line review monsters requires adopting stacked pull requests: breaking a large initiative into 4–5 sequential, independently verifiable diffs (e.g., 1. Database schema migration \(\rightarrow\) 2. Internal domain repository \(\rightarrow\) 3. HTTP handler \(\rightarrow\) 4. Frontend UI integration).

Tools like Graphite or Git branch stacks make rebasing dependent branches seamless, dropping average review turnaround times from three days to four hours.

Restructuring engineering workflows or establishing PR review rubrics? Get in touch.