Picture the pull request. An agent wrote it: 600 lines across 11 files, a new retry path for a payment webhook, tests green, a tidy description. You scroll through it, nothing jumps out, and you approve before lunch.

Six weeks later that retry path misbehaves during an incident, and the on-call engineer asks who knows how it works. Nobody does. The agent kept nothing from its session. You approved the change, but you never learned it.

That approval felt like a bug check. The research on code review says catching bugs was never most of what review did.

What Microsoft found when it read the comments

In 2013, Alberto Bacchelli and Christian Bird published Expectations, Outcomes, and Challenges of Modern Code Review at ICSE. They watched 17 Microsoft developers do real reviews, hand-classified 570 review comments, and surveyed 873 programmers and 165 managers.

The expectation was clear. In the paper, 383 of the programmers (44%) ranked finding defects as their top reason to review, and so did 44% of the managers.

The comments said something else. The biggest category was code improvements: 165 comments (29%) about readability, consistency and dead code. The second biggest was understanding: reviewers asking why a change was made, and authors answering. Defects came fourth of nine, with 78 comments (14%), and 65 of those were small logic issues such as a wrong expression in an if.

The authors concluded that "code and change understanding is the key aspect of code reviewing." One tester said "understanding the code takes most of the reviewing time." All the interviewees but one said they also reviewed to learn, and a senior developer put the standard this way:

"If you do a code review and did not learn anything about the area and you still do not know anything about the area, then that was not as good code review as it could have been."

A large magnifying glass held over a printed code diff, where the lens shows a small city map instead of code lines, one burnt-orange bug icon sitting off to the side outside the lens
The bug is there, but most of what review produced was a map of the code in someone's head.

Google built review so other people could read the code

Five years later, Caitlin Sadowski and colleagues published Modern Code Review: A Case Study at Google (ICSE-SEIP 2018). They drew on 12 interviews, a survey with 44 responses, and logs for about 9 million reviewed changes.

They interviewed the engineer who introduced review at Google. In the paper's words, the main reason was "to force developers to write code that other developers could understand." Review was also seen as a way of "ensuring that more than one person would be familiar with each piece of code."

Google's developers named four things they expect from review: education, maintaining norms, gatekeeping and accident prevention. The paper's first finding ends with this: "Defect finding is welcomed but not the only focus."

So a study of another company, with different data, lands where Microsoft's did: review catches some bugs, but mostly it leaves one more engineer who understands the change.

The agent took away the first reader

Both studies assume the author understood the code. Review made the reviewer the second person who did.

When an agent writes the diff, the author is a model, and its context ends with the session. The person who typed the prompt may have read some turns and skimmed the rest. The reviewer is often the first human to read the whole change, and often the last.

The Microsoft paper warned that "if the author of a change is the only expert, she has no potential reviewers." With agents, the only expert on a change can be a context window that no longer exists.

Meanwhile the pressure runs the other way. Faros AI's AI Productivity Paradox Report 2025, covering more than 10,000 developers across 1,255 teams, found that teams with high AI adoption merge 98% more pull requests, that average PR size rose 154%, and that PR review time rose 91%. That is more diffs, and bigger ones, for the same number of reviewers. Approving on green tests is the obvious shortcut.

Addy Osmani described the result in March 2026: comprehension debt, "the growing gap between how much code exists in your system and how much of it any human being genuinely understands." His line on approvals: "Engineers approved code they didn't fully understand, which now carries implicit endorsement."

There is evidence on the learning side too. In Anthropic's randomized trial, published in January 2026, 52 mostly junior engineers learned a new Python library with or without AI help. The AI group averaged 50% on the quiz afterwards, and the hand-coding group 67%. Participants who handed the work to the AI scored 39%. Those who generated code and then asked follow-up questions about it scored 86%. The subgroups were small (2 to 7 people) and the task was learning, not reviewing, so treat it as a signal. It points the same way as the review studies: reading and questioning AI output is where the understanding comes from.

