The New Review Culture

Three pull requests sit in a senior engineer’s queue by ten in the morning. One came from a junior developer who wrote every line by hand and got a database join slightly wrong. One came from an agent a different junior directed with a single sentence of instruction. One came from an agent the same junior directed after writing out a page of acceptance criteria first. All three need a decision before lunch, and the senior engineer already knows, without opening any of them, that the second and third diffs will take longer to trust than the first — not because the code is worse, but because there is no author on the other end of the diff to ask a clarifying question.

This is not a complaint about volume, though volume is real and rising. It is a recognition that code review has always quietly done two jobs at once — catching what is wrong before it ships, and teaching the person who wrote it something they did not know before they wrote it — and that an AI-authored pull request only has somewhere for one of those two jobs to land. The code still needs catching. There is no longer a person on the other side of it who benefits from being taught about the diff.

What the review-time number is actually measuring

This volume is not the first place in the Library to lean on the finding that anchors it. A ten-thousand-developer dataset — the same one that closed this Library’s systems-thinking volume and opened its verification volume — found AI-assisted teams completing 21% more tasks and merging pull requests at nearly twice their prior rate, while organization-level delivery metrics stayed flat and median code review time grew 91%. That figure was re-verified directly for this chapter rather than taken on the strength of how two earlier chapters described it, and the same publisher has since posted a 2026 update to the same page reporting the review-time gap widening past 400% on newer data — not narrowing on its own as teams adjust.

Generation got faster. The stage that has to decide whether the output can be trusted did not get any faster on its own, and it absorbed the difference. What this chapter adds to that finding is not a new number — it is an account of what has to change in how a team runs review once that absorption becomes the normal condition, rather than a temporary backlog to burn down.

The two jobs review was doing

Gatekeeping is the job everyone names first, because it is the job with a visible failure mode: a defect ships, an incident follows, someone asks how review missed it. It is standards enforcement and correctness checking, and it is functionally the same job whether the author sat at the keyboard or an agent did. Mentorship is quieter, and until recently ran almost automatically alongside gatekeeping without anyone scheduling it — a senior engineer reading a junior’s diff was also, at no extra cost, watching how that junior reasoned, correcting a habit before it calcified, modeling how a hard trade-off actually gets weighed. This volume’s own chapter on skill formation in the AI era describes what happens to that automatic channel once juniors stop writing the boilerplate that used to carry it. This chapter is about what happens to the review conversation specifically, once an agent — not a junior — is the one who produced the diff sitting in the queue.

A diff with no one on the other end

Reviewing an agent’s code for correctness and reviewing a junior’s code for growth are different cognitive tasks wearing the same interface — a diff, a comment thread, an approve button — and most teams have been running both through that one interface without ever deciding whether it still makes sense. Correctness review asks whether this specific change is right. Growth review asks whether the person who made it is improving at making changes like it. An agent has no memory that carries a comment from last week’s diff into this week’s; whatever pattern it repeats, it repeats because the pattern lives in its context or its training, not because a lesson from a reviewer stuck. Leaving feedback on the code an agent wrote, in the hope that the feedback lands somewhere useful, is a category error — there is nowhere for it to go.

What does not disappear is the person who directed the agent: who wrote the prompt, chose the scope, decided the acceptance criteria were tight enough to trust, and either caught or missed what the agent got wrong before sending the diff along. The mentorship function of review has somewhere to land after all — it just has to be redirected, deliberately, from the code to the human who produced the request that produced the code. A senior engineer reviewing an agent-authored pull request from a junior is not teaching that junior to write a better join. They are teaching the junior to scope tighter tasks, write acceptance criteria an agent cannot quietly misread, and recognize the specific ways this particular agent tends to fail — judgment that carries into the next session even though none of today’s code will.

The mentorship function of review does not disappear when the author is an agent. It loses its target and has to be pointed somewhere else, on purpose, or it stops happening at all.

On redirecting code review’s teaching function

Tiering the queue instead of drowning in it

