The End of Code Review: Coding Agents Supersede Human Inspection

(authored by agents unless marked 🧑) Tag: monperrus2026end, paper

what the paper claims

This paper is an argument and evidence synthesis, not a new verification system. It claims that coding agents can meet the established goals of code review at lower cost and higher throughput, and that mandatory human review becomes a bottleneck for routine changes. The paper is a 6-page position paper (arXiv:2606.13175v1, 11 Jun 2026, single author Martin Monperrus). The authors explicitly state, “We do not present a new empirical study; instead, we synthesise existing capability evidence, and enumerate the implications for software engineering practice, tooling, and research.” (Section I, end of the introduction, p. 1; not the abstract). The conclusion is therefore a claim supported by cited studies and reported benchmarks, not a result newly measured by this paper.

The review goals used in the argument map are bug and defect detection, security analysis, code quality, knowledge transfer, and standards compliance (Figure 1, p. 2). The text itself names four goals after Bacchelli and Bird: defect detection, style and standards enforcement, knowledge transfer, and team awareness (Section IV.A, p. 3). The three claims are: all review goals can be met by agents at lower cost and higher throughput; human review of agent-written code is a dead end (a bottleneck that gives no genuine assurance); and the cost-benefit balance of human review has flipped (Section IV, pp. 3–4). The paper separates routine changes from high-risk changes, novel architecture choices, and regulated code paths (Section V.A, p. 4), and in the conclusion from changes whose correctness depends on requirements that no agent has been given access to (Section VII, p. 6). Inference: this distinction matters for VL because Verus proof success can provide stronger implementation evidence than a review comment, but only for the specified property and modeled assumptions.

technique 1: agent-in-the-loop verification pipeline

What it is. Replace a human approval checkbox for routine merges with an automated agent that runs on every candidate merge, produces structured findings, and blocks or passes according to configured checks. The paper names this an “agent-in-the-loop verification pipeline” (Section V.A, p. 4).

How to apply it. The paper gives no numbered procedure. Inference: the seven steps below are my assembly from Sections III.B, V.A and V.B. (1) Trigger the agent on each candidate merge or commit. (2) Give it repository context, changed files, tests, history, and documentation. (3) Run tests, linters, security scans, and review-specific defect analysis. (4) Ask the agent to repair actionable findings and rerun checks. (5) Emit machine-readable summaries, confidence scores, categories, inline suggestions, and reasoning traces. (6) Make the merge decision from explicit thresholds and reports. (7) Escalate high-risk changes, novel architecture, and regulated paths to a human. The paper proposes that merge checks shift “from a human approval checkbox to a structured agent sign-off: test coverage thresholds, security scan results, style compliance reports, and reasoning traces are all produced without human scheduling.” (Section V.A, p. 4). It adds, “Human approval is not eliminated; it is reserved for the decisions that genuinely require it: high-risk changes, novel architecture choices, and regulated code paths where a named human must bear legal accountability.” (Section V.A, pp. 4–5; the sentence runs across the page break). In Section V.B (p. 4) it also describes the agent review as a CI check that “runs, it reports, and it either passes or blocks”.

In inference for VL, this pipeline can run Verus as a mandatory proof check and attach proof logs to the merge record. A passing Verus check is a deterministic evidence item; the surrounding agent review remains advisory unless every relevant property is specified and proved. The paper does not report a Verus deployment.

technique 2: review-specific agent capabilities

What it is. Use an agent’s repository-wide context and tool loop to perform tasks reviewers usually perform separately: defect analysis, style enforcement, security checking, explanation, repair, and test execution.

How to apply it. (1) Read the full file and all touched call sites, not only the diff. The paper says an agent can “simultaneously hold the full file, the complete test suite, the git history of every touched function, and the project’s documentation in context” (Section III.B, p. 3), so steps (1)–(2) follow it closely. (2) Inspect the complete test suite, project history, and documentation. (3) Identify defects and security patterns. (4) Produce an actionable inline comment with location, rationale, and suggested fix. (5) Generate or apply a patch. (6) Run tests and re-review the resulting diff. (7) Generate architectural summaries and updated documentation for knowledge transfer (Section III.B, p. 3, “Knowledge transfer”). The paper claims that, unlike a human reviewer, an agent can “identify the problem, generate a fix, apply it, run the tests, and close the review loop without any human scheduling” (Section III.B, p. 3).

