Make AI-Generated Code Safe Enough to Ship: A Review Gate for Agent PRs

Your review queue fills with pull requests from agents, and each patch looks reasonable on its own. One agent can open a dozen pull requests in an hour. The old habit of skimming a patch and trusting the author no longer works when the author is a process. Treat every agent PR as untrusted input, then build a gate that makes the safe path the easy path.

Agent PRs need a trust surface

The review surface has changed: AI-generated code carries 1.57 times as many security vulnerabilities as human-written code. The number does not make every patch dangerous. It makes the review problem a throughput problem: plausible changes arrive faster than a human can inspect them.

The gate is the redesign

Put the gate where the PR is created, not in a wiki. It should answer the designer's question: what does the reviewer need to see before the next step is safe? For agent code, the reviewer needs provenance, scope, evidence, compatibility, and exceptions. The gate should be visible to designers, not only engineers, because the merge decision is a product decision. The checklist below is the redesign: a small set of checks that turns “looks plausible” into “safe to merge.”

• Provenance: The PR must name the agent, task, and commit lineage. If it cannot say where the change came from, it does not enter review.
• Diff scope: The patch must stay inside the stated task. Unrelated modules, config files, or generated artifacts are a stop signal.
• Regression coverage: The relevant test suite must run against the patch, and new failures must be visible. Inferred coverage does not count.
• Format stability: Storage, API, and serialization formats must remain compatible or be explicitly versioned. Silent migrations fail the gate.
• Divergence and security accounting: Known behavior differences and security findings must be listed with an owner and disposition. Hidden exceptions in comments do not count.

Each check gives the reviewer a clear reason to stop. Provenance makes agent output accountable. Diff scope keeps a small task from dragging in a large blast radius. Regression coverage lets the system’s own tests speak before a bad patch spreads. Format stability gives version control a rollback contract. Divergence and security accounting keeps known holes assigned to a person.

DoltLite shows the receipts

DoltLite was five months old when it became Beta at version 0.50.0. DoltLite's Beta launch followed about 2,000 pull requests from a team of agents. The useful part is the evidence trail behind the speed: DoltLite passed all 5.8 million queries in the sqllogictest suite, a SQL test suite. It passed 99.46% of SQLite's 892,277 TCL-based acceptance tests, with 4,809 known divergences. DoltLite needed 12 storage-format changes before Beta and then kept the current format for 57 releases over more than three months.

The receipts change the review question. A project can move quickly and still ship when the team can point to executed tests, known exceptions, and a stable format. The gate does not ask the agent to be perfect. It asks the product to make the evidence visible before the merge button becomes meaningful. It also gives the team a shared record for later questions.

Make the gate the default

Start by wiring the checklist into the PR template. Provenance is a required field, not a comment. Diff scope shows as a visual summary, not a hope. Regression results block the merge when they fail. Format changes require a version label. Divergences and security findings appear in a table with owners. Then the team can approve the merge with the same evidence it would need in an incident review.