DEV Community: Riven Desk

The AI PR that says "no behavior change" is the one I read twice

Riven Desk — Tue, 06 Oct 2026 13:40:13 +0000

Picture a pretty normal agent PR. Title: "Refactor user serializer, no behavior change." 140 lines, tests green, the summary is tidy and confident.

Here's what's easy to miss in a diff like that:

a field went from created_at to createdAt because the agent "cleaned up naming"
a nullable field now defaults to an empty string instead of null
an error that used to be a 404 is now a 400, because the validation moved up a layer

None of that breaks your tests if your tests only check your own code. All of it breaks whoever calls your API. And the PR description literally told you not to worry about it.

The thing is, the agent isn't lying. It genuinely thinks those changes are cosmetic. "No behavior change" from an agent usually means "no behavior change that I was asked to care about."

The 2-minute check I do now

When a PR claims no behavior change, I stop reading the summary and look at the surface instead:

Anything public that got renamed? Fields, routes, flags, env vars, exported functions. Search the diff for removed lines in serializers, schemas, route files and type definitions.
Did any default change? null vs empty, false vs missing, a timeout, a page size. Defaults are where "cosmetic" changes hide.
Did an error shape or status code move? Callers branch on these. A 404 turning into a 400 is a behavior change, full stop.
Is there one test that would fail if the old behavior came back wrong? If the tests were edited in the same PR to match the new output, that doesn't count.

If any of those turn up something, I don't argue about whether it "counts". I reject the claim, not the PR: "This changes X for callers. Either keep the old shape or call it out as a breaking change." Usually the fix is small.

Why this one matters more with agents

A human who renames a public field mostly knows they did it. An agent will do it as a side effect of tidying, in the same PR as the thing you actually asked for, and then describe the whole bundle as a refactor. So the claim in the description is exactly the part to verify, not the part to trust.

I keep this and seven other "stop and look" rules on a free one-pager if you want to pin it next to your review tab: https://chopragunji.gumroad.com/l/zpnmdn

And if there's a specific AI PR you're nervous about, I'm doing a few line-by-line reviews at $49 right now: https://chopragunji.gumroad.com/l/byoyi/FOUNDING

What's the sneakiest "no behavior change" you've caught?

I reviewed 3 AI-written PRs from public repos. Here's what I'd have blocked.

Riven Desk — Mon, 05 Oct 2026 07:34:44 +0000

I sell a human second pass on one AI-written PR (Riven Desk). Before pitching that, I wanted to do the work in public: pick three recent agent PRs from real repos, read the diffs (not just the summaries), and apply the same STOP checklist I give away for free.

Method, briefly:

Searched public GitHub for PRs authored by copilot-swe-agent and bodies/trailers mentioning Claude Code (Co-Authored-By: Claude / claude.com/claude-code).
Preferred medium diffs (under ~400 changed lines) in repos people might recognize.
Reviewed each against the STOP conditions one-pager — when to refuse the merge even if CI is green.

These are outsider reviews. I don't maintain these projects. Maintainers may have context I don't. I'm grading the diff as written, not the people.

PR 1 — microsoft/testfx#11740 (Copilot)

PR: Deduplicate sample binlog argument construction

Author signal: GitHub Copilot coding agent (copilot-swe-agent)

Size: ~27 changed lines across eng/build-samples.ps1, eng/samples-tools.ps1, eng/test-samples.ps1

State when reviewed: merged

What it does

Extracts repeated “build a -bl: / /bl: path under $BinaryLogDirectory” into Get-SampleBinlogArgument in eng/samples-tools.ps1, then calls it from the sample build/test scripts. The call sites already dot-source samples-tools.ps1, so the helper is in scope.

STOP checklist

STOP	Fires?	Notes
1 Secrets	No	No credentials or env files
2 Blast radius / no boundary	No	One clear intent: dedupe binlog arg construction
3 Mixed concerns	No	Script-only, no lockfile/infra hitchhikers
4 “No behavior change” while surface moved	Borderline	Behavior should match; see nit below
5 Rollback story	Fine	One revert undoes it
6 Security-sensitive paths	No	Build helper only
7 Prompt/tool surface	No
8 CI / tests	N/A from diff alone	Trivial pure helper; no new failing assertion added

