Reviewing Work You Did Not Write

Reviewing Work You Did Not Write is where the pipeline now narrows. Producing a change got dramatically cheaper and accepting one did not, so the hour a competent reviewer spends is the scarce resource in most teams. That makes review a career skill rather than a chore, and it makes the record a review leaves behind more valuable than the review itself.

Key takeaways

• Faros AI, which sells engineering-productivity analytics and whose report conclusion supports that business, reports from telemetry across more than 10,000 developers and 1,255 teams that teams with high AI adoption merged 98% more pull requests, with review time up 91% and average change size up 154%.
• Review norms were built for small changes. Sadowski and colleagues' 2018 study of nine million reviewed changes at Google found most changes small, usually one reviewer, and over 80% of changes involving at most one iteration.
• Trust calibration is the named central difficulty of reviewing generated multi-file changes, per a June 2026 participatory design study run with JetBrains. Sonar's January 2026 survey of more than 1,100 developers found 96% do not fully trust that AI-generated code is functionally correct while only 48% always verify before committing.
• Defects persist. A large-scale April 2026 preprint analysing 302,600 AI-authored commits across 6,299 repositories found more than 15% of commits from every assistant studied introduced at least one issue, and 22.7% of tracked AI-introduced issues still present at the latest repository version.
• A review that leaves no record is spent effort. The decision record, one page per architectural decision with its rationale and consequences, is the artifact that makes a review pay twice.

Read this after Chapter 6, since half of what a review argues about is intent that was never fixed, and beside Chapter 10, because review is the most visible place your judgement becomes other people's decisions. If you want the systematic version of knowing whether generated behaviour is acceptable, that is the evaluation argument.

Monday morning, one open change: 41 files, 2,300 added lines, one migration, two new dependencies, and a description that says "implements the export spec".

The tests pass. The author has read it, in the sense that they scrolled it.

The reviewer has ninety minutes before their own work starts. The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

What a review is actually for

Review has accumulated four purposes and they compete for the same hour. Separating them is the first move.

The first purpose is correctness against intent, meaning does this do the thing that was specified. The second is risk, meaning what can this break that we cannot easily undo. The third is comprehension transfer, meaning does at least one other person now understand this well enough to maintain it. The fourth is craft, meaning naming, structure and consistency.

When changes were small, one pass served all four. At 2,300 lines they have to be ordered, and the order is the whole skill.

My ordering is risk, then correctness against intent, then comprehension transfer, then craft. I would put risk first even though correctness feels more fundamental, because a correct change with an unbounded blast radius is more dangerous than an incorrect change you can revert.

Review is where the throughput went

There is telemetry on this and it needs its caveat attached to it.

Faros AI published its AI Productivity Paradox Report on 23 July 2025, drawing on telemetry across more than 10,000 developers and 1,255 teams, with a stated method. It reports that teams with high AI adoption merged 98% more pull requests. Review time rose 91%, average pull request size rose 154%, tasks completed rose 21%, and bugs per developer rose 9%. Faros AI sells engineering-productivity analytics, and the report's conclusion is that engineering productivity requires analytics, so read it as vendor research with real data behind it.

Take those numbers together rather than separately. Twice the changes, each one two and a half times larger, reviewed by the same number of people, in individually longer sittings.

That is not a gain arriving. It is a queue forming. Stack Overflow's 2025 survey supports the felt experience: 45.2% of respondents cited debugging AI-generated code as more time-consuming than debugging their own.

Review norms were designed for small changes

The current norms are not neutral. They were tuned in an era with different inputs, and knowing that makes it obvious why they break.

Sadowski, Söderberg, Church, Sipko and Bacchelli published a case study of code review at Google in 2018, drawing on 12 interviews, 44 survey responses and review logs for nine million reviewed changes. The majority of changes were small, had one reviewer, and drew no comments beyond the authorisation to commit. Over 80% involved at most one iteration. During the week, 70% of changes were committed less than 24 hours after being sent for initial review.

That is a system optimised for small increments authored by someone who understood them. The paper is eight years old. It describes the world the tooling in your repository was built for.

Now change one input. Make the changes two and a half times larger, and make the author someone who did not write them and may not have read them closely. Every norm in that paper stops fitting, including the one-reviewer default and the single iteration.

Trust calibration is the difficulty with a name

The hardest part of reviewing generated code is not technical, and it has been named in the literature.

A participatory design study conducted with JetBrains, published as a preprint in June 2026, identifies trust calibration as the central difficulty in reviewing LLM-generated multi-file changes. It proposes a three-level workflow: overview, then file analysis, then code-snippet review. The percentages in that paper are participants' expectations about a proposed tool rather than measured outcomes, so I am taking the framing and leaving the numbers.

The framing is right. When a human writes a change, you hold a prior on that human: what they are good at, where they cut corners, what they always forget. That prior is most of what makes review efficient. Generated code offers no such prior. It offers a false one instead, because it is uniformly well-formatted and confident.

Sonar's January 2026 survey of more than 1,100 developers puts numbers on the gap. 96% do not fully trust that AI-generated code is functionally correct, yet only 48% always verify before committing, and 38% say reviewing AI-generated code takes more effort than reviewing human-written code. Sonar sells code-quality tooling, which is worth stating. The contradiction between 96% and 48% is the interesting part regardless of who asked.