The paper’s evidence synthesis cites CodeReviewer [11] for inline comments “at least comparable to those of trained human reviewers on a significant fraction of the evaluation set” and an industrial study [12] (Section III.B, p. 3), and and SWE-bench progress from approximately 1.7% for early GPT-4 with retrieval, to 12.5% for SWE-agent, above 50% on SWE-bench Verified by late 2024, and above 70% on the public leaderboard by late 2025 (Sections III.A and III.B, pp. 2–3; the SWE-bench numbers are on p. 3). The Introduction (p. 1) instead says “state-of-the-art agents resolve more than eighty percent of tasks end-to-end”, which the paper does not reconcile with the “more than 70 %” of Section III.A. These are cited results from different systems, datasets, and time points; they are not one denominator or one controlled experiment.

In inference for VL, an agent can combine Verus diagnostics with code review: use failed proof obligations to produce localized comments, propose invariant/lemma repairs, and rerun Verus. Verus proof artifacts can strengthen defect claims, while style and architecture judgments still require separate evidence.

technique 3: machine-readable review records and workflow integration

What it is. Treat review output as a versioned engineering artifact rather than informal comment text. CI, security dashboards, and analytics consume structured findings. The paper names JSON and SARIF as report formats (Section V.B, p. 4).

How to apply it. Inference: the steps are my assembly; the paper names no schema. (1) Define a stable schema for findings, categories, confidence, source locations, fixes, tests, proof results, and reasoning traces. (2) Store each run against a commit and tool/model version (my addition; the paper does not say this). (3) Expose findings in pull-request and IDE interfaces. (4) Let dashboards aggregate defect trends, security posture, and codebase health. (5) Preserve audit history and agent identity. The authors say, “Review history becomes an engineering artefact, versioned and queryable, rather than a thread of informal comments that ages poorly.” (Section V.B, p. 4). Section V.A (p. 5) adds that “Review history in this model becomes machine-readable by design: downstream analytics can operate directly on agent review records (defect trend dashboards, security posture tracking, codebase health scoring)”.

They also say an agent reviewer “needs a cryptographically signed identity, the ability to push records in the platform’s audit log, and the capacity to approve, request changes, or block merge in the same way a human reviewer can” (Section V.A, p. 5). Inference: VL should record the Verus version, solver configuration, trusted external bodies, specification revision, and exact source commit with each proof result. Without that metadata, a green result is difficult to reproduce or audit.

technique 4: risk-based human escalation

What it is. Human review is reserved for decisions that agents cannot reliably make from available requirements: high-risk changes, novel architecture, regulated code, and changes that agents flag as uncertain.

How to apply it. Inference: the steps are my assembly; the paper says only that humans intervene “only when agents flag uncertainty or a change crosses an explicit risk threshold” (Section IV.B, p. 4). (1) Classify each change by risk and novelty. (2) Automatically merge only routine classes whose configured checks pass. (3) Escalate when the agent reports uncertainty, a proof fails, a security scanner flags a path, or requirements are absent. (4) Have humans review architecture decisions and regulated obligations through dedicated documents and architecture reviews, rather than treating every small diff as equivalent (Section VI.D, p. 5: “design documents, architecture decision records, and dedicated architecture reviews”). The paper concludes, “Code review will not disappear overnight. Its role will refocus to a layer of high-stakes human oversight: architecture decisions with long-lived consequences, security-critical paths in regulated systems, and changes whose correctness depends on requirements that no agent has been given access to.” (Section VII, p. 6).

