DEV Community: Riven Desk

STOP conditions I use before merging an AI agent PR

Riven Desk — Tue, 08 Sep 2026 14:16:03 +0000

A 10-minute review bar tells you how to look. STOP conditions tell you when to stop looking and refuse the merge as written.

I wrote the timed review here: I stopped rubber-stamping AI PRs — here's the 10-minute review bar I use. The short checklist is here: How I review AI agent PRs in 10 minutes.

This post is the hard edge: concrete conditions where I reject, ask for a split, or ask before continuing — even if CI is green and the agent summary sounds confident.

What a STOP condition is

A STOP is not a style nit. It is a pre-agreed line that ends the current review path.

For each one I pick one of three outcomes:

Reject / request changes — the PR can stay one unit, but it must change before merge.
Split — the work is too mixed; ship the intent first, park the rest.
Ask — I do not have enough written intent, ownership, or rollback story to decide alone.

If a condition fires, I do not “finish later and LGTM.” The STOP is the decision.

STOP 1 — Blast radius with no written plan

Fire when: a large file set changed across modules or layers, with no short plan in the ticket or PR explaining why that radius was required.

Continue only if: a human wrote the boundary — e.g. “touch A and B; leave C; no lockfile.”

Outcome: Ask for the plan, or split into the minimal fix plus follow-ups. Unplanned multi-file agent work is where drive-by renames hide.

STOP 2 — Mixed concerns in one “quick fix”

Fire when: app logic, lockfile/dependency churn, and infra (CI, deploy, secrets wiring) land together under a small-fix title.

Continue only if: each concern is necessary for the same intent and rollback is still one revert — rare for true quick fixes.

Outcome: Split. Dependency bumps deserve their own attention; burying them next to a bugfix is how rubber-stamping happens.

STOP 3 — “No behavior change” while the surface moved

Fire when: the summary says refactor-only / no behavior change, but types, routes, public APIs, flags, or error contracts moved.

Continue only if: the PR lists the external surface that changed and how callers stay safe — with tests or a migration note.

Outcome: Reject the claim language and request changes until the description matches the diff. Summary theater is merge-blocking when it contradicts the file list.

STOP 4 — No one-sentence rollback story

Fire when: you cannot say how you undo this at 2am: single revert, documented forward fix, or explicit irreversible step with a plan.

Continue only if: the change set is coherent, or irreversible pieces (migrations, permission flips) have a written plan in the PR.

Outcome: Ask for the rollback sentence before approve. Agent PRs often lack the mental model you would have authored yourself.

STOP 5 — Security-sensitive paths you only skimmed

Fire when: auth, sessions, permissions, payments, secrets, shell/filesystem, templated commands, or new outbound network calls changed — and you only skimmed those hunks.

Continue only if: you read them (or parked them), with at least one failure/abuse check for the sensitive bit.

Outcome: Ask for time or a second reviewer, or reject until the hotspot is isolated. Ten-minute review is not a license to wave past auth.

STOP 6 — Tests that would not catch the bug returning

Fire when: CI is green, but tests only assert something returned,” noisy snapshots, or paths that fail solely if the function is deleted.

Continue only if: at least one assertion would fail on the regression you care about — ideally a negative or edge path from the human intent.

Outcome: Request changes. Weak tests make green feel like permission.

STOP 7 — No owner for the follow-up

Fire when: the PR crosses team or on-call boundaries and nobody is named for if this misbehaves Monday.”

Continue only if: an owner (person or rotation) is explicit in the PR or ticket.

Outcome: Ask. Agents do not own production; humans do.

How I apply these

I run them early, during the file-list / hotspot pass — not after half an hour of line comments. When one fires, I name it in the review: which STOP, reject vs split vs ask, and the smallest evidence that clears it. Same language for juniors and seniors.

No fake “bugs down X%” metrics. The point is fewer merges you cannot explain, and fewer 2am archaeology sessions on agent-authored blobs. If a PR cannot clear these STOPs, that is useful signal: narrower intent, a written plan, a split, or a deeper review — not a faster approve.

I packaged the checklist, Cursor-oriented rules, and review prompts I use into a small AI Agent Code Review Kit ($29): https://chopragunji.gumroad.com/l/nxoboi

For a second set of eyes on one difficult agent PR, the Agent PR Audit is here: https://chopragunji.gumroad.com/l/byoyi

— Riven Desk

What STOP conditions do you treat as merge-blockers on agent PRs? Worst drive-by you caught (or wish you had) — drop it in the comments.

How I review AI agent PRs in 10 minutes (checklist you can steal)

Riven Desk — Tue, 08 Sep 2026 10:49:58 +0000

AI-generated pull requests are getting better at looking finished. That is exactly why I review them with a small, repeatable bar instead of trusting a green check, a long summary, or my first impression.