The defects that survive the merge

The reason this matters is that the defects do not get caught downstream. They stay.

A large-scale study published as a preprint in April 2026 analysed 302,600 verified AI-authored commits across 6,299 GitHub repositories and five coding assistants, using commit-level differential static analysis. It found 484,366 distinct issues, of which 89.3% were code smells. More than 15% of commits from every assistant introduced at least one issue, ranging from 17.4% to 29.1% by tool. And 22.7% of tracked AI-introduced issues were still present at the latest repository version, some introduced more than nine months earlier.

The security picture from that work is the sharper one: the tools introduced roughly 1.5 times as many security issues as they fixed. Veracode's 2025 GenAI Code Security Report, published 30 July 2025, found 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability, rising to 72% in Java.

So the review is the last real gate rather than the first of several. That is a different job from the one code review was designed to be.

My triage order for a large generated change

This is judgement, offered as the thing I would actually do on that Monday morning, and it is the most liftable artifact in this chapter.

The order matters more than the content. Reviewers naturally start at the last row because it is the easiest to have opinions about, and a change can pass a thorough naming review while carrying an unreviewed migration.

In my experience the first pass catches most of the expensive problems in under ten minutes, which is why I refuse to start at line one of file one. If you read nothing else from this chapter, read the change's shape before its contents.

What to send back without reading further

Rejection is a skill and reviewers under-use it, usually out of politeness.

I send a change back unread past the shape pass in four cases. When it bundles a migration with feature work, because those have different rollback stories. When it touches more than one bounded area for one stated reason. When the description does not say what was verified and how. And when the author cannot answer what happens if one step fails halfway, which is a question about their understanding rather than about the code.

That is not gatekeeping. It is queue management. A 2,300-line change split into four is not more work, it is the same work made reviewable, and four small reviews find more than one large one.

The sentence I would use is neutral and reusable: this needs splitting before I can review it properly, and here is the split I would make. Naming the split is what stops it reading as a refusal.

The record a review leaves behind

A review generates knowledge and then usually throws it away, which is the largest waste in the whole pipeline.

Architectural decision records fix the durable part. As documented at adr.github.io, an ADR captures a single architectural decision along with its rationale, including trade-offs and consequences. The practice was popularised by Michael Nygard's 2011 post on documenting architecture decisions. One decision, one short file, dated, in the repository.

The connection to review is direct. Every review conversation ending in "fine, but do it this way because of X" is a decision with a rationale, and it currently lives in a comment thread nobody will find in eighteen months. Write it as a record and link the review to it. The next person to touch that code inherits the reasoning instead of rediscovering it.

There is a career effect too, and it is not subtle. The decision record is the most legible artifact of judgement an engineer can produce, because it is dated, attributed and checkable against what happened next. Chapter 10 is about that legibility becoming your output.

The objection: this makes me the bottleneck

The objection is real and the framing is wrong, so both parts need answering.

The real part: if you review carefully while others merge quickly, your queue grows, your own delivery slows, and the metrics that get discussed favour the people generating rather than the person gating. That is a genuine political cost and pretending otherwise is useless.

The framing error is that the alternative is not faster. It is a different cost centre. The unreviewed change becomes the incident, and the incident takes your week anyway, with an audience. What careful review actually does is choose when to spend the time.

So the move is to make the constraint visible instead of absorbing it. Report review time as work, publish the triage order so it is a team rule rather than your personal strictness, and push the split-changes requirement into the contribution guide. In my experience a reviewer who states the rule in advance is treated as rigorous, and one who applies the same rule silently is treated as slow.

Chapter summary

Review has four competing purposes, being correctness against intent, risk, comprehension transfer and craft. At 2,300 lines they must be ordered rather than served at once, with risk first, because a correct change with an unbounded blast radius is worse than an incorrect one you can revert. Faros AI, which sells engineering-productivity analytics and whose conclusion supports that business, reports from telemetry across more than 10,000 developers that high-adoption teams merged 98% more pull requests, with review time up 91%, average size up 154% and 9% more bugs per developer. That is a queue forming rather than a gain arriving. Existing norms were tuned for the opposite inputs, and Sadowski and colleagues' 2018 Google study of nine million reviewed changes found most changes small, usually one reviewer and over 80% with at most one iteration. Trust calibration is the named central difficulty for generated multi-file changes, per a June 2026 study with JetBrains, because generated code denies you the prior you hold on a human author. Sonar's January 2026 survey found 96% not fully trusting functional correctness while only 48% always verify. Defects persist too. An April 2026 preprint on 302,600 AI-authored commits found 22.7% of tracked issues still present at the latest version, alongside Veracode's 45% of samples introducing an OWASP Top 10 vulnerability. The triage order is shape, contract, failure, logic, then craft. Four cases justify sending a change back unread, and every review ending in a reasoned decision should leave a decision record behind it.

The next threshold is what happens when nobody can specify the work for you at all. Chapter 8 is Being Trusted With Ambiguity, which is how problems with no agreed definition of done end up assigned to particular people, and what those people did to get them.