Pat Before You Merge.

There was a moment, six months ago, when I realized I hadn't actually read a pull request in weeks. I'd been pasting links into Claude, getting back tidy summaries, glancing at them, and clicking approve. The diffs were getting bigger and my reviews were getting shorter, and somewhere in there the math stopped working. The AI was reading the code. I was reading the AI. And then someone downstream was reading my LGTM and shipping the result. Three layers of trust, and the only one actually looking at the code was the one I couldn't ask follow-up questions to in the post-mortem.

I think about that a lot lately, mostly because I spend my mornings now patting an AI on the head before my coffee's gone cold and then making it stop. Some days it ships a finding I'm proud of. Some days it invents a regression that doesn't exist and I have to gently walk it back to reality. Either way, we work together. But the version of "AI code review" I keep seeing pitched in 2026 (paste a URL into a desktop chat, read the bullet points, hit merge) is something else. That version is the rubber stamp with extra steps.

The rubber stamp learned to talk

Rubber stamps started honest. An official had too many forms to sign, so they bought a stamp shaped like their signature to keep up. Within a year the stamp was in the assistant's drawer and the official had quietly stopped reading the forms. The signature was still real. The reading was gone. Every industry that runs into this eventually writes a rule against it. Auditors aren't allowed to sign off on a quarter without touching each material finding. Doctors aren't allowed to countersign a chart they haven't read. The rule is always the same shape: a signature has to mean you looked.¹

Code review is in the rubber-stamp phase right now and almost nobody is naming it. The AI desktop apps got good enough at summarizing pull requests that the cheap move is to feed them a URL, read the summary, and approve. The summary is genuinely good. The diff is genuinely complex. The reviewer's attention is genuinely finite. And the result is a Slack channel full of "LGTM" from engineers who have not, in any meaningful sense, looked at the change. I know because I was one of them.²

“The thing AI didn't take from us was the reading. We handed that over. The thing it can't take from us is the deciding, but only if the workflow forces us to touch each decision individually.”

What I built, and what it deliberately doesn't do

Pat Before I Merge (the repo lives at github.com/jitinmaher/pat-before-i-merge⁴) is a Chrome side panel that sits next to the pull request. Same idea as everyone else's AI reviewer in one respect: the AI reads the diff, with real line numbers attached, and comes back with a stack of findings graded by severity. Where it diverges is the part everyone optimizes out: it doesn't post anything for you. Each finding is a card. The card has the file, the line, the AI's reasoning, and three buttons. One scrolls the diff to that exact row so I can see the code. One copies the text. One posts the comment as a real inline review on the line. The third button is the one this whole essay is about.

The deliberate part is that the AI never posts on its own. No "auto-publish all findings." No "approve PR with one click." No bulk button. Twelve findings means twelve clicks, and each click implicitly asserts: I read this, I agree, I'm putting my name on this comment. That sounds small. It's the whole product. It's the wet signature that I, the reviewer, am still in the loop, not as a checkbox at the end but at every individual finding the AI proposes.

A concrete one from last week, because abstract is cheap. The React team merged a small compiler change: eight lines in `BuildHIR.ts` adjusting which JSX tags count as components. My reviewer flagged it HIGH severity. The logic was correct, but the comment above it would mislead the next reader about which identifiers belonged in the component bucket. It cited line 3417. It hedged carefully: Babel's parser probably prevents the edge case in practice, but the comment should still be precise. I read the finding. I clicked through to line 3417 and read the code. I agreed. Then I clicked Insert, and the comment landed on the line, signed "Drafted via Pat Before I Merge." Two names on the byline because two brains did the work.³

Where the analogy actually breaks, and why that's the good part

Here's the thing I have to be honest about, because just dunking on auto-approval would be cheap and also wrong. The audit analogy isn't perfect. A partner signing off on a quarter is making one decision; a reviewer signing off on a PR is making dozens of micro-decisions all at once. Forcing me to click each finding individually means more clicks per PR, not fewer. There's a real cost to the workflow I'm advocating for, and a reviewer in a hurry will absolutely feel that cost. So let me argue the cost is worth paying.

When I bulk-approve a Claude summary, I save five minutes and get back a review I haven't actually done. When I click through twelve findings, I spend an extra two minutes per PR and I get back something genuinely different: a record that I touched each finding, an opportunity to disagree with the AI on three of them (it happens, last week I rejected two findings that turned out to be non-issues), and a comment on the PR that I'd defend if asked at a post-mortem. That last one matters most. The version of code review where I can't be held to my own LGTM is a profession that's already been outsourced; the click is what keeps the profession.

Here is where the analogy actually breaks in a useful direction. The engineering underneath the click is the part that makes the workflow tolerable instead of grueling. Pat Before I Merge reads the diff three different ways with graceful fallback so the line numbers are always real. The findings are sized to a single glance. The Insert click posts on the exact right line, on the right commit, live on the page. None of that is the headline feature. All of it is why "twelve clicks per PR" feels like a workflow instead of a punishment. The whole thing is open source if you want to verify any of those claims yourself.⁴

The question I now ask every AI feature

Before I get excited about a new AI reviewer, mine or anyone else's, I try to ask the rubber-stamp question out loud:

“When the AI's done thinking, who actually decides what gets posted? The AI, with a bulk "approve all" button at the end? Or the human, by individually touching each finding? Because only one of those is still a code review.”

Most tools, I suspect, will land on the first version, because the second one is slower and slower demos worse. But slower is exactly the point. The bottleneck in code review was never "reading the diff faster." It was "a thoughtful human making a judgment." If the AI removes the bottleneck by removing the human, the bottleneck didn't get fixed. It got skipped. The reviewers who win the next round of this won't be the ones with the fastest AI. They'll be the ones whose tools made the AI take notes and made the human take responsibility.

Patting the AI, taking the review back

This site has always argued for the same loop: pat your AI, give it credit when it earns it, and stay a step ahead. The reason this tool exists is that I noticed I'd quietly stopped doing the third part. The AI did the work; I did the LGTM. Pat Before I Merge is my attempt at putting that loop back together. The AI still reads, still drafts, still gets a pat at the end of a good morning. But the review is mine again. Each finding takes a click and the click takes a read, and the comment on the PR carries both our names because that's actually who did the work.

Some days my reviewer is wrong. It flags a non-issue confidently, I disagree, and we move on, same as I would with a tired colleague. A good teammate is right often, wrong sometimes, and always sitting where the work is rather than shouting from another tab. The bar isn't how smart the model sounds in isolation. It's whether the human is still in the loop at the moment that matters.

And the rest of us? We pat the AI, read every finding, click the line, and take the review back from the rubber stamp we were quietly becoming.

1. 1.The same shape of rule shows up across professions whenever an automation tempts people to sign things they haven't read. Audit-quality regulators require partners to attest to each material finding individually. Medical boards require attending physicians to actually read a chart before countersigning a resident's note. The rule is always: a signature has to mean you looked.
2. 2.GitClear's 2024 and 2025 Code Quality Report: measurable rise in copy-pasted code and "churn" commits across repos with heavy AI assistant adoption. Not a one-to-one proxy for shallow review, but the same direction of drift.
3. 3.The pull request in question: facebook/react #36747, a small compiler change to how JSX tag identifiers are classified. The misleading comment fix was merged.
4. 4.Pat Before I Merge: the open-source Chrome extension this essay is about. MV3, no telemetry, BYO Anthropic key, hosts you choose. Clone, load unpacked, review your next PR with the human back in the loop.