Two silhouetted developers at a long table passing a single glowing burnt-orange folder between them, while a robot arm in the background keeps dropping more folders onto a growing stack nobody is opening
Agents add diffs faster than humans read them. The unread stack is the comprehension debt.

Review agent work for comprehension, turn by turn

If review's main output is understanding, change what you do in it.

Read the work in the order it was made. An agent works in turns: it reads, edits, runs a test, edits again. One squashed diff hides that story. If your agent commits per turn, plain git shows the turns oldest first:

git log -p --reverse main..agent/fix-retry

Ask before you approve. The agent is still there. Put the questions to it in the session: why this approach, what else it considered, what fails first. That is the "generate, then ask" pattern from Anthropic's trial (86%, in a group of two), applied to review.

Keep agent PRs small enough to understand. Google's process runs on small changes, usually with a single reviewer. In the Microsoft survey, 798 respondents (91%) said files they don't know take longer to review. Agent code is unfamiliar code by default.

Put the explain-back in the PR. GitHub picks up a template from .github/pull_request_template.md (GitHub docs), so every agent PR opens with it:

## Agent change, explained by a human  - What changed, in two sentences: - Why this approach (ask the agent, then check): - What fails first if it is wrong: - Who else has read this change: Reviewer: approve with one paragraph in your own words. If you can't write it, don't approve yet.

Hand the code-improvement comments to tools. Bacchelli and Bird recommended automating the low-level checks back in 2013, because "Automating these tasks frees reviewers to look for deeper, more subtle defects." Linters and AI reviewers can take much of that 29%. None of them puts the understanding in a teammate's head.

Measure explanations, not bug counts

Bugs caught per review is the wrong scoreboard. The Microsoft data says defects were never most of the output, and an agent PR with zero review comments could be a clean change or an unread one. The count can't tell you which.

Count what review is for. A cheap version: once a week, pick one merged agent PR at random and ask the person who approved it to explain it in two minutes, without the diff open. Ask what it does and where it would break first. Score it yes, partly or no. If "no" keeps coming up, your team is collecting code nobody can explain, and a green CI dashboard will never show it.

Rotate approvers as well. One of Google's reasons for review was that more than one person knows each piece of code. An agent PR that one person skimmed has a bus factor of one at best.

Where Hermes IDE fits

I build Hermes IDE, so weigh this section with that in mind. Hermes runs Claude Code, Codex and other CLI agents in their own terminals, each task on its own branch and worktree. Two parts of it are built for the reading habit above.

Every agent turn is saved, so you can diff or restore any single turn, with undo. The strip under a session, labelled "Agent replies", shows one chip per reply with the lines it changed, and clicking a chip shows that reply's changes.

The Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows changes by turn or by file, with risk flags. A line comment goes back to the agent that wrote that line, so "why did you do this?" lands in the right session.

The Hermes IDE Review Desk in By turn view for a Claude Code task, with two turns listed, turn 1's diff of src/db.ts, the changed files and a drafted commit message
The Review Desk (⌘G) in By turn view: two turns (T1: 3 files +69 −1, T2: 1 file +1 −0), turn 1's diff of src/db.ts, the changed files, and a commit message drafted from the turns.

Hermes doesn't measure whether you understood anything. No tool does that for you; the explain-back is a team habit. Per-turn reading also works without Hermes, through the git log line above. Hermes is free, source-available under BSL 1.1, runs on macOS, Windows and Linux, and is not affiliated with Anthropic, OpenAI or any other agent vendor. Download it or read the code on GitHub.

So what does your team count when it reviews agent PRs? And could the person who approved your last one explain it today, without opening the diff? Tell me in the comments.

If this was useful

Explaining a change you didn't write, with its trade-offs, out loud and without notes, is most of what a system design interview asks of you. The System Design Pocket Guide: Interviews walks through 15 real designs step by step, which makes good practice for the explain-back above. And if you want to read agent work turn by turn, Hermes IDE is free.

System Design Pocket Guide: Interviews — 15 Real System Designs, Step by Step