Your coding agent's reviewer needs evidence

For engineers handing a coding agent's patch to a second agent for review, and the owners deciding whether that review step earns its place.

Another agent can help find defects. Its endorsement is useful only to the extent that its checks support it.

A coding agent changes a date filter. It adds a test, explains the implementation and hands the patch to another agent. The reviewer sees that the comparison matches the test. Both agree the work is complete.

They have agreed on the wrong boundary.

This is a fictional patch, with no code or tests executed. It illustrates a particular review problem: the author can carry the same misunderstanding into implementation, test and explanation. A reviewer that accepts that explanation can inherit it.

The missing ingredient is evidence tied to the intended behavior. Changing who reads the diff does not automatically provide it.

A passing example can preserve the mistake

Suppose a report lists jobs completed during a selected UTC calendar day. The owner has specified that selecting September 15 includes jobs from midnight at the start of September 15 up to, but excluding, midnight at the start of September 16. Each job belongs to exactly one daily report.

The fictional patch uses an inclusive comparison at both ends: completion time is greater than or equal to the start and less than or equal to the next midnight. Its author-written test supplies one job at noon on September 15 and another at noon on September 16. The expected output contains only the first job.

By inspection, that example is consistent with the flawed comparison. It says nothing about the exact midnight separating the days. A job at September 16, 00:00 UTC would appear in both reports under the stated comparison. Summing daily reports would count it twice.

The defect is specific enough to explain without a runtime. That is a logical finding about the fictional predicate, not an observed result from a repository. A real patch would still require checking how timestamps are parsed, stored and passed to the query.

Give the reviewer a question it can answer

“Review this diff” leaves several jobs bundled together.

Requirements verification asks whether the behavior satisfies the owner's decision. Defect discovery looks for other ways it can fail. Maintainability review considers how easily the next engineer can understand and change it. Approval determines whether the available evidence justifies accepting the remaining uncertainty.

For this patch, start with a narrower assignment: verify that adjacent UTC daily reports cannot include the same completed job, and inspect the path from selected date to query bounds. The intended interval comes from the requirement, independently of the author's explanation.

Give the reviewer the changed implementation, relevant callers and the actual test definitions. Include the consequence of overlap and any relevant history. A prior issue about double counting could matter; unrelated discussion need not fill the context.

The reviewer should derive expected boundary behavior before reading the author's conclusion. That creates a chance to notice disagreement. It does not guarantee independent reasoning.

Return a packet someone can use

Here is a completed review packet for the fictional change. It records an analytical finding and a concrete verification plan. Every execution result is unverified; no test run or repository artifact exists for this example.

The boundary check is small enough to spell out completely:

These examples assume millisecond precision. A real test should use the application's supported representation rather than silently rounding a fixture. Also check the shared invariant: the September 16 midnight job appears once across the two adjacent reports, in September 16 only.

For an executed review, attach the revision, check definition, command, environment and output. A green result from an earlier revision cannot establish that the revised patch works. A proposed test belongs under next actions until it has actually run.

Independence comes in degrees

Two reviewers can share an incomplete requirement, a misleading mock or the same mistaken assumption about timestamps. Using different models may diversify some mistakes, but does not establish that their errors are independent.

Evidence can challenge those shared assumptions. An acceptance case derived from the owner-approved interval challenges the author's interpretation. Exercising the real query path challenges a mock that quietly applies different semantics. Comparing adjacent report membership challenges tests that inspect each report in isolation.

An independently prepared acceptance set can be withheld from the author during implementation and applied afterward. Keep the behavior public; withholding requirements turns verification into guessing. Once a failing case drives a correction, preserve it as regression coverage. Repeated success on that disclosed case is no longer fresh evidence of general defect detection.

These measures still depend on somebody choosing the right requirement and assertion. A deterministic test can reliably enforce an incorrect expectation.

Anthropic's March 2026 harness report describes separate generation and evaluation, with the evaluator exercising running applications against agreed criteria. It also reports evaluator leniency, shallow checking and remaining defects. This is a vendor's engineering account, not independent evidence that another reviewer reliably catches our bugs. Its useful contribution here is showing that evaluator behavior itself required scrutiny. Harness design for long-running application development (opens in a new tab)

Missing evidence should change the conclusion

If the reviewer cannot run the query, it can still identify the boundary contradiction and state what remains unverified. If the requirement says only “daily report,” it should surface the timezone and boundary ambiguity before approving a particular interpretation.

Escalation should name the unresolved decision: which timezone defines the day, or whether an external consumer depends on existing behavior. “Needs human review” without that question transfers investigation rather than helping it.

Anthropic's January 2026 evaluation guide distinguishes the execution transcript from the resulting state and discusses different grading methods. That distinction matters here: an agent saying it checked the filter is different evidence from the check's output, and neither establishes behavior outside the check's scope. Demystifying evals for AI agents (opens in a new tab)

Earn the additional review step

Human reviewers also miss boundaries, accept weak tests and misunderstand requirements. The comparison should be with the team's actual review process, including its failures and cost.

For this narrow predicate, agreed boundary tests may supply the routine check once the requirement is settled. Running a conversational reviewer on every future edit could add little. Its stronger role may be discovering missing cases when behavior changes or tracing interactions the tests do not cover.

To evaluate that role, compare matched changes with and without the additional reviewer. Have findings adjudicated against behavior, including false alarms. Record accepted defects found, escaped defects discovered later, active human review and correction time, machine cost and elapsed delay. Keep disagreements visible. A longer list of comments does not demonstrate a better review.

The useful output is a finding someone can verify, or a bounded account of what was checked and what remains uncertain. That gives the next engineer a basis for deciding. Agreement alone gives them another opinion.

Next: When more agents are worth it, on which work can proceed independently, and what bringing it back together costs.

---

Source record: sources, evidence status and fictional elements for the whole series. Apply the series: Delegation review kit. Related: What the agent did, on why a transcript records a claim and an observer records evidence.