Phloemphloem

Review governance

How to review AI-generated pull requests

Agent output arrives faster than human review capacity, so the review itself becomes the control. This checklist assumes the change reaches you as a normal pull request on a ticket-isolated branch, with evidence attached to the commit you are reading.

  1. 01

    Confirm you are reading the exact head

    Approvals age badly. Record the head SHA when you start reviewing and refuse to merge if it moved. Every piece of evidence you read must name that same commit — a green pipeline from two pushes ago proves nothing about what you are about to ship.

  2. 02

    Check the branch is ticket-isolated

    One ticket, one branch, one intent. If a branch touches unrelated modules, split it before review. Agents are cheap enough to redo work; a mixed diff is expensive for every future reader and blocks a clean revert.

  3. 03

    Read the intent before the diff

    Compare the acceptance criteria with what the change actually does. The most common agent failure is not broken code — it is code that solves an adjacent problem convincingly.

  4. 04

    Verify tests test the change

    Look for assertions on the new behaviour, not just a passing suite. Tests written by the same agent that wrote the code can encode the same misunderstanding, so check at least one test against the requirement by hand.

  5. 05

    Audit dependencies and secrets separately

    New packages, new network calls, new environment variables and new permissions deserve their own pass. Run dependency and secret scanning on the reviewed commit and treat any addition the ticket did not ask for as a defect.

  6. 06

    Inspect data access and migrations

    Schema changes, row-level policies and privileged queries carry the blast radius. Ask what the change lets an unauthenticated caller do that it could not do before, and confirm the migration is reversible.

  7. 07

    Exercise the preview, not the description

    Open the deployed preview for the reviewed commit and walk the user path the ticket describes. Summaries written by the agent are a hypothesis about its own work.

  8. 08

    Keep merge and spend with a human

    Agents may plan, implement and argue for a change. Approval, budget release and the merge button stay with a person who can be asked why in three months.

Failure patterns to reject outright

Approving on the summary
Read the diff and evidence; the summary is authored by the party under review.
Stale green checks
Evidence must name the head SHA. Reject anything older.
Silent scope growth
Refactors bundled into a feature ticket hide behaviour changes.
Unbounded retries
Set a spend cap per ticket so a failing loop stops instead of billing.

Next: write the policy down

A checklist works once the rules are agreed. The companion guide covers what an AI code contribution policy should state — disclosure, ownership, licensing and enforcement.