Reviewing Code Nobody Typed: Human Judgment in an Agentic Workflow
A pull request arrives with thirty seven changed files, polished comments, and a description that explains the architecture with unusual confidence. The reviewer approves it. Two days later the team finds the bypassed authorization rule. Nothing looked careless. That was part of the problem.
🗓️ Last updated: September 2026
A pull request arrives with thirty seven changed files, polished comments, comprehensive tests, and a description that explains the architecture with unusual confidence. The reviewer reads the summary, sees green checks, and approves. Two days later the team discovers that the patch duplicated an authorization rule and bypassed the actual policy service.
Nothing in the pull request looked careless. That was part of the problem.
Code review must change when producing plausible code becomes cheap. The reviewer's job is no longer to reward effort or infer care from presentation. It is to test whether the change belongs in the system.
Review intent before implementation
Begin with the task contract. What outcome was requested? Which boundaries were protected? Which files were expected to change? Which checks were required? If the pull request cannot answer these questions, reviewing the diff immediately is premature.
Then inspect the change map. Group files by purpose: production behavior, tests, configuration, dependencies, migrations, generated output, and documentation. Unexpected groups deserve attention. A small feature that changes deployment configuration may be correct, but it has crossed a boundary the task should explain.
Read the dangerous parts first
Review by risk, not file order. Start with public contracts, authentication, authorization, data access, migrations, concurrency, error handling, dependencies, and destructive operations. Generated formatting changes can wait. The review interface may sort alphabetically. Architecture does not.
Ask four questions of every material change:
Is this behavior required?
Is this the correct architectural location?
What existing invariant could it violate?
What evidence would expose that violation?
These questions work regardless of whether the author is a human, an agent, or the increasingly common partnership in which neither wishes to discuss individual responsibility.
Demand provenance without demanding a transcript
The reviewer needs the base commit, task contract, agent and tool version where relevant, files changed, commands run, and unresolved concerns. The reviewer usually does not need thousands of tokens of internal conversation. Preserve the full session for diagnosis according to policy, but present a concise, structured handoff for review.
Require citations from the summary to code, tests, and design decisions. A claim that compatibility was preserved should point to the contract check. A claim that a race was fixed should point to the synchronization change and concurrency test. Fluent explanation is not evidence. It is an invitation to find evidence.
Control diff shape
Large diffs reduce review quality. Ask agents to separate mechanical changes from behavioral ones. Package upgrades, formatting, generated output, and feature logic should not share a commit unless they are inseparable. Small coherent commits allow reviewers to inspect intent and revert safely.
Set escalation thresholds for dependency additions, public API changes, migrations, permission changes, and unusually broad diffs. A threshold need not reject the change. It changes the review route and required owners.
Use code ownership for domain boundaries. A coding agent can edit a payment module. It cannot manufacture the payment team's accountability by adding them to the pull request description.
Review the tests as production code
Tests written by the same agent are useful but not independent. Inspect whether they prove the requirement or simply reproduce the implementation. Look for deleted cases, weakened assertions, excessive mocking, snapshots accepted wholesale, and tests that never exercise the changed branch.
Run focused experiments when the risk warrants it. Revert the production fix and confirm the regression test fails. Change a boundary value. Simulate a timeout. Review is not confined to reading. Sometimes the quickest way to understand code is to make its assumptions uncomfortable.
Preserve human attention
Do not send every generated patch to the same approval queue. Classify work by risk. Documentation and mechanical refactors with strong checks may use lighter review. Contract, security, data, and infrastructure changes require owners with the relevant context.
Measure review load, rework, and escaped defects. If agent throughput rises while reviewer queues and defect rates rise faster, the organization has automated typing and created a new bottleneck. The dashboard may still call this productivity because dashboards enjoy optimism.
Failure modes
The first failure is summary substitution. The reviewer reads the agent's explanation instead of the code. Summaries guide attention; they do not replace inspection.
The second is green check hypnosis. Automated verification reduces risk but cannot prove that the requested behavior was correct or complete.
The third is authorship bias in either direction. Generated code is not automatically suspect, and human code is not automatically wise. Apply the same engineering standards while adjusting scrutiny for scale and provenance.
The architect's checklist
Review the task contract before the diff.
Inspect high risk boundaries before routine files.
Require a structured handoff with evidence links.
Separate mechanical and behavioral changes.
Route sensitive changes to accountable domain owners.
Track reviewer load, rework, and escaped defects together.
The purpose of review is not to determine whether code looks as though a competent person wrote it. Modern tools can arrange that appearance very efficiently. The purpose is to determine whether the change deserves to become part of the system.