Concrete findings

Default prefix is -bl: (Get-SampleBinlogArgument). Call sites that need MSBuild-style /bl: pass -ArgumentPrefix "/bl:" explicitly. That looks correct in the diff — just something a human should eyeball once so a future caller doesn’t assume the wrong flag.
Log name vs extension: the helper always appends .binlog to $LogName. Call sites that previously built "$name.binlog" now pass $name (or "$name.restore"). Consistent in this PR; don’t re-add .binlog in the caller later.
No unit test for the helper. For this size I’d accept it — the risk is a wrong path string, and the scripts are the real consumers.

Merge stance

Would merge. Nothing on the STOP list fires hard. This is the kind of agent PR that should land with a short human glance, not a drama review.

What I’d fix before merge (optional): one sentence in the PR body: “Default prefix -bl:; MSBuild restore/build paths pass /bl:.” Saves the next reviewer two minutes.

PR 2 — trimble-oss/modus-wc-2.0#1569 (Copilot)

PR: Update vulnerable dependency pins

Author signal: GitHub Copilot coding agent

Size: package.json + package-lock.json (~280 line churn, mostly lockfile)

State when reviewed: open

What it does

Updates npm overrides / pins for brace-expansion@1|2|5 and fast-uri, and bumps @stencil/react-output-target from 1.2.0 → 1.6.2 (lockfile follows, including @lit/react, ts-morph, nested minimatch, etc.).

STOP checklist

STOP	Fires?	Notes
1 Secrets	No
2 Blast radius / no boundary	Yes — ask/split	Title says vulnerable pins; diff also jumps a codegen package several minors
3 Mixed concerns	Yes — split	Security pin refresh + Stencil React output-target upgrade in one PR
4 Surface moved	Ask	React wrapper generation can change across 1.2→1.6 with no app source in the diff
5 Rollback	Partial	Revert works; “why these versions” isn’t written
6 Security paths	Skimmed	Dependency pins are security-adjacent — need the CVE/advisory names in the PR
7 Prompt/tool	No
8 Tests that catch the regression	Ask	Lockfile-only PRs often go green without proving consumers still build

Concrete findings

@stencil/react-output-target 1.2.0 → 1.6.2 is not a pin tweak. Peer dependency text in the lockfile widens toward Stencil 5. That can change generated React bindings. I’d want either (a) that bump in its own PR with a smoke build of the React output, or (b) a short note linking the release notes and what was verified.
brace-expansion / fast-uri overrides look like the actual “vulnerable pins” work. Fine — but the PR body should name the advisories (or Dependabot/Snyk findings) so a reviewer isn’t trusting the title alone. I didn’t see CVE IDs in the title; treat that as missing evidence, not proof they’re wrong.
Lockfile-only confidence: no source/test changes. Merge only if CI already builds the React/Angular output targets you ship, or after a manual npm run of those packages.

Merge stance

Would not merge as written — request changes / split.

Smallest clear path:

Split: PR A = brace-expansion + fast-uri pins only. PR B = @stencil/react-output-target upgrade with a one-line verification note.
Or keep one PR, but add: advisory links for the pins, changelog pointer for 1.2→1.6, and “I built X output target locally / CI job Y is green.”

This is a classic agent shape: honest security cleanup, then a larger upgrade rides along because the agent “fixed versions” broadly.

PR 3 — Asymptote-Labs/agent-beacon#723 (Claude Code)

PR: feat(lenses): built-in MCP Calls lens

Author signal: human opener + Co-Authored-By: Claude / claude.com/claude-code markers

Size: ~387 changed lines — new mcp.lens.html, Playwright e2e, fixture lines, docs

State when reviewed: open

What it does