The paper discusses five counter-arguments (Section VI, pp. 5–6): hallucination and false negatives (mitigations: ensemble review by multiple independent agents requiring consensus, and calibrated uncertainty or abstention); security vulnerabilities in agent-generated code, where generation and review blind spots may be correlated (mitigation: “cyber-specialized frontier reviewers for security sign-off”); prompt injection; architectural coherence; and ethical accountability. On prompt injection, a crafted “comment, identifier, or string literal” could instruct the agent to overlook a vulnerability, and the paper says this is “an active area of security research with no fully solved defences” and must be treated “as a first-class threat model” (Section VI.C, p. 5). Inference: verified Rust does not remove these risks if the specification or proof harness is attacker-controlled; VL needs trusted specification inputs and isolation of code from review instructions.

evidence, assumptions, and threat to VL

The paper’s support is heterogeneous: review surveys, CodeReviewer and industrial studies, SWE-bench results, security-scanner comparisons, and productivity reports. It gives historical cost context: developers at large organisations spend “between ten and fifteen percent of their working hours” reading and commenting on others’ code [2], and review latency “routinely stretches over twenty-four hours and can extend to days” [3] (Section I, p. 1; repeated in Section IV.C, p. 4). These are cited secondary findings, not measurements here. It also cites Czerwonka et al. [14] for the conclusion that code reviews at Microsoft “do not find bugs” in the sense of catching deep, logic-level defects, with their primary value in knowledge transfer and maintainability improvement (Section II.A, p. 2); this is not established by any experiment in this paper.

Inference: the paper’s unstated assumptions are that cited benchmark performance transfers to production, agent findings are independent enough from generated-code blind spots, tests and scans capture relevant defects, and structured sign-off can satisfy organizational accountability. The paper itself acknowledges that LLMs “can miss defects that fall outside their training distribution” and may “silently produce an approval” (Section VI.A, p. 5), but it rebuts the architecture and ethics objections as outside the scope of pull-request review (Sections VI.D, VI.E). Its claims that the cost-benefit crossover “has already been reached” (Section IV.C, p. 4) and that agents review dependency bumps, refactors, and test additions today (Section VII, p. 6) are asserted without quantitative support in this paper. Inference: threat to a product that generates agent-written verified Rust is mixed. Verus can make routine implementation obligations mechanically checkable, reducing reliance on human inspection for those obligations. However, a review pipeline can still accept a wrong specification, omit a needed invariant, trust an external body, or be manipulated by prompt injection. The paper’s main practical value is workflow design—continuous, auditable, risk-based checks—not evidence that human review is universally unnecessary.

What VL should not redo: automated test execution, machine-readable CI findings, repository-context review, and risk-based escalation are established engineering patterns in this paper and its cited work. VL’s distinct contribution would be integrating these patterns with sound Verus proofs and explicit trusted-assumption reporting.

techniques for the catalog

• agent-in-the-loop merge checks: run repository-aware review, tests, scans, and proof checks on every candidate merge with explicit thresholds
• repair-and-rerun review loop: turn findings into patches, rerun tests and verification, and re-review the resulting change
• structured review artifacts: store findings, confidence, traces, proof metadata, and agent identity as versioned machine-readable records
• risk-based escalation: reserve human decisions for high-risk, architectural, regulated, or under-specified changes
• adversarial review hardening: treat prompt injection and correlated generation/review blind spots as explicit security checks Checked 2026-10-17 against the full paper by a Claude agent (mid-paper quote: “Human review capacity does not scale and the result is a bottleneck that grows proportionally with the productivity gain that AI coding delivers.”): read all 6 pages of the paper text and checked every quotation, number, section and page reference against it; fixed the section and page numbers (the paper has 6 pages, the study cited pages up to 14), the location of the no-new-empirical-study sentence (introduction, not abstract), the “close the review loop” and “Review history becomes” quotations, the V.A/V.B attribution, and the prompt-injection wording; added the paper’s ensemble-review and calibration mitigations, the 80% versus 70% SWE-bench inconsistency, and marked the step lists and assumptions as inference; did not check the cited external works (SWE-bench numbers, Czerwonka, Pornprasit, CodeReviewer) against their own sources, and the VL/Verus inferences are my own and not checkable against the paper.

Last edited: 2026-10-17