How to review a pull request you didn't write, in a codebase you don't fully know

Review the boundary, not the internals. What the change touches, what it calls, what calls it, what it removed: those are checkable without knowing the history of the repository, and they are where the structural mistakes live. This matters more every month, because there is a lot of code arriving that nobody has read. A 2026 study of 33,596 agent-authored pull requests, "These Aren't the Reviews You're Looking For", found 61.38% of them received no recorded review at all, and 71.58% of the review comments that were written on them came from other agents.

I do this constantly. Most of the pull requests I look at now are in code I did not write, sometimes in a service I have opened twice. The reflex is to feel unqualified. That reflex is expensive, because the alternative to your partial review is usually no review.

What you actually need to know to review a change

You do not need to know the codebase; you need to know what this change assumes about it. Those assumptions are finite and they are usually visible:

• That a component it calls exists and behaves the way the call implies.
• That a component it removed has no live caller left.
• That the data it writes is read by something, in the shape it wrote.
• That the boundary it crosses, if it crosses one, was meant to be crossed.

Every one of those is checkable from the change plus its immediate neighbours. None of them requires you to have onboarded. And the Coldtea essay behind PR Lens makes the point that used to be less true: stale knowledge of a codebase was once about three months old, and with agents committing daily it is now about a week old. Everyone is reviewing a codebase they half know now, including the people who wrote it.

Start from the map, not the file list

A file list in an unfamiliar repository is worse than useless, because the names look like they mean something. services/notify/dispatch.ts tells you nothing about whether dispatch is a queue consumer or an HTTP client, so you guess, and you carry the guess into everything you read afterwards.

What you want first is a map of the neighbourhood: this change, drawn against the components around it, with the calls between them. Salesforce's engineering team described why this hurts more with agent output than with human output: agent pull requests span backend, config, tests and UI in a single change without preserving the narrative structure a human author would have used. There is no first commit that sets up the shape and no second commit that uses it. It all lands at once.

So build the shape yourself before you read anything, or have it built for you. That is the whole reason PR Lens exists: it draws each pull request as animated architecture and data-flow diagrams inside the pull request itself, with new components in green, changed in amber, removed in red and struck through.

The parts it did not touch stay on the page

This is the part that matters for unfamiliar code, and it is the reason a diff view cannot do it. A diff shows you only what changed. A map of the change shows you what changed inside the system that did not.

That surrounding context is what you are missing when you do not know a codebase, and it is exactly what the change's author, human or agent, had in front of them. Seeing an unchanged store sitting next to the new writer tells you the write has a reader. Seeing a struck-through worker with an arrow still pointing at it tells you something is about to call a thing that is gone. Neither fact is in the diff.

Three questions that need no prior knowledge

1. Does the shape match the title? One sentence describing what the change does to the system, checked against what the pull request claims to do. A mismatch here invalidates everything you assume afterwards.
2. Does one path hold together? Pick the path the change exists for and follow it from entry point to whatever it writes, including the failure branch. You are checking coherence, which is a property of the change and not of the codebase.
3. Does anything deleted still have a caller? Search the repository for the names of what was removed. This takes twenty seconds and it is the check most often skipped by reviewers who feel they lack standing to comment.

There is a fourth question I ask when the code is genuinely foreign, and it stays off the list because it is optional: what do the tests around these files already assume? Test files are the cheapest documentation in a repository. They are written in the vocabulary of the domain, they state the expected behaviour in a few lines each, and an agent's change either fits those assumptions or quietly stops meeting them. Ten test cases read faster than one service.

Those three fit inside the same ten-minute clock as everything else in how to review a 400-line pull request in ten minutes.

What to do about the parts you genuinely cannot judge

Name them. A review that says "the structure is coherent, I traced the upload path and it holds, I cannot judge the tenancy check in authorize and it needs someone who owns that" is a good review. It moves the pull request forward and it tells the author exactly whose eyes are still needed.

The failure mode is the opposite one: reading the whole diff, finding nothing you feel confident about, and approving because it looked fine. The study above found that agent-steering commands appear in 25.92% of reviews of agent pull requests against 1.63% for human ones, which tells you how much of this review traffic is now humans nudging a machine rather than judging a change. Partial, honest review is worth more than a rubber stamp with a full read behind it.

In a monorepo, the neighbourhood is the unit

The hero image on this post is a monorepo-wide refactor: six lanes, thirty-seven components. Nobody reviews that as one thing. What makes it reviewable is that the lanes group the change by where it landed, so you can take the lane you know, check its edges, and hand the rest to the people who own the other lanes.

That is also the practical answer to "who should review this". The right assignment is one person per lane who knows its edges, and no single reviewer who is expected to know all six. A drawn change makes that assignment take seconds, because you can see which lanes were touched before anyone opens a file.

Handing it to someone who knows it better

When you hit the part you cannot judge, the fastest thing you can do is give the owner the picture rather than the diff. Every PR Lens comment links to a canvas where the diagrams are full size, with pan, zoom and a walkthrough that steps through the change one part at a time. Sending that link with "the bit I need you on is step three" is a smaller ask than "can you look at this 400-line PR", and it gets answered sooner. Explaining a change without walking someone through the diff covers that in full.

Before you approve anything, the nine boxes in the checklist for agent-authored code are the ones that do not require you to know the repository, and the complete guide to reviewing AI-generated pull requests has the method they came from.