Adds a built-in dashboard “MCP Calls” lens: group MCP tool calls by server/tool, show args/results, mark failures, document it in docs/concepts/lenses.mdx, and cover it with Playwright (builtin-mcp.spec.ts) including an XSS-shaped payload in fixture args.

STOP checklist

STOP	Fires?	Notes
1 Secrets	No
2 Blast radius	No	Matches “add MCP lens” intent
3 Mixed concerns	No	Feature + tests + docs for the same lens
4 Surface claim	No	Docs say seven built-in lenses now
5 Rollback	Fine	Revert removes the lens file + docs line
6 Security-sensitive	Reviewed	Renders untrusted trace payloads in the browser
7 Prompt/tool / rendered AI output	Watched closely — clears	Uses `textContent` / `el()` helpers; e2e asserts markup in args does not execute
8 Tests	Strong	Playwright checks grouping, failure flag, XSS non-execution, empty state

Concrete findings

XSS handling looks intentional and tested. Comment in the lens: arguments/results are untrusted. Fixture plants <img src=x onerror=...>; the test opens Arguments and expects window.pwned to stay undefined. That’s the right bar for a lens that prints agent/MCP payloads.
Field-shape ask (not a block if CI is green): the Playwright fixture puts arguments / result under gen_ai.tool.call, while the lens JS reads event.tool.arguments / event.tool.result and event.tool_call_id. If window.beacon.getTrace() normalizes those fields before the lens runs, fine — and the e2e implies it does. If someone later feeds raw JSONL into the lens, args/results would silently go missing. Worth one maintainer sentence: “getTrace maps gen_ai.call → tool.*.”
Classification heuristics (mcp__server__tool, MCP:tool, event.type === "mcp") are documented enough in empty-state copy. Edge cases (weird tool names) are acceptable for v1.

Merge stance

Would merge after confirming the e2e job that runs builtin-mcp.spec.ts is green on the PR. I would not block on style. I would leave the field-mapping note as a non-blocking comment.

This is closer to what you want from an agent: feature-sized, security-aware rendering, and a test that would fail if someone “helpfully” switched to innerHTML.

What I’d actually have blocked

Across these three:

PR	Block?	Why
testfx#11740	No	Small, matched intent, easy revert
modus-wc#1569	Yes (as packaged)	Security pins mixed with a multi-minor Stencil React target bump; missing advisory + verification notes
agent-beacon#723	No (pending green e2e)	Untrusted output handled; tests watch the scary path

The interesting failure mode wasn’t “AI can’t code.” It was scope creep inside a true-sounding title (vuln pins) and whether security-sensitive UI proves it doesn’t execute untrusted text.

CI green is not a STOP clear. Title confidence isn’t either.

Takeaways I’m keeping

Read the file list before the summary. If the title says “pins” and a codegen package jumped 1.2→1.6, stop and split.
For anything that renders agent/tool output, demand a textContent-style path and a regression test. agent-beacon did this; many agent UIs don’t.
Tiny refactors from agents are often fine. Don’t invent risk on testfx-shaped PRs just because an agent wrote them.
Name a human owner and a rollback line on anything non-trivial. Agents don’t get paged on Monday.

I used the free STOP one-pager while writing this: STOP conditions before you merge an AI agent PR.

If you want a second set of eyes on one hard agent PR

I’m running a founding price on a single human review of one AI-written PR: $49 for the first 5 (normally $99) → Agent PR Audit — founding offer.

You get concrete findings with file names, a merge stance, and what to fix — same shape as the sections above, on your PR. No fake “bugs down X%” claims. The point is fewer merges you can’t explain.

— Gunjit / Riven Desk

Free one-pager: STOP conditions for AI agent PRs

Riven Desk — Fri, 11 Sep 2026 09:05:20 +0000

AI-assisted pull requests can be smaller and safer—but only if “looks plausible” is not treated as a review.

STOP is a compact pause point for AI-authored PRs. It is not anti-AI; it is a reminder to stop merging when evidence is missing.

The STOP check

Pause when any of these conditions is true:

