Once Claude Code or Codex starts doing real chunks of work, there comes a point where reading everything stops being realistic. One request changes a dozen files, the tests pass, and reading the diff top to bottom would take an hour. Skip it, and nobody knows what actually went in.
There's a lot of talk lately about merging AI code without reading it. Look closely and the serious versions of that argument aren't saying "don't read." They're saying: keep enough of a record that you can make the call without reading all of it.
So what is that record, concretely? Here's one change an AI agent made, used as the example.
Not "what changed," but "what did the AI change"
With a human PR, the git diff is the thing you review. With an agent it's messier. Your own fixes and another agent's edits land in the same working tree, so git can't separate out what the AI did.
What you need is a record of every moment the AI wrote a file: which model, why, which file, and what changed.
In the osFoundry desktop app, for example, every time an agent saves a file, the content, the model and its stated reason go into a local database. Review shows only the diff against the version right before that write.
The request here was "make retries start sooner." The diff is one line: timeoutMs went from 30,000 to 3,000. But the comment right above it says big photo uploads take 20+ seconds. Making retries start sooner just made uploads fail.
The tests passed. Buried in a dozen-file diff, that line would almost certainly slip through. It was visible only because the view showed the AI's write and nothing else.
Read less code by reading the plan first
The other lever is timing. Reading a plan before anything is written is far shorter than reading the code afterwards.
But "show me a plan first" in a prompt isn't enough. Models often start editing as soon as they've read enough. To make it stick, the write tools themselves have to be unavailable until the plan is approved. That's what plan mode for AI agents does.
This plan lists four files to change and one line that may matter most for review: "Not touching: src/billing/." Agree on that up front, and checking the diff later partly becomes checking that billing wasn't touched.
If you can undo it, you read differently
The last piece is surprisingly effective: being able to roll back.
If any change can be undone one turn at a time, the goal of review shifts from "let no mistake in" to "back it out if something's off." You no longer have to read everything in advance. You can run it first, then read the parts that look suspicious.
Here the turns are listed by the first line of each request. Pick one, and the files it edited go back while any files it created are deleted. Files edited by hand are left alone.
So what should you keep?
Put side by side, the list is short: a diff and a reason for every AI write, a plan agreed before writing (especially what it won't touch), and a state you can roll back one turn at a time.
With those three, you can answer "what went in," "was that what we agreed," and "can we undo it" without reading every line. Stopping to read everything is something to give up only once you can answer those.
