A Fixed Review Order for Ten Finished Agent Branches

The first gate is the cheapest and should be fully automated: build, tests, linters, type checks, secret scanning. If a branch fails, it goes back to the agent and no human opens the diff.

This is the largest saving in the order. Ten branches that each fail a test suite cost zero reviewer minutes instead of ten partial reads. The reviewer's first action is to sort the branch list by check status and discard the red ones.

Two conditions make the gate trustworthy. Checks must run on the branch as submitted, in the environment the merge target uses, not on the agent's local assumption. And the agent must be able to read the failure output, or it will resubmit the same broken branch. Espressif's guidance points the same way: build and test the affected project before committing the Espressif agent Git workflow.

You can script the sort. Commands differ by forge, but the logic is universal: check out each branch, run checks, print one line with the outcome.

#!/usr/bin/env bash
# Gate 1 triage: one line per agent branch, checks first
set -uo pipefail
BASE="${BASE:-origin/main}"
for branch in $(git for-each-ref --format='%(refname:short)' refs/heads/agent/); do
  git switch --quiet "$branch" || { echo "SKIP $branch (checkout failed)"; continue; }
  if ./ci/check.sh >/dev/null 2>&1; then
    status="PASS"
  else
    status="FAIL"
  fi
  lines=$(git diff --shortstat "$BASE"...HEAD | awk '{print $4+$6}')
  echo "$status ${lines:-0} $branch"
done

Sort the output and ignore every FAIL line for the rest of the session. The list you carry forward is shorter, and nothing on it has a known broken build.

The second gate is a number. Pick a maximum changed-line count for a branch that gets a human read and send anything above it back to be split. The 400-line ceiling is a defensible starting point, because the 200 to 400 band is where the size study found the best reported mix of detection, review time and engagement the PR size data study. The same source suggests tighter limits by change type: under 100 lines for bug fixes, 200 to 400 for one cohesive feature, 300 to 500 for one logical refactor, under 50 for configuration.

Measure from the merge base to the branch head, count additions and deletions, and exclude generated or vendored files so agents cannot pad a diff with formatting. Be explicit about what does not count.

The Karpathy guidelines skill states the principle behind the ceiling: minimum code that solves the problem, nothing speculative, and if you write 200 lines and it could be 50, rewrite it the skill source. A branch that blows past the ceiling is usually an agent adding flexibility nobody asked for. Returning it with the line count and the ceiling is a complete, unambiguous instruction.

Allow one documented exception: a mechanical rename or format change across many files, where the diff is a single repeated transformation. Review the pattern once rather than line by line. Make the agent state the pattern in one sentence; if it cannot, the gate stands. Skills are portable Markdown instructions rather than provider-specific code, so the same guideline text can be installed in any agent that reads SKILL.md the skill listing.

The third gate checks where the branch went, not how far. A 120-line diff that edits a migration, a lockfile and a CI workflow is riskier than a 400-line diff confined to one feature folder. Path review is fast because it is a set comparison, not a reading task.

Espressif's checklist is the same test in other words: every changed file belongs to the task, generated files are intentional, and no credentials or build artifacts were added the Espressif agent Git workflow. The Karpathy guidelines call it surgical changes: touch only what you must, do not improve adjacent code, do not delete pre-existing dead code unless asked the skill source. A related project documents guarding agent edits against scope creep, in the spirit of the same rule a scope-guard plugin.

Generate the path list mechanically, not by eye:

BASE=origin/main
git diff --name-only "$BASE"...HEAD \
  | sed 's#/[^/]*$##' | sort -u

Read the folder list, not the diff. If a folder appears that the task description did not name, the branch stops here. A bare-repository layout makes this cheap, because every branch already sits in its own worktree and you can run the command without disturbing your own checkout a practical bare-clone worktree setup.

Only branches that pass three gates reach a human reading logic. The read covers four things: does the change do what the task asked, is control flow correct at the edges, do the tests exercise the behavior, and will the names or comments mislead the next reader.

Two rules keep this gate from expanding. Read the diff, not the whole file, unless a changed line calls something the diff does not show. And stop at the first substantive concern, sending the branch back with the concern named. One pass with a clear rejection beats a full reading plus ten minor notes.

Batching is what keeps total time flat as branch count grows. Group survivors by the folders they touch and review one group per sitting, so you load each file's context once instead of once per branch. Six branches touching three shared modules become three batches, not six sessions. Espressif's practice of small, coherent commits supports this: commit after each verified state rather than at the end of a large task, which keeps each reviewable unit small the Espressif agent Git workflow.

The evidence supports batching for a second reason: attention decays inside a session. The size study found fewer meaningful comments on larger changes despite longer review time, and attributes it to cognitive overload and approval bias the PR size data study. A batch of small diffs in one area keeps each change inside the range where scrutiny stays high.

Know the limit of automation here. An empirical study of pull request acceptance found that static-analysis quality flaws did not influence whether a maintainer accepted or rejected a change, with only a few rules considered at all the study on code quality and pull request acceptance. Automated findings are a filter in front of the logic read, not a substitute for it. That is exactly the role Gates 1 to 3 play: they decide what gets read, not whether reading happens. A research overview maps the wider literature on how change size, ordering, tests and explanations affect reviewers the code review research overview, which is a better guide than intuition if you want to tune the limits beyond the starting values.

Ten agents finish, each with a task description, a diff and a check status. Apply the gates in order and count reviewer minutes, using illustrative per-branch costs: check triage 2 minutes, size check 1 minute, path check 2 minutes, logic read 25 minutes for an accepted diff.

Six branches fail a gate before any logic read, at 15 reviewer minutes. Four reach Gate 4, batched by path into feature A (a3, a10), feature B (a4, a6) and docs (a9), at 101 minutes. The session costs about 116 minutes, and the largest block is the batched logic read.

Compare that with reading all ten diffs without gates. Using the size study's figures as an illustration, 4.2 hours for an oversized change and 1.5 hours for a mid-sized one turn the same ten branches into a queue measured in days the PR size data study. The gates do not make reading faster. They make most branches cheap to reject, so reading time goes only where a read can change the outcome. Review time now scales with the number of branches that fail their first gate, which you can reduce by improving agent instructions, not with the number of agents you run.

A fixed order stays flat only if you can see which gate does the work. Log three numbers per branch: the gate that stopped it, the changed-line count, and the number of touched folders. After a few batches you will know whether the ceiling is right and whether path failures cluster on one folder.

Agent session capture helps when a branch fails a gate for a reason the diff does not explain. A command-line tool that hooks into your Git workflow to record agent sessions makes it possible to reconstruct what an agent did the Entire CLI. If you build your own harness, the branch prefixes and checkpoints in Espressif's workflow are a reasonable model the Espressif agent Git workflow, and the bare-clone layout keeps one folder per branch a practical bare-clone worktree setup.

Two metrics belong on a dashboard: median reviewer minutes per passed branch, and the share of branches stopped at Gate 1. If the first climbs, your ceiling or batching groups are wrong. If the second falls, agents are shipping broken builds, and the fix belongs in their instructions or their test access, not in review.

For teams that want the triage commentary generated by a model, one endpoint for several model kinds keeps the script simple: Quanta Inference serves text, image, video, audio and embedding models through one OpenAI-compatible API key (https://quantaintelligence.ai/inference). The per-branch cost of a summarizer is the point of the gate, so route it through something predictable.