如何審查 AI 編碼智能體撰寫的 Pull Request

A pull request from a coding agent usually looks better than one from a tired human. The description is complete, the code is formatted, the tests pass, and every changed line has a reason. That polish is exactly what makes it hard to review. The usual signals that something is off (a messy diff, a vague description, a missing test) aren't there.

The mistakes agents make are different from the ones people make. They rarely forget a semicolon. They often solve the problem in a way your team decided against, or change something that other code relies on without noticing the other code exists. Both of those are invisible if you only read the diff.

Here is the checklist we use.

1. Read the description last

Agents write confident summaries of what they intended to do. Read the diff first and form your own view of what changed, then compare it with the description. Gaps between the two are where the bugs are: "refactored the retry logic" that also changed the timeout default, "added a field" that also made an existing one optional.

2. Ask who depends on what changed

For every function, type or exported value the PR changes, find the callers. Not the ones in the diff, all of them.

An agent asked to "add a required orgId parameter to loadSettings" will update the function and the callers it found. Whether it found all of them depends on how it searched. Your editor's "find references" or grep takes ten seconds and is the highest-value thing you can do on an agent PR.

Be suspicious when a tool says nothing calls a function. In our own measurements, a code graph reported zero callers, labelled "exact", for 17 of 26 functions that had real callers. "No results" from a tool means "unknown", not "safe".

3. Check it against what the team already decided

Every codebase has rules that aren't enforced by the compiler: all database access goes through the repository layer, prompts live in files and not inline strings, model calls go through one shared client, no new dependencies without discussion. People learn these from review comments. Agents don't, unless they're written down somewhere the agent reads.

When you review, ask: does this follow how we do things here, or just a way that works? Agent PRs drift toward the most common pattern on the internet, not the one your team picked.

4. Look for scope creep

Agents like to tidy. A PR to fix one bug touches three unrelated files because the agent "noticed" something. Each tidy-up is a small, unrequested change that nobody asked to review. Ask for them to be split out, or reverted.

5. Check the tests test the change

Agents are good at making tests pass, and occasionally that means changing the test. Look at test diffs as carefully as code diffs: a loosened assertion, a new skip, a mock that now returns whatever the code expects. A green check on a PR that edited its own tests means less than it seems.

6. Check error paths, not just the happy path

Agent code tends to handle the case it was asked about. Look at what happens on the failure branches: swallowed errors, a catch that logs and continues, a fallback that silently returns an empty list. These pass every test that only exercises the success case.

Move the checks earlier

Most of this checklist is the reviewer doing work the agent could have done before opening the PR. You can move a lot of it to write time:

• Write your decisions down where the agent reads them. CLAUDE.md, .cursor/rules or AGENTS.md, with the reason for each rule, not just the rule. Agents follow rules they can see.
• Make "find all callers" part of the task. Tell the agent to list every caller of anything whose signature it changes, and to update or explain each one. It works noticeably better than hoping it does it on its own.
• Keep PRs small. One concern per PR. Agents will happily do five things at once if you let them, and five things are much harder to review than one.

Automate the two hard parts

Steps 2 and 3 are the ones that don't scale by hand. Finding every caller of every changed symbol, and remembering every decision the team has made, is a lot to ask of a reviewer on their tenth agent PR of the day.

That is what we built Tently for. It is an AI code reviewer for GitHub that checks each pull request against the code that depends on it and against your team's decisions, which it learns from merged pull requests, review threads and docs. Findings land on the PR with evidence: the affected callers, or the decision and where it came from. It runs next to whatever reviewer you already use.

The same decisions are available while the agent writes, through an open-source MCP server for Claude Code, Cursor and Codex (tently-team/tently-mcp), so fewer problems reach the PR at all.

With or without a tool, the checklist holds:

1. Read the diff before the description.
2. Find every caller of what changed.
3. Check it against your team's decisions.
4. Push back on scope creep.
5. Review test changes as carefully as code.
6. Read the error paths.