How to Review Agent-Written PRs Without Lowering the Bar

Agent-written pull requests are everywhere because they compress the most flattering part of engineering: producing a lot of code quickly. What they do not compress is accountability. Someone still has to decide whether the diff is correct, safe, maintainable, and worth shipping. Grim news for management decks, but that someone is still us.

If your review process treats agent output like ordinary handwritten code, you will miss a predictable class of problems: broad diffs, confident nonsense, shallow tests, and architecture that looks clean right up until it meets production traffic and other humans.

Review the task framing before the code

Agent output quality is tightly coupled to the prompt and constraints. Before you review implementation details, check what the agent was actually asked to do.

• Was the task narrow enough to review in one sitting?
• Did it define acceptance criteria and non-goals?
• Did it tell the agent what not to touch?

Bad prompt, bad diff. The code may still compile, but so do a lot of regrettable decisions.

Diff size is now a policy problem

Agents do not feel review fatigue, so they happily generate sprawling changes. Humans do feel it. That means teams need an explicit rule: if the change cannot be reviewed clearly, it should be split before anyone argues about style.

• Separate refactors from behavior changes.
• Separate generated cleanup from business logic.
• Separate tests from speculative “while I was here” edits.

Smaller diffs are not aesthetic. They are how you stop automation from turning review into archaeology.

Interrogate boundaries first

Agent-written code often looks locally reasonable while being globally reckless. Review the boundaries before the implementation details.

• What happens on loading, error, empty, and retry states?
• Did it change validation, serialization, or API assumptions?
• Are logging, analytics, and monitoring still useful when things fail?
• Did it quietly increase coupling between modules that used to be separate?

The sharpest bugs now hide in the seams because the center of the code looks suspiciously polished.

Ask for evidence, not confidence

Agents are excellent at sounding done. That is not the same thing as being done. Reviews should demand proof.

• Which tests were added for the risky paths?
• What manual scenarios were exercised?
• Is there a screenshot or recording for UI changes?
• What is the rollback path if the behavior is wrong in production?

“It should work” is not evidence. It is a bedtime story for tired teams.

Require a readable change summary

A strong agent workflow includes a short explanation of what changed, why it changed, and what still feels risky. If the PR description is vague, the reviewer ends up reconstructing intent from code, which is the software version of excavating a ruin with a toothbrush.

1. Require a clear summary.
2. Require a list of touched systems or files.
3. Require known risks, assumptions, and follow-up work.

The point is not bureaucracy. The point is reducing interpretive fiction during review.

Keep the human accountable

The cleanest team rule is also the least glamorous: whoever delegates the task owns the result. Not the model, not the tooling vendor, not the mystical cloud of innovation hovering over the sprint board.

Trade-off: agent-written PRs can absolutely speed up routine implementation and documentation work, but they also make it easier to generate polished mistakes at scale. The upside is leverage. The downside is that your review standards have to get stricter, not softer, or the speed turns into cleanup debt with excellent branding.