Discuss before diffs, let's rethink PR reviews

PR reviews haven't changed in decades. It's time to shift left.

Rico Sta. Cruz's picture
Written by Rico Sta. Cruz
(@rstacruz) · 5 July 2026

PR reviews haven’t changed in decades. “At least 1 or 2 approvals to merge” is still the default policy everywhere. In this age of AI, it’s time to reflect on our best practices on pull requests.

Too much code to review

10 PRs per person per day. This is now typical of the most productive developers in my org, and I’m sure it’s even higher for some. We’ve increased capacity to write code, but not to review them.

  • Lines of code per developer grew 1.7× from 2022 to 2025 1
  • AI now generates ~41% of new code; daily AI users produce 4× more output 1
  • Task throughput per developer is up 33.7% 2

31% of PRs are merged without reviews according to one 2026 report 2. PRs are either never reviewed, or are taking longer to merge.

  • Code arrives faster than review capacity. Skipping review is the default, not a decision
  • Median time in review is up 441.5%. Reviews that do happen take over 5× longer 2

PR reviews were for strangers, not teammates. Just because it worked for OSS doesn’t automatically imply that it should work for teams.

  • Pull requests originated in open source: a gate for maintainers reviewing code from untrusted external contributors 3
  • In OSS it made sense. Untrusted outsiders need vetting. In teams, it’s overhead dressed as quality 3

Strategy: shift-left code reviews

Let me offer a thesis on a simple change to address all these issues: move the reviews before PRs are written.

  1. Discussions before diffs: Design docs, 10-minute conversations. The review starts before code exists.
  2. Automate agentic code reviews: Delegate grunt work (bugs, style) to agents. Code should be clean by the time humans see it.
  3. Review what the AI can’t: Humans focus on strategy, agents focus on clerical. Make reviews fast.

Discussions before diffs

Organise design reviews before writing PRs. High-level design debates should happen before pull requests are made, not after. Consider:

  • Set a meeting: Grab 1 or 2 colleagues and explain the approach before writing code
  • Write specs: Write tech design docs before coding starts, share with coworkers

Why?

  • This preloads context to your coworkers, drastically shortening their PR review effort
  • These specs are useful for both humans and agents

Prior art:

  • Google front-loads review into design docs as a form of “code review before code is written” 4

Automate agentic code reviews

Reduce review burden with agentic review tools. The time-consuming parts of what humans traditionally do in code reviews can be delegated to AI agents.

  • Requires humans:
    • Convey context and share knowledge
    • Share ownership and accountability
    • Level up junior engineers
  • Partially delegatable to agents:
    • Manual verification
  • Mostly delegatable to agents:
    • Catch logic blindspots
    • Ensure codebase alignment
    • Audit for security issues
    • Identify bugs

The bottom ones are the most time-consuming, and the most automatable. Consider:

  • Automated reviews: tools like Copilot and CodeRabbit catch bugs, style issues, and known patterns
  • Use review-and-fix loops: AI can be automated to request code reviews and triage its comments, such as Claude Code’s autofix 5

By the time PRs are seen by other humans, it should already be “clean”, with most issues and anti-patterns already caught and fixed. See some Prior art:

  • GitHub Copilot code review: 60M+ reviews, >1 in 5 reviews on the platform, 10× growth in under a year 6
  • Anthropic’s internal Claude code review: raised PRs receiving substantive review from 16% → 54%; under 1% of AI findings marked incorrect 7
  • “The same tools generating all that extra code are also the best thing I have for keeping up with it.” — Addy Osmani 8

Review what the AI can’t

Aim to ship PR reviews in 5 minutes. Not by skipping review, but by front-loading it and delegating grunt-work to AI. Prerequisites:

  • Design was debated and approved before code existed
  • AI already caught the bugs, style issues, and known patterns
  • CI passed, tests exist, and the author can explain their choices

The real review already happened before the PR. All that’s left is a sanity check.

Example: from docs to PRs

Pretend we’re working on a 1-week-sized piece of work. Say, your video sharing site needs support comments. How might we do this? We can start by surprising our coworkers with a PR. Why stop at one? It will probably take 20 PRs, and I’m sure AI can write them all in a day.

What’s your first PR? Maybe a database migration. This may not go very well. “Why are we storing this in API service’s Postgres? Shouldn’t it be in Video Service’s DocumentDB?” your colleague might ask. You’ll do a back-and-forth exchange in the comments. You may even get it merged in 2 days if you’re lucky.

Instead, let’s try something different. Start by writing a simple design document. Let’s list down the data model, API, and some key decisions:

Design: video comments

Goals:

  • Add comments to videos
  • Automate spam detection
  • …

Key decisions:

  • Spam detection will be done via AWS SpamDetect
  • No “get single video comment” API - not needed by UI
  • Use API Postgres; access patterns lend well to a relational structure
  • …

Data model:

  • table Comment
    • fields: user_id, body

API surface area:

  • POST /video/:id/comment { body }
  • GET /video/:id/comments { page }

PR plan (tentative):

  1. DB migration
  2. Stub for API endpoints
  3. POST comment endpoint
  4. Comment validation
  5. Spam detection infra
  6. Wire up spam detection
  7. …

How you choose to write this is up to you. The intent-density on this document should be high (ie, more human thought than LLM generated). Hand-rolling it is realistically doable. Alternatively, LLMs today are getting better at architecture and technical writing, and that’s another way to go.

Next, get in touch with 2 other engineers. Organise a design review. “Do you have 30 mins? I’m working on video comments and I’d love to run some ideas past you both.” Present this document and discuss. Alice is going to ask “why are we using AWS SpamDetect? Let’s consider Cloudflare Malguard.” Bob’s going to ask “why do we need APIs when Next.js server actions should be enough.”

Figure it out as a team and reach an understanding.

Once you’re all aligned, you’re now ready to write your first PR. Put yourself in Alice’s and Bob’s shoes: how would you review the DB migration PR now? You’ve already talked about why Postgres works best here. Assuming CI is green, there’s really almost nothing to review.

Take this with you

  • Discuss before PRs. Discussing approach with a colleague saves days of PR comment threads.

  • The PR is not the review. It’s a sanity check on work already done, not the first time anyone thinks about what was built.

  • Delegate the grind to AI. Use automated code review loops. Agents focus on bugs and consistency, humans think in architecture and strategy.

Footnotes

  1. GitClear — AI tool impact on developer output (2025) ↩ ↩2

  2. Faros AI — AI Acceleration Whiplash (2026) ↩ ↩2 ↩3

  3. Stephan Schwab — Pull Requests Were Never Meant for Your Team (2026) ↩ ↩2

  4. Google — Software Engineering at Google, Ch.10: Documentation ↩

  5. Anthropic — Claude Code: Auto-fix pull requests ↩

  6. GitHub Blog — 60 Million Copilot Code Reviews (2026) ↩

  7. Anthropic — Claude Code Review ↩

  8. Addy Osmani — Agentic Code Review (2026) ↩

Rico Sta. Cruz's picture

Written by Rico Sta. Cruz

I am a web developer helping make the world a better place through JavaScript, Ruby, and UI design. I write articles like these often. If you'd like to stay in touch, subscribe to my list.

Comments

More articles

← More articles