Part 4 · Authoring for Review

Agent-Assisted Code Review · ~7 min

PR Slicing & Descriptions

The cheapest review win happens before review starts — author the PR small, say why it exists, and flag the code that will get deleted.

Why this, for you: every earlier lesson made the reviewer sharper. This one moves upstream to the author — because a 1,200-line agent branch with a one-line description is a review you have already lost. Three controls you set at PR-creation time decide how much of the reviewer's attention you waste.

An agent can ship a feature in one branch and one giant diff. That is convenient for the agent and brutal for the reviewer. Reviewable PRs are authored, not hoped for — and the agent that wrote the code holds exactly the context needed to make them reviewable.

1 Slice to the attention envelope

Defect detection drops sharply once a single review crosses 200–400 lines or 60–90 minutes of attention — the SmartBear/Cisco study of about 2,500 reviews across 3.2M lines of code. A 2,000-line branch sliced into four 500-line PRs lands back inside that envelope.

The agent's edge as a slicer is intent context: it holds the session record of which edits belonged to which sub-task and where the dependency edges are. Diff-only tools cluster hunks; the authoring agent slices by what the change was for.

Slice along axes the diff alone does not encode — feature vs. refactor, backend vs. frontend, formatting vs. logic, tests vs. production code, dependency bumps vs. behavior changes — plus the sixth axis only the session knows: which task each edit belonged to. Dependent slices stack (each targets the one before it); independent slices land as parallel PRs against the same base. Skip the partial order and reviewers merge dependent slices out of sequence, breaking intermediate states.

Slicing can make review worse, not better

A cross-cutting refactor split by directory becomes four PRs that each touch one layer — reviewing one means opening the others, so everyone holds more context than the monolith forced. Two red flags: no PR is independently mergeable, and reviewers keep asking for the original diff. Don't slice cross-cutting refactors, atomic-revert paths (migrations, feature flags), security-sensitive fixes, or diffs already under ~200 LOC. Keep the stack at 3–4 PRs; beyond that, feedback on an early slice forces a rebase cascade through every downstream one. And keep the author's approval gate — the proposed split is a hypothesis, not a result.

2 Describe the why — it moves merge rates

PR description structure is a configurable agent parameter, not a cosmetic default. A study of 5 AI coding agents across the AIDev dataset found description structure varied systematically by agent and correlated with reviewer engagement and merge rates — partly independent of code quality (arXiv:2602.17084).

AgentMerge rateDescription signature
OpenAI Codex82.6%Frequent headers and lists; high clarity
Cursor65.2%Politeness markers; moderate structure
Claude Code59.0%High text volume; emoji; convention-strict
Devin53.8%Frequent commit splits
GitHub Copilot43.0%Most reviewer discussion generated
Copilot generated the most reviewer discussion and had the lowest merge rate. High engagement volume is not the goal — review churn is the failure mode. Structured headers cut the clarification overhead that forces reviewers to reconstruct intent from prose.

The mechanism is direct: neither Claude Code nor Copilot enforces description structure by default, so configure it. Put a template in CLAUDE.md, AGENTS.md, or custom agent instructions, specifying the sections reviewers actually need.

## Pull Requests (in CLAUDE.md / AGENTS.md) Every PR description must include: - **Summary**: one sentence — what changes and why - **Changes**: bullet list of file-level changes - **Testing**: how the change was verified - **Breaking Changes**: state "None" explicitly if none

Make it opt-in where it only adds friction: solo repos, trivial or mechanical PRs (dependency bumps, formatting), and teams with strong ambient context. And remember the binding constraint — description style is a secondary lever; merge value tracks the code, so templating weak code just hides the root problem.

3 Predict where review will choke

AI PRs ship functions reviewers routinely delete — dead code, over-engineered helpers, spec-mismatched implementations. That deletion is statistically predictable from structure alone: arXiv:2602.17091 reaches AUC 87.1% flagging likely-to-be-deleted functions using only static features — no semantic understanding of the spec required.

The strongest predictors are method name length, lines of code, Halstead volume, and call count — all proxies for "more was generated than the task required." A function with a long descriptive name and high Halstead volume encodes more conceptual surface area than a focused one, and that excess surface is what reviewers remove.

Run the structural pre-flag before a human sees the PR. Return flagged functions to the agent for regeneration — eliminating the review cycle for code that was never going to survive it.

This loops straight back into how you prompt the author: require generated functions be reachable from named entry points, prohibit abstraction beyond the current task, and declare external dependencies explicitly. Fewer generated functions that survive review beats more functions with a higher deletion rate.

Don't trust the flag blindly

A 12.9% error rate leaves roughly 1-in-8 deletable functions unflagged — reviewers who lean on the report skip unflagged code too fast. And a utility called once looks like over-engineering by metrics but may be essential for testability; setup hooks and exported API surface read as dead code to a single-module call graph. Calibrate false-positive rates locally and keep a human fallback before routing regenerations to the agent.

↪ Your win: a PR authored to be reviewed

Retrieval practice — recall, don't peek

Question 1The authoring agent's advantage as a PR slicer over a diff-only tool is that it holds…

Question 2Defect detection drops sharply once a single review exceeds roughly…

Question 3Copilot generated the most reviewer discussion yet the lowest merge rate, which means the outcome to optimize is…

Question 4The structural pre-flag for likely-to-be-deleted functions (AUC 87.1%) keys on signals like…

Question 5 · spaced recall from an earlier lessonIn human-AI review synergy, work is split by comparative advantage so that…

Ask me anything. Want a slice plan for a real agent branch, or a PR-description template tuned to your reviewers? Next in Part 4: The Feedback-to-Rule Loop — how to turn the same review comment you keep writing into a learned rule so it's never written twice.
✎ Feedback