Cognitive load in code review: what it is and why agents make it worse

Cognitive load in code review is the working memory a reviewer spends to understand a change. Some of it goes on the change itself, which is the work you actually want them doing. The rest goes on assembling the change out of a diff: opening files, holding names, jumping to a definition, scrolling back to check what a variable was called four files ago. That second kind carries no information about whether the code is correct, and it is most of the cost. Xia and colleagues followed 78 professional developers across seven projects and 3,148 working hours, and found that about 58% of their time went on program comprehension. Reviewing is that activity with a deadline attached.

Where the term comes from

Cognitive load theory came out of John Sweller's work in the late 1980s on why some problem-solving practice teaches people nothing. His argument was that human working memory is small enough that the way material is presented can consume all of it, leaving nothing for the actual learning. Later work in the field splits the load into the difficulty inherent in the material, the load added by how it is presented, and the effort that goes into building a durable mental model.

That middle category is the one worth caring about in review, because it is the one you control. The difficulty of a distributed transaction is what it is. The difficulty of understanding a distributed transaction spread across eleven files in the order git happened to list them is a choice somebody made, usually by not making it.

Working memory is where reviews fail

Nelson Cowan's 2001 review of the evidence put usable short-term storage at roughly three to five chunks, revising George Miller's earlier and looser figure of seven. A pull request that touches twelve files is already two or three times past that limit before anyone has read a line.

The reviewer's working memory is the scarcest resource in the pipeline, and the only one nobody measures. We track cycle time, pickup time, review time, comment counts, defect escape rates. None of those tell you the thing that determines whether a review was any good: whether the reviewer ever held the whole change at once.

What people do instead is chunk. An experienced reviewer collapses "these four files are the new HTTP client" into one item and carries that item forward. Chunking is why a senior engineer reviews faster, and the same study by Xia and colleagues found senior developers spend less time on comprehension than junior ones. The chunks are prebuilt. They come from knowing the system.

The twelve-files problem

You open the pull request. Twelve files. You open the first one alphabetically, which is a config change you cannot evaluate yet because you do not know what it configures. You open the second, a test, which references a function that does not exist in your head. By file five you have a partial model of three subsystems and you are holding six names. By file eight you go back to file two, because it turns out that was the important one.

Nothing in that description is about code quality. All of it is load spent on reconstructing a structure that the author already knew and did not write down. Cowan's three-to-five chunks ran out somewhere around file four, and everything after that is you paging your own memory to disk and back.

This is the problem reviewing a pull request you didn't write is really about. Unfamiliarity is a chunking gap: you have no prebuilt items, so every file costs full price.

Why agents make it worse

Two effects, and they multiply.

The changes are bigger. LinearB's 2026 Software Engineering Benchmarks, drawn from 8.1 million pull requests, put AI-assisted pull requests at 408 lines at the 75th percentile against 157 for unassisted ones. More material, same working memory.

The changes have no reading order. A human building a feature leaves a trail of intent behind them: commits in the order they thought of things, the interesting file first, a description flagging the part they were unsure about. An agent emits the whole change at once, correctly, with every file looking as important as every other. The load that a human author would have absorbed by structuring their own work now falls on whoever opens it.

There is a cause underneath both. The reviewer's prebuilt chunks are going stale much faster than they used to. When your team shipped ten changes a week, your model of the system was a few months behind at worst. With agents in the loop it can be a week old, and a week-old model means the chunking advantage that makes senior reviewers fast stops applying. That argument is in your mental model of the codebase is one week old, and it is the reason we started building diagrams at all.

What this costs, measured

The visible symptom is pickup time. LinearB found AI-generated pull requests wait 4.6 times longer for a reviewer to pick them up, over 16 hours against roughly 200 minutes, while the review itself runs faster once it starts, about 194 minutes against 252. Reviewers are correctly pricing the load before they take it on, and deferring accordingly. I unpack those numbers in why AI-generated pull requests wait 4.6 times longer for review.

Is this just another way of saying the pull request is long?

No, and the difference decides what you do about it. A 600-line change that adds one endpoint and its tests is long and cheap: one chunk, read top to bottom, done. A 200-line change that alters a shared type, a migration, two call sites and a feature flag is short and expensive, because understanding it means holding four things at once and knowing how they interact. Line count is a bad proxy for load. Number of things you have to hold at the same time is a good one.

Which is also why the answer to a hard review is rarely "split the pull request". Splitting a change with genuine element interaction just spreads the same interaction across several reviews, and now nobody sees it whole. The team ends up with the load intact and the picture gone. The Coldtea essay behind PR Lens makes the same point about the one part of review that cannot be automated: keeping a shared understanding of how the architecture is moving.

What actually lowers it

The lever is presentation, since the inherent difficulty of the change is fixed and the reviewer's memory capacity is fixed.

A description that names the change in the system's terms, rather than restating the diff, saves a reviewer the first five minutes. A commit history that reads in order saves them the next five. Both are cheap and both mostly vanish when an agent writes the pull request.

The larger saving comes from handing over the structure directly. If the reviewer can see which components the change touches, which are new, which were removed, and how they connect, the chunking work is done for them and their working memory is free for the question that matters, which is whether any of it is a good idea. The method for doing that by hand is in the complete guide to reviewing AI-generated pull requests.

That is why PR Lens draws a pull request rather than summarising it. A summary is prose about code, so the reviewer still has to map it back onto files. A diagram is the shape itself: components as cards, calls as routes, green for new, amber for changed, red for gone, with the untouched parts of the system still on the page so the change has somewhere to sit. Whether that lands as one comment on the pull request or on the canvas with a walkthrough playing through it, the job is the same one. Move the load off the reviewer's memory and onto the page.