Session review
Published July 28, 2026 · by the AQ team
Session review is the practice of reviewing an AI coding agent's working session, the prompts it was given, the corrections it received, the paths it tried and abandoned, and the behavior of what it built, rather than only the code diff it produced. It extends code review to fit how agent work actually happens: the decisions that determine quality are made during the run, and the diff records only their outcome.
Why the term exists
Code review assumes the diff is where the thinking is visible. That assumption held when a human wrote every line. With coding agents it breaks: the thinking is in the session (how the task was scoped, what the agent misunderstood, what the operator let slide), and the diff is the residue. As of July 2026 the gap is measurable: a LeadDev analysis of 25,264 agent-generated pull requests found that in 79 percent the same developer both reviewed and modified the agent's contribution, with no second set of eyes anywhere in the loop. The full argument is in the self-review problem.
What a session review covers
| Layer | Question | Visible in the diff? |
|---|---|---|
| The brief | Was the agent asked for the right thing? | No |
| The run | Where did the agent struggle, retry, or get corrected? | No |
| The overrides | What warnings or suggestions did the operator wave past? | No |
| The code | Is the change correct and maintainable? | Yes |
| The behavior | Does the running result do what the ticket meant? | No |
Classic code review covers one of the five layers. Session review covers all five, and it concentrates human attention where the session shows the agent had trouble, which is where plausible-but-wrong code hides.
How teams practice it
- Minimum viable: the operator pastes the original brief into the PR description and keeps the session transcript retrievable (terminal scrollback, tmux history, or the CLI's transcript export). The reviewer reads the brief before the diff.
- Better: sessions run somewhere persistent that a reviewer can open after the fact, and someone other than the operator runs the result before merge.
- Full practice: teams make shared sessions the norm: agent workspaces are opened to the team (visibility stays owner-managed), so a second person can watch or join the run live, read the scrollback while the session is up, and click through the built feature next to the diff. This is the model AQ is built around: 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. The step-by-step pattern is in reviewing AI agent work.
Related terms
Multiplayer coding agents (the category of tools whose sessions are shared places), agent orchestration (running and coordinating many agents, which multiplies the review load), and the self-review problem (the failure mode session review exists to fix).
Frequently asked questions
How is session review different from code review?
Code review evaluates the diff. Session review evaluates the run that produced the diff: the brief, the corrections, the abandoned paths, the overrides, and the behavior of the result. For agent-written code the run is where the quality-determining decisions happen, so reviewing only the diff audits the residue of the work.
Does session review replace code review?
No, it contains it. The diff still gets read; session review adds the context that makes the reading meaningful and adds a behavior check by someone other than the person who ran the agent.
Do I need special tooling for session review?
No. The minimum is a preserved brief and a retrievable transcript, which tmux scrollback or a CLI transcript export provides. Tooling matters at team scale: sessions that live in shared persistent workspaces make the review one link instead of an archaeology exercise.
Why is session review suddenly a topic in 2026?
Because the data made the gap visible: a July 2026 LeadDev analysis found that in 79 percent of agent-generated PRs the same developer both reviewed and modified the contribution, meaning no independent reviewer was involved. As agent output grows, the session is where review has to move.