Is code review dead?
AI agents can produce a convincing patch and still miss the task. Why code review needs to expand into agent review, with a second AI checking the evidence.
The agent has finished. The pull request is open. The tests are green. Its summary says every requirement is covered. You can read every changed line and still miss the most important problem: part of the requested work never made it into the patch. Code review still matters. As agents take on more of the implementation, the review needs to cover the work they claim to have completed.
More code, the same amount of attention
When an agent can turn a short request into changes across a dozen files, writing code stops being the slowest part of that particular workflow. Understanding what was delivered can take longer. Each additional patch asks someone to recover the intent, follow the implementation and decide whether the result belongs in the product.
Anthropic’s account of building Scion offers an unusually large-scale example. The company reports daily merged code changes growing from roughly 2,500 in May to more than 30,000 in September 2026. Engineers on the Scion team still review every change request, with their attention shifting toward intent. Those numbers describe Anthropic’s environment; the pressure on reviewer attention is the part worth examining in our own workflows.
Source: Anthropic, Redesigning source control at Anthropic
A growing queue of PRs makes it tempting to skim more quickly. But the harder questions often require stepping outside the diff. What did the user actually ask for? Which existing behavior had to survive? What would demonstrate that the work is complete?
Missing work has no line in the diff
Imagine asking an agent to add a background CSV export. The agreed behavior is straightforward: the user starts an export, can close the page, and returns later to download the result. The agent adds an endpoint, a worker and a progress screen. The happy-path test passes. The implementation looks coherent.
There is one omission: the job identifier lives only in the page’s memory. Closing the tab loses the connection to the export. The worker may finish successfully, but the user cannot find the result when they return. Every added function might behave exactly as its test expects. The promised experience is still incomplete.
The diff shows what the agent changed. The task also tells you what it may have forgotten.
A careful code reviewer can catch this. The point is to make that comparison a deliberate part of every review. The requirement about returning later should produce a question about persistence, a search for the recovery path and a check that exercises it. Otherwise, the shape of the patch quietly becomes the definition of the task.
The unit of review is the agent’s work
Agent review starts with the agreed request and follows it through to the delivered behavior. The patch remains essential: permission errors, broken retries and unsafe data handling still live in code. Around that patch sit other things worth checking: acceptance criteria, repository conventions, decisions made during the task and the evidence behind the final handoff.
That wider view gives a reviewer a way to question both omissions and unnecessary changes. Did the agent preserve the existing access rules? Did it introduce a new service for a task that needed a small fix? Did it quietly narrow the requirement to fit the solution it had already built? A local implementation choice can be reasonable while the overall delivery drifts from the request.
For the export example, the useful finding is concrete: the task requires recovery after closing the page; the client stores the job identifier only in memory; no recovery path was found in the inspected code; the existing test keeps the page open. That gives the author something specific to investigate and the human reviewer a clear reason to care.
A second AI that can follow the first AI’s work
This is what we mean by an AI that understands AI: a reviewer able to connect an agent’s task, available execution records, code changes and completion claims. It needs to recognize that a confident summary is a claim, that a command in a plan may never have run, and that passing a narrow test leaves other requirements unanswered.
The second agent needs a separate review assignment and access to the relevant evidence. Asking it to approve the first agent’s explanation invites the same assumptions to pass through again. Asking it to examine each requirement against the repository and recorded results gives it a more useful job. Missing context should remain visible as an unanswered question.
A second AI can make mistakes too. It may share the author’s blind spots or invent an issue that disappears on inspection. Its findings therefore need their own support: the affected behavior, the relevant code, the requirement at risk and, where possible, a reproducible check. Using another model does not by itself establish independence or correctness.
Give “done” something a reviewer can inspect
A useful handoff lets someone trace a completion claim back to evidence. For each material requirement, we want the review to distinguish three outcomes:
- Supported: the inspected implementation and relevant checks provide evidence for the requirement.
- A gap found: a specific behavior conflicts with the agreed task or a project constraint.
- Unverified: the available context or checks do not establish whether the requirement is met.
Those outcomes must refer to a specific code revision. A successful test from before the final edit cannot establish the behavior of that edit. A report also needs to say which checks actually ran and which were only suggested. This makes the remaining decision easier for a person to inspect without treating either agent’s confidence as proof.
Where Inkspect fits
Inkspect brings this broader review into your workflow. Code review stays at its core. It connects agent-written changes to the task, repository context, team rules and available test evidence, then produces findings that a human can assess and a coding agent can act on.
Inkspect reviews Git-based work and keeps findings tied to the code revision and evidence behind them. Scion compatibility is a separate roadmap item, dependent on an accessible integration interface and validation against it.
Code review has more work to do as agents write more code. Reading the patch remains valuable. Reviewing whether the agent delivered the requested outcome makes that reading part of a stronger decision. A second AI can help assemble and challenge the evidence, while people retain responsibility for the intent, tradeoffs and acceptance of the work.
Explore the Inkspect agent review workflow
Every line. Worth a second look.