Scope drift: the diff changes files, behavior, or dependencies outside the stated task.
Weak tests: the summary says “all good,” but relevant tests were not run or do not exercise the changed path.
Opaque risk: new permissions, network calls, migrations, generated code, or security-sensitive logic appear without a clear explanation.
Possible data exposure: logs, fixtures, prompts, environment values, or copied snippets need a deliberate secrets check.

A practical review loop:

Write down the intended boundary before reading the agent’s summary.
Inspect the diff, not just the explanation. Ask what changed and what did not.
Require evidence for behavior claims: focused tests, CI results, and a rollback path.
Split the PR or send it back when the agent expanded the task instead of guessing at intent.

This pairs well with “commit before agent” and “plan before multi-file.” Small checkpoints make it easier to see the real change and reject a confident but unsupported summary.

The goal is not to slow every PR. It is to spend a few minutes up front so an AI shortcut does not become an on-call incident, surprise dependency, or hard-to-reproduce security problem.

Free one-pager

Printable checklist: https://chopragunji.gumroad.com/l/zpnmdn

For the longer self-serve workflow with Cursor rules and review prompts, the Riven Desk AI Agent Code Review Kit is here ($29): https://chopragunji.gumroad.com/l/nxoboi

Use the free page first; the kit is simply for teams that want the surrounding workflow.

What to verify after an AI agent says tests pass

Riven Desk — Thu, 10 Sep 2026 01:31:40 +0000

Green CI from an agent is not a merge signal. It is a claim: "I ran something and it exited zero." Your job is to check whether that claim covers the bug, the intent, and the failure modes you care about.

I treat "tests pass" as the start of a short verification sequence — not the end of review.

1. Inspect the diff, not the summary

Open the file list first. Ignore the agent's narrative until you can answer:

Which files actually changed?
Do they match the human intent in one sentence?
Any lockfiles, renames, config, or test fixtures you did not ask for?

Agents often pad the suite while touching unrelated helpers. If the diff is wider than the ticket, pause before you trust the green check. A passing suite on the wrong surface is still the wrong merge.

2. Read the assertions (adversarially)

Open the new or edited tests and ask: would this fail if the original bug came back?

Watch for:

Asserts that only check "something returned" or status 200
Snapshots that absorb any behavior change
Happy-path-only coverage with no edge or negative case
Tests that fail solely if the function is deleted

If the assertion would still pass with the regression restored, the suite is theater. Request a tighter assert before you approve. Prefer one sharp negative case over five soft positives.

3. Exercise the failure paths

Green tests often skip the paths that hurt in production:

Invalid input, missing auth, permission denied
Empty collections, timeouts, partial writes
Feature-flag off, second call, idempotency

Pick the failure mode closest to the ticket and ask whether any test forces it. If not, either add that case or manually exercise it before merge. Agents optimize for "looks covered." You optimize for "breaks when broken."

4. Reproduce the command locally

Do not trust the agent's pasted output alone. Run the same command on your machine (or the same CI job) with the PR branch checked out:

# example — use whatever your repo actually runs
npm test -- path/to/relevant.spec.ts

Check:

Same command the agent claimed to run?
Same working directory / env assumptions?
Flakes, skips, or "passed with warnings" you would not accept?

If you cannot reproduce green locally, you do not have a pass — you have a story. Fix the story before merge.

Sequence, not vibes

Order matters: diff → assertions → failure paths → local reproduce. Skip ahead and you rubber-stamp confidence. Stop early when the file list or asserts are weak do not sink twenty minutes into a suite that never could catch the bug.

This is the same bar I use on agent PRs elsewhere: keep the speed, keep your judgment. Green is necessary. It is not sufficient.

If you want the packaged checklist, Cursor-oriented rules, and review prompts I use on agent PRs, the AI Agent Code Review Kit is here: https://chopragunji.gumroad.com/l/nxoboi

— Riven Desk

What do you check first after an agent claims tests pass — file list, asserts, or a local re-run? Drop your sequence in the comments.

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.