Every AI code-review tool is racing to replace the reviewer. We went the other way. PR Compass prepares the review — it finds the three files that actually matter, surfaces the context you'd otherwise miss, and hands the work back to the human who's paid to think.
It's not busywork. It's the single best mechanism your team has for mentoring, spotting architectural drift, and building shared context. Automate it away and you automate away your seniority pipeline.
"LGTM, looks good" generated at scale is noise. Confident-sounding inline comments that miss the actual bug are worse than silence. We refuse to generate commentary we can't ground in real repository history.
A 40-file PR has maybe three files worth real scrutiny. The other 37 are renames, generated output, test updates, or trivial. Finding those three is the job. Doing it manually is the waste.
Four common practices in this category. Four we chose the other way. A short manifesto, because the alternative is everywhere.
Posts inline comments on every line.
A trail of nits on the diff
Posts one sticky brief per PR.
A single top-of-thread summary that updates in place. Zero inline noise. Your comments stay yours.
Auto-approves when confident.
LGTM from a robot
Never approves. You still review.
Compass has no approve permission and never will. The human who merges is the human who owns it.
Generates suggestions without context.
Best-practice lint in a trench coat
Grounded in your repo's git history.
Every flag cites the commit, PR, or incident it's reacting to. If there's no prior art, Compass stays quiet.
Replaces reviewer judgment.
Automation as the product
Sharpens reviewer attention.
Triages 42 files down to the 3 that matter — then gets out of the way. Judgment is the job; we protect it.
If you want something that reviews for you, there are ten products for that. We build the one that makes your review sharper.
| Priority | File | Why | Δ LOC |
|---|---|---|---|
| Review | services/payments/webhook_handler.ts | Signature verification rewritten; replaces HMAC path from Feb 2026 incident. | +412 −289 |
| Review | services/payments/retry_queue.ts | Idempotency key now derived from event.id — changes replay semantics. | +188 −94 |
| Review | db/migrations/20260419_webhook_events.sql | Adds unique index on (provider, event_id); backfill not gated. | +61 −0 |
| Skim | services/payments/__tests__/webhook_handler.test.ts | New fixtures mirror handler changes; confirm edge cases match spec. | +204 −18 |
| Skim | lib/crypto/hmac.ts | Constant-time compare extracted into shared util — same behavior. | +48 −12 |
| Skip | services/payments/**/*.snap | Snapshot updates follow from the fixture changes above. 14 files. | +284 −201 |
| Skip | package-lock.json, yarn.lock | Lockfile churn from bumping @stripe/webhook.
Auto-generated. | +87 −118 |
⚠ Heads upThis handler was rewritten once before — and reverted.
Commit a3f912c (Feb 12, 2026) attempted the same HMAC consolidation and was rolled back after a spike in
409 Conflictreplays from Stripe. The retry queue assumed provider-uniqueevent.id, but Adyen re-emits IDs on webhook replay — the new index in this PR will reproduce that failure mode unless the backfill excludesprovider='adyen'.Look for: migration gating, and whether
retry_queue.tsstill normalizes Adyen IDs before hashing.
down path db/migrations/20260419_webhook_events.sqlThe question isn't whether AI should be in the review loop. It's which end of the loop it should be on — the end that does the thinking, or the end that clears the runway for it.