human review of agent output

Human review of agent output is the step that keeps an AI coding agent from becoming an unsupervised contributor. It sounds obvious and is routinely skipped, because the output looks plausible, the tests passed in the agent's own summary and there are seven more tasks waiting. The risk is not that agents are usually wrong. It is that when they are wrong, the output reads just as confidently as when they are right, and the cost of a bad accept lands later, somewhere harder to trace. Good review is a small, repeatable routine rather than an act of heroic attention: look at what the task asked for, look at what changed, look at the evidence that the change works, and decide. The tooling question is whether the facts you need are in front of you when you sit down to review, or whether you must reconstruct them from a terminal scrollback.

What to look at, in order

Start with the task, not the diff. Reread the completion criteria so you review against what was asked, not against what the agent decided to do. Then check scope: did the changed files fall inside the area the task allowed, and is anything touched that should not be? Next, find the evidence. Which check ran, what did it return, and does it actually exercise the changed behavior? A green run of unrelated tests proves little. Then read the code the way you would read a colleague's pull request, paying extra attention to places where agents tend to be sloppy: silently broadened error handling, deleted tests, hardcoded values and edits to configuration. Finally, decide and record it. Accept, reject with a reason, or send back with specific changes. A rejection that leaves a note helps the next attempt, while an unrecorded one means the same mistake repeats.

Treat agent claims and process signals as unverified

Two kinds of signal are tempting and weak. The first is the agent's own summary. It is a useful pointer to where to look, but it is written by the party being reviewed. The second is process status: the terminal closed, the exit code was zero, the scheduler logged a success. These tell you the tooling ran, not that the work is right. A diff has the same limit, since it shows change but not correctness. Stronger signals are independent: a check you defined before the run, evidence tied to the files as they are now, and a human who read the result. Be especially careful with missing data. If usage figures or results are absent, the honest reading is unknown. Review also needs a place to put the verdict that is separate from the place the agent writes, so acceptance never happens as a side effect of the agent finishing.

How review works in Liquid Brain

Liquid Brain is built so that you inspect the recorded outcome before accepting it. Attempts, outcomes and reported usage are kept with the work [C4]. You can check whether recorded evidence still matches its supporting files [C6]. Build tracks implementation and acceptance separately, so a high implementation figure does not read as approval, and missing or stale checks remain visible [N02]. Reports show decisions waiting for attention and recorded work history, with missing coverage disclosed [C7]. By default accepted managed harness work goes to a verify state instead of done, so a person makes the final call [C4]. Because actor names in history are declared tags, not authenticated identities, treat them as provenance to inspect [C7]. Before an agent runs, proposed scope and approved authority are already kept apart [N09].

QUESTIONS

How should I review code written by an AI agent?

Review it against the task's completion criteria first, then check that changes stayed inside the allowed scope, then look for the evidence that the change works. Read the code as you would a colleague's pull request, and record your decision either way.

Is a passing test run enough to accept agent changes?

Not by itself. It proves only what the tests cover, and it may be stale if files changed afterward. Look at which checks ran and whether they exercise the changed behavior. Liquid Brain shows whether recorded evidence still matches its files [C6].

Does Liquid Brain mark agent work as done automatically?

No. By default, accepted managed harness work goes to a verify state, and human acceptance remains separate from the agent saying it finished [C4]. Build also tracks implementation, evidence and owner acceptance as distinct things [N02], so a card in review is never silently counted as approved by a person.

RELATED GUIDES

• How to read Liquid Brain reports and provenance
• How to read project progress in Liquid Brain Build
• What is a project management harness?

RELATED HARNESS PAGES

• evidence gates for AI work Evidence gates for AI work: separate proposed from approved execution, run checks, and record outcomes so acceptance rests on evidence.
• agent run history and reports Agent run history and reports: what to record about AI agent runs, how to read usage coverage honestly and where unknown differs from zero.
• kanban for AI agents Kanban for AI agents: the board states that matter when software does the work, including review, blocked and decision owed.