Here is the tight version of my 10-minute review. It is designed for the moment when an agent has opened a PR and you need to decide whether it deserves attention, revision, or a merge.

Minute 1: Restate the job

Read the issue, acceptance criteria, and the PR title. Then write one sentence in your own words: “This change should do X, for Y, without breaking Z.”

If you cannot write that sentence, do not start reviewing the diff yet. Ask for clarification or inspect the surrounding code until the boundary is clear. A fuzzy request makes every later judgment fuzzy too.

Minutes 2–3: Check the shape of the change

Look at the file list and the diff size before reading individual lines.
“While I was here” is not automatically a bonus. Split unrelated work into a separate PR, or send the change back with a narrower boundary.

Minutes 4–6: Trace the behavior

Follow the main path from input to output. Read the changed code as if you were the caller, not as if you were grading the agent’s explanation.

Check the happy path, then ask:

What happens when the input is empty, duplicated, malformed, slow, or very large?
What happens on retries, partial failure, or a missing record?
Does the change preserve existing permissions, validation, and error handling?
Could it leak data, log a secret, create a race, or make an expensive call in a loop?

I also compare the implementation with local conventions. An elegant pattern in the abstract can still be the wrong pattern for this repository. Consistency is a maintenance feature.

Minutes 7–8: Test the test

Do not treat the presence of tests as proof of coverage. Read what the assertions actually distinguish.

A useful test should fail when the important behavior regresses. Look for the boundary cases you named in minute one, plus at least one negative path. If the test only checks that a function returns something, or snapshots a large object without meaningful assertions, it may be test-shaped documentation rather than protection.

I call it summary theater when the description is polished, specific-sounding, and only loosely connected to what changed. “Improved reliability” is not evidence. “Added validation” is not evidence until you can point to the validation and its tests. A summary is useful as an index; it is never a substitute for verification.

Minute 10: Choose one of three outcomes

Merge: The boundary is clear, the behavior matches the job, risks are understood, and the tests protect the important cases.
Request changes: Name the smallest concrete correction, the scenario it fixes, and how you would verify it.
Split or close: The work has scope creep, the premise is wrong, or review would be safer as a fresh proposal.

A short review is not a shallow review. It is a time-boxed way to spend attention on the highest-risk claims first. If the change cannot clear this bar in ten minutes, that is useful information: the PR needs a better boundary or a deeper review, not a faster “LGTM.”

I wrote the longer version of this approach here: I stopped rubber-stamping AI PRs — here’s the 10-minute review bar I use.

If you want a ready-to-use starting point, my AI Agent Code Review Kit packages the checklist, Cursor rules, and prompts. For a second set of eyes on one difficult change, the Agent PR Audit is available too.

— Riven Desk
Run the smallest relevant test command yourself, then inspect the diff for untested branches. Weak tests are a common failure mode because they let an agent demonstrate motion without demonstrating correctness.

Minute 9: Read the summary last

Now read the PR summary and let it explain rather than persuade. Compare each claim with the diff and test output.

Are the changed files where you expected them to be?
Is the agent touching configuration, dependencies, migrations, or public APIs unnecessarily?
Did a focused fix turn into a refactor?
Are generated files, formatting churn, or unrelated cleanup hiding the meaningful lines?

This is where I catch scope creep. An agent may solve the stated problem and quietly redesign three neighboring systems.

I stopped rubber-stamping AI PRs — here's the 10-minute review bar I use

Riven Desk — Tue, 08 Sep 2026 08:56:00 +0000

Coding agents are great at producing diffs. They're less great at knowing when a "quick fix" quietly became a 30-file refactor with a new dependency, a renamed helper, and a test suite that only fails if you delete the function entirely.

I kept merging PRs that looked fine: confident summary, CI green, "improved robustness" in the description. Then: drive-by renames, lockfile churn I didn't ask for, auth-adjacent code I never mentally authored. The failure mode wasn't "AI bad" — it was rubber-stamping when review bandwidth couldn't keep up.

So I stopped relying on vibes. I forced a thin, explicit bar I can finish in about ten minutes. Shareable below — steal it, argue with it, add to it.

What "AI-aware" review actually means

Tests that prove nothing. Happy-path asserts that pass even if the bug returns.
Unclear rollback. You didn't write the mental model, so at 2am you don't know what to revert.

AI-aware review is not "distrust everything." It's matching human intent to agent delivery before you read every line like it's 2014.

The 10-minute review bar

Do these in order. If something fails early, stop — don't sink twenty minutes into a PR that should be split.

1. Restate the human intent (60 seconds)

Ignore the agent summary first. Write one sentence of what you (or the ticket author) asked for.

"Add rate limiting to the public signup endpoint."

If you can't state that without reading the diff, the PR description is already broken. Fix that before diving in.

2. File-list sanity check (90 seconds)

Scan the changed files against

3. Hotspots first, not alphabetical (2 minutes)

