Review has two jobs
Anthropic's account of the Claude Code review process names both jobs. Review finds problems before release. It also spreads codebase knowledge across the team. The company has built a detailed system for the first job. Automated agents inspect changes, security checks can block them, risk sets the approval count, and a merge queue retests against the current branch.
The second job is less settled. The article says there is no formal process for sharing context. Engineers request fresh explainers for the slice they need and work in open chat channels. That may work for this team. It is not proof that an explainer gives another engineer enough knowledge to change the same code under pressure.
A clean merge records compatibility. It does not record comprehension.
The lost thing is not every line
Nobody needs a complete codebase in their head. That was rare before coding agents. The useful unit is smaller. A maintainer needs the reason for the change, the boundary it depends on, the failure that shaped it, and the person who can answer the next question.
Google's review guide asks reviewers to inspect the design and the wider system, not only the changed lines. Its comment guide says an explanation left only in the review tool does not help future readers. The normal fix is clearer code or a durable comment.
That advice gets sharper when a machine handles routine review. If the reason exists only inside an agent session, the merge can erase the most useful part of the work.
A queue protects code, not memory
GitHub documents the merge queue as a way to test a pull request against the latest target branch and the changes already queued ahead of it. That catches combinations that passed on separate branches but fail together.
The queue does not know whether another person can explain the new behavior. It does not preserve a rejected design, name the fragile assumption, or prove that the on-call engineer can find the rollback route. Those need a separate handoff.
Make the handoff earn its shelf space
Do not generate a broad architecture essay after every pull request. Write a short transfer note only when the change alters a shared boundary, adds a failure mode, retires an old assumption, or creates a pattern others will copy.
A useful note answers four questions:
- Why did this change happen now?
- What boundary or invariant must stay true?
- Which failure or rejected approach shaped the final design?
- Who owns the next decision, and where is the runnable proof?
Then ask someone other than the authoring agent to challenge one answer against the code. The note is ready when the challenger can point to the exact revision, test, or runtime output behind it.