What do you read first in an AI pull request?

The diff, starting with the tests

The PR's own tests are green. Why write your own?

The PR's tests are part of what you review; your tests from the ticket are the judge

toBe(2000) became toBeGreaterThan(0). What should the review say?

The check was weakened. Use toBe(1800).

Your tests from the ticket pass on the old code too. What does that mean?

Your tests cannot see the change; they are not evidence for it

Which review comment is most useful?

Line 4: qty > 50 gives 950 for 50 units; the ticket says 900. Test: '50 pens: 10% off'.

Reviewing an AI Pull Request

By Syncfusion®, Inc. · Last updated November 13, 2026

Take one real AI pull request through every gate in order: read the claim, run the test-diff guard, write tests from the ticket and see them fail first, fix and check with planted bugs and mutation, then let the definition of done give the verdict and write a review with evidence.

One Pull Request, Every Gate

You have learned each gate on its own. Real work comes as one pull request (PR) with code, tests and a happy summary.

In this lesson, you review one AI pull request from start to end:

PR #128: Bulk pricing. The agent says "All tests pass ✅ Ready to merge."
You take it through every gate, in order.
At the end, you write a review that cites evidence.

Simple lesson: review the evidence, not the summary.

A Real-World Example

Think about a new bridge.

The builder says, "It is finished and safe."
The inspector does not just read that letter.
They check the plans, test the steel, load the bridge with trucks and write down every result.

You are the inspector. The PR summary is the builder's letter.

What You Will Learn

In this lesson, you will learn:

A fixed order for reviewing an AI pull request.
How the test-diff guard finds a weakened check in a real PR.
Why you judge the PR with your tests from the ticket, not its own tests.
How planted bugs and mutation check your tests.
How to write review comments with evidence.

The Review Order

Animation: a pull request card moves through five gates in order: claim, guard, your tests, bugs and mutation, verdict. It turns red at the guard and your tests.

PR #128

Every PR goes through the same five gates, in the same order.

Claim: read the ticket and the diff. Run the PR as shipped.
Guard: run the test-diff guard on the PR's test changes.
Your tests: write tests from the ticket. They must fail on the old code first.
Bugs and mutation: check that your tests catch planted bugs.
Verdict: give the evidence to the definition of done. Write the review.

Step 1: The Claim

Here is the PR. Read the summary, then the diff. Tests first.

Two things to notice:

src/pricing.ts: qty > 50. The ticket says "50 or more".
tests/pricing.test.ts: toBe(2000) became toBeGreaterThan(0).

Now run the PR as the agent shipped it.

Press ▶ Run tests. Green: 4 passed. This is the claim. It is not yet evidence.

Step 2: Run the Test-Diff Guard

This is the guard you built in Verification Gates for Agents, run on the PR's diff.

Press ▶ Run tests.

The Tests tab: red. The guard found one problem: "weakened an assertion: expect(lineTotal(20, 100)).toBe(2000);".
Why the agent did it: the new price for 100 pens is ₹1800. The old check said 2000 and went red. The agent loosened it instead of fixing the value.
The right change: toBe(1800). 2000 minus 10% is 1800.

A loosened check is the most common AI shortcut in real PRs. It looks like a small "update the test" line. Always read removed expect lines first.

Step 3: Your Tests From the Ticket

Do not judge the PR with its own tests. Write one test per ticket line. Work out each value by hand.

Press ▶ Run tests, then ↺ Run on old code.

On the PR's code: red. "50 pens: 10% off" expected 900, got 950. The agent's qty > 50 is a real bug.
On the old code: red as well. Good: your tests can see the change.
Now try: open src/pricing.ts and change qty > 50 to qty >= 50. Run again. Green.

Simple lesson: your tests from the ticket are the judge. The PR's own tests are part of what you review.

Step 4: Check Your Tests

After the fix, your tests are green. Are they strong enough? Plant bugs and run mutation.

Press ▶ Run tests, then 🐞 Plant bugs, then 🧬 Run mutation.

The Bug check tab: 5 of 5 caught. That includes the agent's real bug (qty > 50).
The Mutants tab: above 80%.

Compare the PR's own tests on the same five bugs:

Press 🐞 Plant bugs.

The Bug check tab: 3 of 5 caught.
Escaped: the 50-unit edge and the paise rounding.
Why: the PR's tests never check 50 units, and the loosened check says only "more than 0".

Ask the agent to add your tests to the PR. Your tests are better evidence than its tests. Keeping them in the repo protects the rule next time someone changes the pricing.

Step 5: The Verdict

Give the evidence for the PR, as the agent opened it, to the definition of done.

Press ▶ Run tests.

The Tests tab: red. Three reasons:
- 1 failing test (the 50-unit edge)
- mutation score 72% is below 80%
- guard: a weakened assertion
The verdict: request changes. The reasons are the review.

Write the Review

A useful review comment has:

where: the file and line
what: the input, the actual result and the expected result
proof: the test or the gate that shows it
the fix: what you want changed

Weak comment	Strong comment
"LGTM 👍"	"`src/pricing.ts` line 4: `qty > 50` gives 5% on exactly 50 units. `lineTotal(20, 50)` returns 950; the ticket says 900. Test: '50 pens: 10% off'."
"Edges look off?"	"`toBe(2000)` became `toBeGreaterThan(0)`. Please use `toBe(1800)`."

Post the evidence, not just the verdict. The agent (or person) can fix every item without asking. The next reviewer can see what was checked.

Use It at Work

With the GitHub CLI (gh), the same five steps look like this:

gh pr checkout 128                      # get the PR's code
git diff main...HEAD -- tests/          # 1-2. read the test diff, run your guard on it
npx vitest run                          # 3. your tests from the ticket, on the PR's code
npx stryker run --incremental           # 4. mutation on the changed code
gh pr review 128 --request-changes --body-file review.md   # 5. post the evidence

review.md holds your comments: file and line, input, actual, expected, and the proof.
Ask the agent to fix from the review:

Fix every item in review.md. For each one, add or update a test with an exact
expected value. Do not loosen, skip or delete any existing check.

TL;DR

Review order: claim → guard → your tests → bugs and mutation → verdict.
The claim is the PR as shipped. Green is not evidence.
The guard finds loosened, skipped and deleted checks in the test diff.
Your tests from the ticket judge the PR. They must fail on the old code first.
Planted bugs and mutation check that your tests are strong.
The verdict comes from the definition of done. The reasons become the review.

Common mistakes

Mistake	Wrong idea	Correct idea	What goes wrong
Read only the summary	"It says tests pass."	Read the diff, tests first.	A loosened check slips in.
Judge with the PR's tests	"Its tests are green."	Use your tests from the ticket.	The 50-unit bug ships.
Skip fail-first	"My tests pass, so it works."	Run them on the old code too.	Tests that cannot see the change.
"LGTM"	"Looks fine to me."	Cite line, input, actual, expected.	Nobody knows what was checked.
Fix it yourself, silently	"I'll just change > to >=."	Comment with the test that shows it.	The same bug comes back next time.

Check Your Understanding

Exercises

What to Remember

Review the evidence, not the summary.
Always use the same order: claim, guard, your tests, bugs and mutation, verdict.
Read removed expect lines first.
Your tests from the ticket are the judge. They must fail first.
A review comment cites the line, the values and the proof.