Jump to risky surfaces before cosmetic churn:

Auth, sessions, permissions
Payments / money paths
Filesystem, shell, eval, templated commands
New outbound network calls
Secrets, tokens, .env patterns, anything that looks like a prompt or credential leaked into code or comments

You're not doing a full security audit in ten minutes. You're checking whether the agent wandered into dangerous neighborhoods without being asked.

4. Scope creep pass (90 seconds)

Look specifically for:

Mass formatting or import reshuffles
New dependencies you wouldn't have chosen
"No behavior change" claims while types or public APIs moved
Extra abstractions the ticket never named

Agents love helpfulness. Helpfulness without a plan is how a one-line bugfix becomes a mini rewrite.

5. Rollback story (60 seconds)

6. Test quality, not coverage theater (2 minutes)

Read the tests as adversarial:

Would they fail if the original bug came back?
Or do they only fail if the function is deleted?
Are edge cases / failure paths covered for the risky bits?

Green CI with weak tests is how rubber-stamping feels safe.

7. Ownership & STOP conditions (60 seconds)

Before approve:

Who owns the follow-up if this misbehaves?
Was there a written plan for a multi-file change?
Does this cross your personal STOP line?

STOP and ask (or split) when:

The agent touched a large file set with no plan written down.
Lockfile + app logic + infra landed in one "quick fix."
The summary says "no behavior change" but types, routes, or public APIs moved.
You can't explain the rollback path in one sentence.
Security-sensitive files changed and you only skimmed them.

Those are merge-blockers for me, not style nits.

Free checklist (copy/paste)

Use this as a PR comment template or a personal pre-merge gate:

AI PR — 10-minute bar

[ ] Human intent in one sentence (not the agent summary)
[ ] File list matches intent — no drive-by files
[ ] Hotspots checked: auth / payments / fs / shell / network / secrets
[ ] No surprise deps, renames, or formatting-only churn mixed in

## Optional: ask the agent for a blast-radius summary

Before you deep-read, paste something like this into the same agent (or a fresh chat with the diff):

text
Summarize this PR for a human reviewer:
1) Intended change in one sentence
2) Files that seem unrelated to that intent
3) Security-sensitive touchpoints
4) New dependencies or infra changes
5) Suggested split if the blast radius is too wide
Be skeptical. Prefer "I might be wrong" over polish.


Treat the answer as a map, not truth. You're still the reviewer.

## Habits that compound

The checklist works better if a few team habits exist upstream:

- **Commit or stash before long agent runs.** Easy revert beats archaeology.
- **Plan before multi-file edits.** A five-bullet plan in the PR beats a post-hoc apology.
- **PR description must separate** what the human wanted vs what the agent added. That single split kills a lot of summary theater.
- **Prefer small agent loops.** One intent per PR — agents can chain; you don't have to merge the chain as one blob.

It's just an explicit bar so juniors and seniors share the same merge / fix / split language.

## What this is not

- Not a claim that AI review tools replace humans.
- Not enterprise GRC, compliance theater, or a vendor pitch dressed as process.
- Not fabricated "bugs down X%" metrics. I don't have those, and you shouldn't trust posts that invent them.

I'm not anti-agent. I'm anti-rubber-stamp. Agents ship faster than thoughtful review capacity on small teams; a thin bar is how I keep both speed and sleep.

---

I packaged the checklist, Cursor-oriented rules, and review prompts I actually use into a small **AI Agent Code Review Kit** ($29): [https://chopragunji.gumroad.com/l/nxoboi](https://chopragunji.gumroad.com/l/nxoboi)

If you've got a better checklist item — or a war story about an agent drive-by — drop it in the comments. I'll steal the good ones.
[ ] Rollback story is clear (single revert or documented plan)
[ ] Tests would fail if the bug returned
[ ] STOP conditions clear? (big unplanned blast radius, mixed concerns, "no behavior change" lies)

Decision: merge / request changes / split PR
Notes:

Ask out loud: if this breaks at 2am, can I revert cleanly?

Single coherent change set → usually yes
Mixed refactors + feature + lockfile → often no
Data migration or irreversible side effects → pause and demand a plan

If you didn't mentally author the change, the rollback question matters more, not less. that one sentence. Ask:

Is every file necessary for the intent?
Any renames, docs, configs, or lockfiles that weren't requested?
App logic + infra + dependency bump in one "quick fix"?

Unrelated files → park them, ask for a split, or open a follow-up. Do not negotiate with yourself ("it's probably fine").
Classic code review still matters: correctness, readability, design. Agent PRs add a few failure modes that show up more often:

Scope creep. Unrelated files, formatting-only churn, "while I was there" refactors.
Surprise surface area. New deps, new network calls, shell/filesystem touch points you didn't request.
Summary theater. The agent writes a polished narrative that doesn't match the file list.