Code Review in the Agentic Era: Review the Change, Not the Confidence

Senior engineers should review AI-written pull requests by reconstructing the intended behavior, running the risky path locally, and making the merge controls enforce what a hurried reviewer cannot. Don’t try to compensate for an agent’s output volume by reading faster: review the invariants, the boundaries, and the last commit that actually reaches main.

Start by making the PR explain itself

The unpleasant property of agent-written code isn’t that it’s always wrong. It’s that it can be locally plausible across 30 files while quietly changing an assumption nobody named: retries are no longer idempotent, a permission check moved after a fetch, an old API response is now treated as complete, or a migration is safe only on an empty database.

Before opening the diff, require a short behavioral contract in the PR description. If the author used an agent, have the author ask it for this—but make the human own the answer. A useful contract says what user-visible behavior changes, which inputs or states are intentionally unchanged, which files are generated or mechanical, how the change was tested, and the one failure mode the author is least certain about. “Implemented feature X and tests pass” is not a contract.

That last uncertainty line matters. It gives you a place to start that isn’t the first file in alphabetical order. If the PR cannot state its changed behavior in five or six sentences, split it or send it back for a plan. An agent can produce a coherent patch without producing a coherent unit of review.

Spend the first 90 seconds on shape, not lines

Use the file list to decide what kind of review this is before you inspect implementation details. A change that touches a request handler, authorization helper, database migration, lockfile, and deployment manifest is not “one feature.” It is five different risk surfaces, and each deserves a different question.

# What changed, before reading the patch?
gh pr diff 482 --name-only

# Read the intent, checks, and review state from the terminal.
gh pr view 482 --json title,body,files,commits,statusCheckRollup,reviewDecision

# Use a disposable worktree when the risky path needs to run locally.
gh pr checkout 482 --worktree ../review-pr-482

The GitHub CLI supports listing only changed paths, viewing selected pull-request fields as JSON, and checking a PR out into a worktree. Use that to keep the review branch out of your current working directory instead of promising yourself you’ll clean up later.

Now label the files mentally: behavior, policy, data, dependency, generated output, and tests. Generated files and formatting changes should be collapsed or isolated so they don’t hide the two hand-written lines that change a default. GitHub’s review UI can filter files and hide whitespace differences; use those features when a broad mechanical edit makes the meaningful diff hard to see.

Review the seams where an agent is weakest

AI-generated code is often competent inside a function. The expensive mistakes live at the seams: between a new helper and an existing convention, between an API client and a retry policy, between a migration and production data, or between an authorization decision and the resource it protects.

For every changed boundary, ask one concrete question: What happens when the dependency is slow, absent, malformed, duplicated, stale, or owned by a different tenant? You don’t need six comments asking for more null checks. You need one reproduced counterexample that proves the change has—or lacks—the intended failure behavior.

Check the test diff with the same skepticism as the production diff. An agent can write a test that asserts its own implementation detail, seed fixtures that conveniently avoid the hard case, or mock the very call whose ordering matters. Look for a test that would fail if you reverted the behavior change, not merely one that executes the new lines. For a risky path, run the narrow test yourself, then alter one input that the PR claims is handled.

Treat a passing CI run as evidence, not a review

CI answers whether the configured checks passed for a commit. It does not answer whether those checks cover the changed contract. For dependency changes, inspect both the manifest or lockfile diff and the dependency view; GitHub explicitly notes that its dependency review may not capture every change a source diff can reveal.

For migrations and operational changes, review the rollback before approving the forward path. Can the application run with old and new code during a deploy? Is the migration reversible, or at least safe to stop halfway through? Does the new configuration have a default that changes production behavior before the feature flag is enabled? These are not questions an agent can settle by producing a green unit-test screenshot.

Make the platform catch the review that arrives too early

The most practical change is to stop treating approval as permanently attached to a PR. On protected branches, enable required reviews, required status checks, and dismissal of stale approvals when code-modifying commits arrive. If the agent—or its human operator—pushes a follow-up after feedback, the old approval should no longer mean “I reviewed this.”

For security-sensitive, deployment, migration, and shared-platform paths, put the responsible team in CODEOWNERS and require code-owner review. GitHub can request those owners automatically, and branch protection can block merge until the relevant owner approves. This is routing, not bureaucracy: send the authorization edit to the people who know what authorization means in your system.

A reasonable starting policy is one required approval for ordinary changes, then a code-owner approval for named high-risk paths. Add a second required approval only where your team can reliably supply it; a rule everyone bypasses is theatre. Also enable “require approval of the most recent reviewable push” if agents commonly push revisions after comments and you need an explicit final pair of eyes.

Leave review comments that force a decision

Avoid comments like “Are we sure?” They invite a fluent explanation, which is the cheapest thing an agent can generate. Ask for an observable decision instead: “Add a test showing a retry after the write does not create a second invoice,” “Which callers rely on this default being false?”, or “Show the rollback command and state whether it is safe after partial execution.”

When the patch is too broad to establish those answers, request a smaller PR. That is not a failure to review generated code; it is the review. Senior review is increasingly the job of setting the boundary at which a change becomes understandable, testable, and safe to own after the agent has moved on.