# Engineers have stopped reviewing PRs > Source: > Published: 2026-07-29 21:31:31+00:00 # How to review an AI coding session, not just the diff Published July 29, 2026 ยท by the AQ team Reviewing an AI coding session means evaluating the run that produced the code, not only the diff it left behind. A full session review covers five layers: the brief the agent was given, the corrections it received mid-run, the paths it tried and abandoned, the warnings the operator waved past, and the behavior of the running result. You can practice it today with any terminal agent and no special tooling, using three habits: preserve the original brief, keep the session transcript retrievable, and make a second person the default on agent pull requests. This guide walks through the manual practice first, then looks at where tooling removes the friction. ## Why the diff alone is not enough Classic code review assumes the author's thinking is visible in the diff. With agent-written code that assumption breaks: the quality-determining decisions happen during the run (how the task was scoped, what the agent misunderstood, what the operator let slide), and the diff records only their outcome. That is the premise behind [session review](/glossary/session-review/) as a practice distinct from code review. The gap is no longer hypothetical. A July 2026 [LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories](https://leaddev.com/ai/ai-coding-agents-kill-team-collaboration) found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. Most agent work merges with exactly one set of eyes on it, and that reviewer carries expectation bias: they know what was asked, so they read the diff as confirmation. The characteristic agent failure (plausible code that does something subtly different from the request) is precisely the failure that bias hides. The full argument is in [the self-review problem](/self-review-problem/); this guide is the how-to. ## Habit 1: preserve the original brief The single highest-leverage change costs thirty seconds: paste the prompt that started the session, verbatim, into the pull request description. Not a summary, the actual text. A reviewer who can compare the brief against the diff can answer the question no amount of code reading answers: does this change implement what was actually asked? Three rules make the habit stick: **Verbatim beats summarized.** A paraphrase of the prompt inherits the same expectation bias the review is trying to remove. Copy the real text, typos and all.**Include the corrections that changed scope.** If you redirected the agent mid-run ("no, only the API layer", "skip the migration for now"), those follow-ups are part of the brief. A reviewer who does not know the migration was deliberately skipped will either waste time flagging it or wrongly assume it was forgotten.**The ticket is not the brief.** Linking the issue is good practice, but the agent never read your intentions, it read your prompt. When the two diverge, the prompt explains the diff. ## Habit 2: keep the transcript retrievable Everything else in a session review depends on the transcript surviving until review time. By default it often does not: terminal scrollback dies with the window, and CLI history files expire. Decide, as a team, where transcripts live, and make saving one a reflex that happens before the PR is opened. If the agent runs inside tmux (which also keeps the session alive when your connection drops), the scrollback is exportable with one command: ``` # from inside the pane: write the entire scrollback to a file tmux capture-pane -p -S - > agent-session-fix-auth.txt # or record everything from the start with the classic script utility script -q agent-session.log ``` The agent CLIs themselves keep records, with different levels of convenience as of July 2026. Claude Code stores every session as JSONL under its projects directory and can resume it later with claude --continue or the claude --resume picker; more usefully for review, the /export command renders the current conversation to a plain-text file or the clipboard. Note the retention default: transcripts are cleaned up after 30 days unless you change the cleanup setting, so "it is in Claude Code somewhere" is not an archival strategy. Codex CLI similarly saves each session as a JSONL file under ~/.codex/sessions/ and reopens it with codex resume, though it has no built-in rendered export, so teams typically save the raw file or capture the terminal instead. For sessions worth replaying rather than reading (a tricky debugging run, a session you want to teach from), asciinema records the terminal as a lightweight text-based cast a teammate can play back. Whatever the mechanism, the bar is the same: a reviewer asked to look at an agent PR should be able to reach the session that produced it in under a minute, without asking the operator to reconstruct it from memory. ## Habit 3: review in five layers With the brief preserved and the transcript in hand, the review itself has a shape. Work through the five layers in order; each one takes minutes, and each catches a class of failure the diff hides. **The brief.** Read the prompt before the code. Does the diff implement what was asked, or a plausible neighbor of it? Was the ask itself right, or did the ticket deserve pushback before an agent spent an hour on it?**The corrections.** Scan the transcript for the places the operator had to redirect the agent. Every correction marks a spot where the agent's first instinct was wrong; read the surviving code in those areas most closely, because a correction fixes the instance, not the instinct.**The abandoned paths.** Dead ends are signal. If the agent tried an approach, backed out, and tried another, it found that part of the codebase confusing, and confusing code is where subtle breakage lives. Check that the retreat was clean: leftover imports, half-renamed symbols, and orphaned helpers are the classic residue.**The overrides.** Look for the moments the agent surfaced a warning, suggested a test, or flagged uncertainty, and the operator moved past it. These are the cheapest review targets in the whole transcript: the agent has already told you where it was unsure, and someone decided under deadline pressure that it did not matter. A second opinion on exactly those moments is most of the value of having a second person at all.**The running behavior.** Run the result. Click the feature, hit the endpoint, resize the window. Most plausible-but-wrong agent code fails within the first minute of someone other than the operator actually exercising it, which makes this the highest-yield minute in the review. For the diff itself, everything from ordinary code review still applies; the difference is that the session tells you where to concentrate. A companion piece covers the diff-level mechanics of [reviewing pull requests from AI agents](/guides/reviewing-pull-requests-from-ai-agents/). ## Habit 4: make a second person the default None of the layers above work if the only person looking is the person who ran the session. The LeadDev numbers say that is the norm today, so the fix has to be a default, not an aspiration: agent-assisted PRs get a reviewer other than the operator, the same way protected branches already require an approver. Keep the policy lightweight or it will not survive deadlines: the second person reads the brief, skims the transcript for corrections and overrides, runs the result, and reads the diff with that context. For a small change that is ten minutes; a rubber stamp takes five and catches nothing. ## Where AQ fits Everything above works with files and discipline. The friction is real, though: transcripts get saved sometimes, briefs get pasted usually, and the running-behavior check quietly disappears the week a deadline lands, because standing up someone else's branch is the expensive step. AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. It makes the session itself the shared artifact, which collapses most of this guide into opening a link. Agents run as real CLIs in persistent tmux sessions on your team's VM, so the transcript is not an export the operator remembered to make: it is the live terminal and its scrollback, still there after the operator's laptop closed, in a workspace a teammate can open directly (visibility stays owner-managed: team-visible, or private and shared with specific people). The reviewer reads the session where it happened, checks the diff in the workspace editor, and clicks through the live preview of that workspace's branch without checking anything out. Comments pinned on the preview can be sent to the agent as prompts, and the PRs the agent opens are tracked on the workspace that produced them, so the session, the diff, and the result stay one link apart. The step-by-step reviewer workflow is in [reviewing AI agent work](/use-cases/ai-agent-code-review/). Start with the habits: they cost nothing and work anywhere. When the team is large enough that "where is the transcript" is a daily question, move the sessions somewhere shared. ## Frequently asked questions ### Isn't reviewing the session just code review with extra steps? It is code review plus the context that makes it meaningful for agent work. The diff still gets read; the session adds what the diff cannot show: what was asked, where the agent struggled, what the operator overrode, and whether anyone ran the result. For human-written code the author carries that context into review. For agent-written code, nobody does unless the session is preserved. ### How long does a session review take? For a typical agent PR, ten to fifteen minutes: a minute on the brief, a few minutes skimming the transcript for corrections and overrides, a minute or two running the result, and the rest on the diff with that context. The transcript skim is targeted reading, not a replay: you are looking for redirections, warnings, and abandoned approaches, which stand out visually in scrollback. ### What if the session is already gone? Review what remains, explicitly. Ask the operator for the original prompt and any mid-run redirections, get them into the PR description, and have someone other than the operator run the result. That recovers three of the five layers. Then fix the pipeline so the next session survives: tmux capture-pane, the script utility, or the CLI's own transcript (Claude Code's /export, or Codex CLI's session files) before the PR goes up. ### Do AI code review bots make this unnecessary? No. Automated reviewers read the diff, so they inherit the diff's blind spots: they cannot see the brief, the corrections, the overrides, or the running behavior. They are useful as a first pass on the code layer (style, obvious bugs, security patterns), which frees the human reviewer to spend their time on the four layers only a human with session access can check. ### What should the PR description of an agent-assisted PR contain? Four things: the original prompt verbatim, any mid-run corrections that changed scope, a pointer to the session transcript (a saved file, an export, or a shared workspace link), and what the operator personally verified by running the result. A reviewer holding those four items can do a full five-layer review in minutes; a reviewer holding only the diff is guessing.