How do we keep up with PR reviews in the age of AI?

1. Scope each PR to one thing

The fastest way to kill review momentum is a PR that does three things at once. Reviewers shouldn't have to mentally untangle which changes belong to the bug fix and which belong to the refactor you snuck in.

• One bug fix, one field, one feature, not all three in the same PR.

• A focused ~1,000-line PR that solves one clear problem is fine. A 300-line PR with three concerns isn't. If you're well past 1,000 lines, that's a strong signal to split.

• Use stacked PRs for larger changes.

• Gut check before opening: can someone review this in one sitting? Does it do exactly one thing? Would you merge it?

2. Don't request review until it's actually ready

Drafts exist for a reason. Moving a PR out of draft is a signal to the team that you've done your due diligence and this is worth someone else's time. If that signal is unreliable, the whole review system breaks down.

Only un-draft if you can say yes to all of these:

• You did a self-review

• All tests pass, including e2e

• Zero unresolved comments (Devin's included)

• You tested it locally for UI/UX changes

• For changes that can be covered by automated tests, you verified it's 100% covered

• All CI jobs are green (except for the pesky Vercel previews)

If any are no, leave it as draft. Drafts requesting review pollute the queue and delay PRs that are actually ready.

3. Cap your open PRs at 5 (drafts count)

Open PRs are inventory. They carry context-switching cost, merge conflict risk, and review debt. If you have more than five open at once, the math doesn't work. You're producing faster than the team can absorb.

If you have 5 PRs open, draft and non-draft combined, do not start something new. Go review your teammates' PRs instead or push through your older work.

4. Put a human voice in your PR description

The description doesn't have to be fully written by you. AI is fine for scaffolding and summarizing the diff. The problem with what we're seeing now is the massive AI-generated descriptions that read like a generic checklist nobody engaged with. They're missing the human element a reviewer actually needs.

• A one-sentence author note on the trade-off you chose, or why this fix matters now, goes further than a long "Key Review Points" / "Human Review Checklist" block.

• If you're shipping code that isn't consumed anywhere yet, say why.

• If AI drafted the description, edit it down and add the context only you have.

5. Prove the fix works

A PR that says "fixes bug X" without evidence is asking the reviewer to take it on faith. Don't make them do that.

• Screenshots, screen recordings, before/after dashboards, whatever shows the bug is dead and nothing else regressed.

• Functional QA is mandatory for UX/UI changes, not optional.

6. SQL and performance changes need real validation

Code review alone can't confirm a query rewrite holds under prod load. Reading a query diff and saying "looks right" is not validation. For PRs touching query paths or rewrites:

• EXPLAIN ANALYZE on a prod-shaped dataset

• Before/after latency numbers or dashboard screenshots

• Feature-flagged rollout for risky changes

7. AI is an accelerator, not a brain

AI can generate code fast. It cannot decide whether that code should exist. The thinking still has to come from you.

• Design first. Sketch the approach, think through edge cases, write a quick note, then prompt.

• After the agent generates, actually read it. Self-review catches Prisma calls in the wrong place, ignored agent guidelines, fragile structure, etc.

• Before opening, ask: what does this touch? Any user impact? Perf or security implications? What's the blast radius if it's wrong?

8. Validate security PRs before opening them

Confirm the vulnerability actually applies to how we use the code. "Fix vulnerability X" PRs that touch sensitive paths can introduce more risk than the original report.

9. Route PRs to the right reviewer

The wrong reviewer wastes two people's time: the reviewer who can't give meaningful feedback and the author who has to wait for a second round with the right person.

• Domain-heavy PRs (Salesforce/CRM routing, team profile migrations, etc.) belong with the domain owner, not Foundation rubber-stamping an AI-generated test suite.

• Changes to core/foundation paths (query infra, hasTeamAccess, etc.) deserve a quick alignment with the owning team before the PR opens.

10. Architecture conversations happen early

Patching the same area three times is a signal, not a coincidence. If you're working around the same limitation again, the right move is a conversation and potential rewrite, not another patch.

Talk to Foundation/Head of Engineering before implementing. That's how the infra modules came together, and consistency compounds.

11. Lighter path for trivial fixes

Not everything needs Foundation review. We should be spending review bandwidth where it matters most.

Toast tweaks, button sizing, mechanical renames, copy changes, mainline features - these can go through AI review and/or team-level reviews. Reserve Foundation review for changes that actually need it.

12. Don't open PRs on behalf of others

If Engineer X is doing the work, Engineer X opens the PR. Otherwise comments land with the wrong person, questions go unanswered, and the PR stalls.