AI pull request summaries vs diagrams: why a summary does not cut review time

A summary does not shorten a review because it is the same job in a different font. You still read prose, one sentence at a time, at roughly the speed you read the diff, and you are reading an account written by the model whose work you are checking. A diagram does shorten it, because the shape of a change is taken in at a glance and stays taken in. The numbers behind the problem are LinearB's: across 8.1 million pull requests at more than 4,800 organisations, AI-assisted pull requests run 408 changed lines at the 75th percentile against 157 without assistance, and AI-generated ones wait 4.6 times longer for a reviewer to pick them up.

What a pull request summary actually is

Every review bot now writes one. It reads the diff, groups the files, and produces four or five paragraphs describing what changed, sometimes with a table of files and a walkthrough of the notable edits.

It is a real product and it does two things well. It gives a stakeholder who was never going to open the diff something to read. And it gives you enough to triage: whether this pull request is the small one you can do now or the one that needs a block of time.

What it does not do is reduce how long the review takes once you start. A summary is prose about code, and reading prose about code is the job you were trying to skip.

There is a second problem, and it is structural rather than a quality complaint. The summary of an agent's pull request is usually generated by a model reading the same diff, and often by the same family of model that wrote it. The 2026 study of agent-authored pull requests found 71.58% of review comments on them were written by agents rather than by people. Layering agent prose on agent code produces a thread that is entirely internally consistent and says nothing an outside check would say.

The same pull request, both ways

Take the change in the render at the top of this post. Nine files. Four new components, three changed, two removed.

A summary of it reads roughly like this: the broadcast queue endpoint now writes a job document with a batch size; a new package under packages/broadcast-lib provides payload building and suppression list lookup; a new sendBroadcastBulk trigger sends through the Postmark bulk endpoint at 500 messages per call; the previous processBroadcast trigger and sendSingleEmail helper have been removed.

That is accurate. Read it and then answer these without scrolling: what still calls the removed helper, which lane the new package sits in, and whether the suppression lookup happens before or after the batch is built.

The diagram answers all three in one look, because the answers are positions and lines rather than sentences. The removed pieces are still drawn, struck through in red, with whatever pointed at them still pointing. The new package sits in the cloud functions lane. The suppression call is an arrow you can follow with your eye.

Prose has to be held in working memory in the order it was written. A picture is held in one piece, and you can re-check it in half a second instead of re-reading a paragraph.

Three things prose cannot report

Absence. A summary describes what is in the diff. The interesting question is usually about what is not: a caller left pointing at a deleted worker, a code path that no longer passes through the rate limiter, an error case that used to be handled two layers up. GitHub's guidance on reviewing agent pull requests calls one version of this hallucinated correctness, code that compiles and passes and is still wrong at an edge.

Duplication. GitHub also names code reuse blindness as a red flag: agents reimplement helpers that already exist elsewhere in the repository. A summary reports the new helper as a feature, because from inside the diff it is one. Duplication only looks like duplication when you can see the existing helper at the same time, which means seeing the parts of the system the change did not touch.

Narrative. Salesforce's engineering team described agent pull requests as spanning backend, configuration, tests and UI without preserving the narrative structure a human author would have given them. A summary of an unstructured change is an unstructured summary. It lists rather than explains, because there was no order to recover. Agent pull requests lose the narrative goes into that properly.

What a diagram does instead

Constant reading time is the main one. A summary of a 40-line change is a paragraph; a summary of a 400-line change across twelve files is a page. The diagram of both is one picture, and the bigger change mostly just has more boxes. That is the property that turns a two-minute orientation into ten seconds.

Delta as colour is the second. Green new, amber changed, red gone. You are not told which category a component is in, you see it, and you see it at the same moment you see where it sits.

Context is the third. The parts of the system the pull request did not touch stay on the page, so what you build is a model of the system rather than a picture of a patch. This is the one that catches the duplicate helper and the orphaned caller, and it is the reason a diff-shaped diagram would not.

Order is the fourth, and it needs animation rather than numbers. The data-flow lens runs the steps of the change as a sequence, one dot crossing one arrow at a time. A numbered list of the same steps is prose again.

Where a summary is genuinely better

A diagram cannot tell you why.

It cannot say that the batch size is 500 because that is Postmark's limit, or that suppression is checked at build time because checking per message was costing a round trip, or that the author considered a queue per tenant and rejected it. Intent, tradeoffs, the thing that was tried first and did not work: that is prose, and it belongs in the pull request description written by whoever is accountable for the change.

So the honest position is that they do different jobs and the review needs both. Where I would spend the review budget differently is in the order: the shape first, because it tells you which parts of the prose to read carefully, and the prose second, because by then you know what you are checking it against.

What about tools that already draw something

CodeRabbit generates Mermaid sequence diagrams inside its pull request summaries, as of September 2026. It is a real improvement over four paragraphs, and if that is what your team already has, use it.

The differences are in what the diagram carries. A sequence diagram shows a call order, not the system the calls happen in. It does not colour what is new, changed or removed, so the delta has to come back from the prose. The diagram is written afresh by a model on each run, so the same change can come back with different nodes in a different arrangement, and the shape you learned on Monday is not the shape you get on Thursday. And it draws what the change touched, without the surrounding components that make duplication and orphans visible.

Why Mermaid is the wrong tool for code review is the long version of that, and it is fair to Mermaid, which is excellent for documentation. PR Lens vs CodeRabbit covers the product comparison, including why running both is a reasonable answer.

How this fits a ten-minute review

PR Lens is the version of this I built: each pull request drawn as animated architecture and data-flow diagrams, posted as one comment inside the pull request and redrawn on every push, with drill-downs for the new path and the retired one, and a canvas link where the same diagrams are full size with a walkthrough that tours the change a step at a time.

The effect is on the first two minutes of a ten-minute review, which is the part where you work out what the change touches and whether that matches its title. A summary spends those two minutes. A diagram spends ten seconds and leaves the rest for tracing the one path that matters.

The reason I care about that specific slice, rather than about review tooling in general, is in the complete guide to reviewing AI-generated pull requests: the first pass is the one that decides whether the review happens at all.