Blast Radius First: A Review Worksheet for Agent-Generated PRs

Most agent PR reviews start with the wrong question. "Is this code good?" invites taste arguments you cannot settle in ten minutes. The question that actually gates a merge is narrower: what does this diff make expensive to undo, and what does it make invisible when it is wrong?

That question is answerable before you read a single line of the implementation. Answer it first, and the review collapses from "read everything" into three short lists: what to trust, what to test, what to revert.

The workflow below is a triage script, a merge-gate table, and a six-line worksheet. The scripts are illustrative and have not been executed for this article — treat them as a starting point you run and correct against your own repository.

Why line count is a bad proxy for risk

A 400-line refactor inside one well-tested module is often cheaper to review than a 12-line change to a database migration. Size measures reading cost. Risk measures reversal cost.

Agent-generated PRs make this gap worse for a structural reason: an agent optimizes for a diff that looks complete. It will happily add a config default, rename a module, or rewrite a lockfile because those edits make the change internally consistent. Each of those is a small number of lines and a large number of downstream assumptions.

So classify by path and operation first, then read.

Artifact 1: a deterministic triage pass

Two facts about a diff are cheap and reliable: which files changed, and how (added, modified, deleted, renamed). Derive the review class from those, not from the model's self-description.

#!/usr/bin/env bash
# triage.sh — illustrative, unexecuted. Usage: ./triage.sh <base-ref>
set -euo pipefail
base="${1:?usage: triage.sh <base-ref>}"

classify_path() {
  case "$1" in
    */migrations/*|*.sql|*/schema.prisma|*/alembic/*) echo "REVERT-FIRST" ;;
    *.lock|*lock.json|*lock.yaml|requirements*.txt|go.sum) echo "TEST-FIRST" ;;
    *.env*|*secret*|*config*.y*ml|*/Dockerfile|*.tf|*/helm/*) echo "HUMAN-ONLY" ;;
    *test_*|*_test.*|*_spec.*|*/tests/*) echo "TRUST-AFTER-RED" ;;
    *) echo "DEFAULT" ;;
  esac
}

git diff --name-status "$base"...HEAD | while read -r status path; do
  case "$status" in
    D)  class="REVERT-FIRST" ;;   # a deletion needs a restore path before merge
    R*) class="HUMAN-ONLY"  ;;    # a rename breaks imports far from the diff
    *)  class="$(classify_path "$path")" ;;
  esac
  printf '%s\t%s\t%s\n' "$class" "$status" "$path"
done | sort

Run it against a diff you already understand and check that the output matches your intuition. That is the whole test: a golden pair of commits, an expected table, and a diff of the two. If your repository keeps migrations outside */migrations/*, your first real review will show it as DEFAULT — fix the glob, not the output.

The two-transcript rule

For any class that says TEST-FIRST or TRUST-AFTER-RED, require two command transcripts, not one:

1. The relevant test failing on the base ref.
2. The same test passing on the head ref.

One transcript proves a test passes. Two transcripts prove the test is connected to the change. Without the first, an agent can satisfy your gate by adding a test that asserts nothing.

Artifact 2: the merge-gate table

Two columns carry the weight. Who signs is a person, not a process, because "the CI was green" is not an accountable answer for an irreversible change. Evidence attached is an artifact, because a sentence in the PR body is a claim, not a result.

Artifact 3: the six-line worksheet

Paste this into the review thread and fill it in before approving:

- [ ] Highest class in this diff: ______
- [ ] Restore path (if REVERT-FIRST): ______
- [ ] Tests that fail without this diff: ______
- [ ] Files the PR body mentions but the diff does not touch: ______
- [ ] Claims I could not map to a file: ______
- [ ] Reviewer who read the HUMAN-ONLY hunks: ______

Line four catches a specific agent habit worth naming: a summary that describes work in files the diff never touches. It is not necessarily dishonest — it is often a summary of intention rather than of the patch. Either way, the mismatch is a signal to read the diff yourself rather than the description.

Where cheap model access fits — and where it must not

A free model tier is genuinely useful for the part of this workflow that is language work: converting a verbose PR body into falsifiable bullets that the worksheet can consume.

Turn this PR description into falsifiable claims. For each claim, output:
  claim | command that would disprove it | file it touches
Do not propose fixes. Do not summarize. Mark any claim you cannot map
to a file in the diff as UNMAPPED.

The output is a hypothesis list, not a verdict. Keep the model out of the classification step entirely — the REVERT-FIRST and HUMAN-ONLY gates should be owned by glob rules a human can read and argue with, because a model that misreads a path fails silently and in the permissive direction.

MonkeyCode is relevant here in two places, and only two. Its free model access is enough for the claim-extraction pass above, where a wrong bullet costs you a re-read rather than a bad merge. Its free server option is a reasonable place to rehearse a rollback for a REVERT-FIRST change, since that rehearsal wants a disposable environment and nothing you care about. Both availabilities are operator-stated; the project also advertises a free token allowance, reported as 10M tokens at the time of writing. I have not independently verified the current allowance, the model list, or the server specification, and all of it is time-sensitive — check the project's own terms before planning around it.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Limitations

• Glob rules are a guess about your repository. They will misclassify monorepos with several migration conventions. Fix the rules per repo; do not add a model to paper over them.
• TRUST-AFTER-RED assumes a test harness exists. In a repo without runnable tests, that class degrades to HUMAN-ONLY. Pretending otherwise is how a gate becomes a formality.
• The table gates merges, not deploys. Feature-flag and runtime-config risk live outside a diff-based review and need their own check.
• Two transcripts can still be gamed by a test that asserts something trivially true. Read the test diff for TRUST-AFTER-RED changes; the transcripts only prove connectivity.

Who should not use this

If your change control requires a documented, auditable approval chain per change, a shell script and a markdown checklist are not that system — keep your existing gate and borrow only the classification idea. If your repo has no migrations, no lockfiles, and no config files, the table mostly collapses into DEFAULT and you are paying process cost for nothing.

How to check this works for you

Pick three merged PRs, two of which caused a follow-up fix. Run the triage script against each, fill in the worksheet as if you were reviewing, and compare the highest class against what actually went wrong. If the script flagged nothing on the PRs that hurt, your globs are wrong, not the method. Start there.

If you want a low-stakes place to try the claim-extraction step, run it on a diff you have already approved — seeing whether the model produces an UNMAPPED line where you know one belongs is a more useful first test than any benchmark.