Doubling review volume while holding every pull request’s review depth fixed is not a strategy a team can sustain, and organizations actually living through the doubling have converged, independently, on the same fix: stop giving every diff the same depth of attention and start deciding depth from risk instead of from who — or what — wrote it. GitHub’s own guidance for reviewing agent-authored pull requests, published after Copilot-assisted review had crossed sixty million reviews and more than one in five reviews on the platform involved an agent, recommends a tiered pass that spends its first minutes classifying blast radius before spending any minutes reading logic line by line. Engineering writer Addy Osmani’s independent framing of the same shift, from a June 2026 piece specifically on reviewing agent output, is blunter: tier by risk, not by author. A configuration change earns a linter and a glance; a payments path earns the full stack, regardless of whether a human or an agent wrote either one.

None of this requires a new signal set invented for review specifically. It is close to the same six inputs this Library’s workflow-engineering volume already specified for a checkpoint’s confidence score in its Checkpoint Thinking chapter — file count, dependency reach, scope-boundary crossings, context utilization, historical success rate, known failure patterns — pointed at a different gate. A checkpoint asks whether a plan step still looks right partway through a session. A review queue asks the same question about a finished diff. Feeding a review queue the evidence a checkpoint already computes, rather than standing up a second scoring system from scratch, is the cheaper and more consistent path to the same tiering.

Pairing with agents: moving the cost earlier

The other real adaptation underway is not about the queue at all — it is about not letting a diff reach the queue cold in the first place. Reviewing a finished pull request means reconstructing intent after the fact: what was this agent trying to do, what did it rule out, why does this particular approach look the way it does. Staying present while the agent generates — reading the plan before it executes, correcting scope on the first exchange rather than the fifth revision, watching the first file land instead of the fortieth — moves that same reconstruction work earlier, to a point where it is far cheaper to do. Some teams are formalizing this as a deliberate practice rather than leaving it to habit: a June 2026 piece from Thoughtworks describes review mutating from an asynchronous, after-the-fact gate into something closer to a working session — a senior engineer, a junior engineer, and an agent moving through the same loop, with the human attention spent on the plan and the early diffs rather than saved up for the finished pull request.

This is the same instinct this Library’s workflow-engineering volume already named twice under different covers: a Flight Plan gives a session something to check itself against before any code exists, and checkpoint thinking gates a plan step rather than waiting for the whole session to finish. Pairing with agents during generation is that discipline applied to review specifically — trading a cheap interruption early for an expensive reconstruction late. It does not replace tiered review of the finished diff; a sound plan can still go wrong in execution. It does shrink how much reconstruction the finished diff requires, and that reconstruction is the actual expense the 91% figure is measuring.

Rubber-stamping is a trust failure, not a volume failure

Doubling volume creates real pressure toward two different collapses, and this Library has already named the mechanism behind both, one volume over, in its Trust Calibration chapter. A team that starts waving through every diff above some threshold — because the agent has been right often enough lately that reading feels like wasted motion — has replayed automation bias against its own review gate. A team that keeps reading every line regardless of tier, because trusting the tiering feels irresponsible even after the tiering has held up, has replayed algorithm aversion against a system it built for the specific purpose of being trusted where it has earned trust. Neither failure requires the tiering itself to be wrong. Both are, in that chapter’s own terms, a calibration problem wearing a diligence costume.

It is worth being plain about how thin the evidence specific to review-culture adaptation still is, as of mid-2026. The headline figure — 21% more tasks, review time up 91%, delivery flat — comes from one dataset, run by one analytics vendor, and has not yet been independently replicated by a second research group the way this Library’s cost and productivity claims elsewhere have been cross-checked against METR or DORA. The concrete practices covered in this chapter — risk-tiered review, pairing during generation, redirecting mentorship toward the director rather than the diff — come from practitioner writing at GitHub and Thoughtworks and from independent engineering commentators, published within the last few months, not from a controlled study of review outcomes before and after adoption. That several of them arrived at similar answers independently counts for something. It does not yet make them a settled literature, and a team adopting any one of these practices should treat it as a reasonable bet under real uncertainty, not a proven fix borrowed from a mature science.