Prompting for a Code Review of Someone Else's PR

TL;DR — On your own diff, AI is a checklist. On someone else's, it's a reading aid, and the output must never reach the review thread verbatim. Use it to orient on a large diff, to surface the invariants you don't know because you don't own the module, and — most valuably — to argue against your own objection before you post it. Write every comment yourself, in your words. Outsource the reading, never the judgement.

Why this is a different task

Reviewing your own code is a private act with one participant. Reviewing someone else's is a conversation, and the output has an audience who will draw conclusions about you from it.

That changes the constraint. A slightly noisy checklist is fine when you're the only reader. Post that same noise on a colleague's PR and you've spent their afternoon on issues you didn't think were worth your own five minutes.

The rule: never paste model output into a comment

Not primarily because it might be wrong — because it's unattributed and unfiltered, and people can tell.

A review comment that reads like it was generated says one thing to the author: I did not read your code carefully enough to have my own opinion about it. That's a real trust cost, and on a team it compounds — people start discounting your reviews generally, including the ones where you did the work.

There's a fairness dimension too. The author spent hours on the change. Responding with thirty seconds of unread generated text is an asymmetry they'll notice, even if every point is technically valid.

Use 1: orient on a large diff

The legitimate, high-value case. A 900-line PR in a module you don't own:

Summarise what this change does in five bullets. Then tell me which files carry the most risk and why — where a mistake would be hardest to catch in testing.

This gets you to the important 200 lines in about a minute. You then read those 200 lines yourself, properly. The model didn't review anything; it built you a map.

Use 2: surface assumptions your unfamiliarity hides

The genuine weakness of reviewing unfamiliar code is that you don't know the module's invariants — so you don't notice when they're violated.

What assumptions does this code make about its callers, its threading, and the state of the system when it runs? List them as explicit preconditions.

Now you have a checklist to take to the author: "Am I right that this assumes load() was called first?" That's a question with real content, and it's the kind that reliably finds bugs, because the author often hasn't articulated the assumption either.

Use 3: argue against yourself before you post

This is the use I'd defend hardest, and the one almost nobody does.

I think this leaks the Activity because the listener is registered in onCreate and never removed. Argue the opposite. What would have to be true for this to be safe?

Perhaps the listener is held weakly. Perhaps the framework unregisters it. Perhaps the class is already scoped to the Activity. Roughly one time in five, I find I'm wrong — and I've saved the author a round trip, and myself a public correction.

It's the same discipline as writing a failure scenario: an objection you can't defend against counter-argument probably wasn't ready to post.

Use 4: check tone before you send

Written review is easy to get wrong, and blunt feedback reads more harshly than it sounded in your head — especially across languages and cultures, which on most teams is the default case.

Rewrite this comment to be direct but not dismissive. Keep the technical content identical.

Then edit that into your own words. The model is a mirror here, not an author.

What it can't do

It doesn't know the author. It doesn't know they're new, or that they raised this exact concern in design review and were overruled, or that this is a deliberate stopgap with a ticket. It doesn't know which of fifteen valid points is the one worth spending your relationship capital on.

That judgement is the actual work of reviewing someone else's code. The reading is the part that scales; the judgement is the part that's yours.

The line

AI can help you read faster. It cannot hold the opinion for you.

Review is a social act — a colleague is learning from another colleague, not receiving a report. The moment the author suspects they're talking to a tool rather than to you, the mentoring value of review is gone, and that value was always the larger half.