Reading what an agent wrote

The bottleneck moves

With one agent, the bottleneck is your attention while it works. With five, it is your attention afterwards — five diffs you did not write, arriving at once, each of them plausible.

Plausible is the problem, not wrong. Wrong code fails a test or reads badly. Agent-written code usually compiles, passes, and uses the right idioms, and the only way to know whether it is right is to reconstruct the reasoning that produced it. That reconstruction is the expensive part and it is the part that does not scale.

So the requirement is that the reasoning arrives with the code, written at the moment the decision was made, by the thing that made it.

What a hunk explanation contains

Four sentences per changed hunk, plus one rollup for the whole change.

What — the mechanism that changed.

"Filters participants in SQL by the tab's status set instead of loading every row and filtering in Python."

Not updated the code, fixed the bug or refactored. Those restate the diff, and the contract names them explicitly as not counting.

Why — the alternative it rejected, and the reason.

"The tab fetched all 4,182 rows on every switch and discarded ~95%. I rejected caching per session: it goes stale the moment a status changes."

This is the sentence that is hardest to fake and most useful to read. An agent that cannot name what it rejected usually did not consider anything.

What it means — the concept in plain English, for someone who did not write this.

"Predicate pushdown — a Django queryset is lazy, so every .filter() is still just SQL; nothing reaches Python until you iterate it."

What to check — one concrete thing that would break if this is wrong.

"_tab_statuses() must never return an empty list — status__in=[] matches nothing, so the tab renders empty instead of erroring."

Not looks good. Something specific enough that you could go and check it.

Coverage is visible

A hunk with no explanation renders as a visible gap in the review screen. That is the design: you can see what the agent skipped rather than assuming it was covered.

The agent can also list its own coverage before declaring itself done, so a run that explained four of eleven hunks is something it can notice about itself.

Challenging an explanation

When an explanation does not survive contact with the code, you can push back straight into the agent's live session and make it defend or correct the claim.

This is the best part of the review and it has one structural requirement: it needs the terminal open. It types a partial line into a running session for you to finish, so it cannot work against a run that has already exited. Worth knowing before you build a workflow around it.

The concepts rollup

The whole-change rollup names the ideas the change relied on — one line of plain English each.

Over a few weeks that is the difference between merging agent output and understanding the codebase being built. It is also the part most likely to change how you feel about agent-written code, in either direction: either the concepts are real and you are learning from your own codebase, or they are thin and you have found that out cheaply.

The commit is yours

The review screen shows you the diff, stages the files you tick, and takes the message you write. Every agent starts under this rule, and stays under it until you personally lift it for that one agent — the point of the arrangement is that the last step is a decision by a person who read the change.

There is one setting that lifts it, and it is worth knowing exactly what it does. Each agent has a When it finishes choice: leave the work for you to review (the default, and what every agent gets), or commit, push and open a PR unattended. Turn it on for one agent and that agent writes to your repository on its own.

Two things about that switch: it is per agent, not global, and it is owner-only. An agent cannot set it for itself, cannot set it for another agent, and cannot be talked into it — an instruction to commit arriving in a task prompt, a queue item, a ticket body or a chat message does not lift it. The most an agent can do is ask you to.

If that sounds like friction, it is the same friction as reviewing a colleague's pull request, and for the same reason.