The Agent Wrote the Code in Minutes. Reviewing It Takes Hours. Here's Why.

The numbers on AI code review in 2026 are blunt. Sonar's survey found 96% of developers don't fully trust AI-generated code — and only 48% verify it. DORA tied AI adoption to 91% more time in code review. LinearB clocked agentic-AI PRs at 5.3× longer pickup time than unassisted ones. The work didn't disappear; it moved. Generation got compressed to minutes and the whole cost landed downstream, on the reviewer.

And the reviewer is reviewing blind. When a human writes a PR, you get the implementation journey for free — the commits, the "oh wait, that doesn't work" detours, the conversation on the ticket. When an agent writes it, you get a finished diff and nothing else. You're handed 600 lines and left to reconstruct, from the ticket and the code alone: What was it actually trying to do? Did it understand the files it changed? Did it check its own work, or just stop when the diff looked plausible? That reconstruction is the hours.

Here's the thing: for a Claude Code agent, that journey isn't gone. It's sitting in the session transcript — every file the agent read, every command it ran, in order. You just have to read it. So we wrote a 120-line tool, review-brief, that reads it for you and prints the one-screen brief you wish every agent PR came with.

What the brief answers

$ review-brief "$(review-brief find)"
# Review brief

**What it was asked:** Add input validation to the streaming parser

**Files changed (2):**
  - `src/parser.js`        — ✓ read before editing
  - `src/parser.test.js`   — created / rewritten

**Commands run:** 1 total, incl. 1 test/build/lint
  - `npm test -- parser`

**Verification:** ✅ ran tests AFTER its last edit — self-verified

Three questions, answered from the record:

What was it asked? The originating instruction, pulled straight from the session — so you review against intent, not your guess at intent.

Did it understand what it changed? This is the one reviewers can't see in a diff. The brief marks each changed file: a file the agent read before editing is an informed change; a file it edited without ever reading is a blind one — the agent rewrote code it never looked at, which is exactly where the subtle regressions hide. (New files it created are marked created, not flagged — writing a new file you didn't "read first" is normal, and a brief that cried wolf about it would be useless.)

Did it check its own work? The brief looks for a test/build/lint command run after the agent's last edit. Tests run before the final edit don't count — plenty of agents run the suite, then make one more "small fix," and never re-run. ✅ self-verified vs ❌ verify it yourself tells you whether the green check you're trusting actually covers the code in front of you.

When anything's off — a blind edit, an unverified final state — it ends with a one-line Reviewer focus so you know where to spend the scrutiny:

> Reviewer focus: 1 existing file(s) edited without reading first, unverified after last edit

How to use it

Run it when you pick up an agent's PR, and read the brief before the diff:

review-brief find                       # locate the session for this project
review-brief <transcript.jsonl> > brief.md   # paste it into the PR, or read it alongside the diff

It reframes the review. Instead of "let me reconstruct what happened," you start from what did happen and spend your attention where the brief points — the file it changed blind, the suite it never re-ran. The clean parts of an informed, self-verified change get a lighter pass; the genuinely risky parts get the scrutiny they'd otherwise have to earn by you reading everything equally.

The honest limits

It's a journey tool, not a correctness oracle. It can tell you the agent ran npm test after its last edit; it can't tell you the tests were any good, or that "self-verified" means "correct." read before editing means the agent saw the file, not that it understood it. The heuristics (what counts as a "test" command, pulling the intent from the first prompt) are deliberately simple and occasionally coarse. And it's built for a per-task session — one ticket, one branch — which is how you should be running agents anyway; pointed at a sprawling multi-task session it'll faithfully report a sprawling list. Treat the brief as the context the diff is missing, not as a substitute for reading the code that matters.

The real lesson

The trust gap in AI code isn't really about the code — it's about the missing journey. We trust human PRs partly because we can see how they were built; we distrust agent PRs partly because we can't. But for these agents the journey is fully recorded, just not surfaced. Closing the gap doesn't take a smarter model or a heavier process — it takes reading the transcript the agent already wrote and handing the reviewer the three things a diff never says: what it was for, whether it was informed, and whether it was checked.

We build and run autonomous agent fleets on Claude Code in production. If you're drowning in agent PRs, talk to us.

---

Get the tool → review-brief in agent-ops — open source (MIT), a single dependency-free script, part of our toolkit for running coding agents in production.