How auto-approving low-risk PRs with AI cut our lead time by 74%

Our engineers waited a median of 2 hours 49 minutes for their first PR approval. Four weeks after we let an AI agent approve low-risk PRs, that dropped to 3.8 minutes, lead time fell 74%, and deploys tripled, all with the same size team.

This is the policy we wrote, how we built trust in the system, and what the data looks like.

The problem: the review queue

Coding agents and assistants made our engineers faster at writing code. Our team averages 10.8 PRs per engineer per week, 2.5x the 90th percentile according to DX benchmarks. But every one of those PRs still needed a human to look at it, and the review queue became the constraint.

An engineer would open a PR, context-switch, and wait. The reviewer would get to it hours later, leave a comment, and the author would context-switch back. For a small bug fix in well-tested code, this round trip often took longer than writing the fix itself. We were producing PRs faster than we could review them.

Not every PR needed the same scrutiny. Architecture decisions, auth logic, database migrations: these deserve careful human attention. But a dependency bump, a copy change, a small bug fix in a file with good test coverage? For those, the human reviewer's contribution was often a single word: "LGTM." Requiring the same process for both wastes senior engineer attention and slows down changes that are safe to ship quickly.

The experiment

We already had Ona's code review automation running on every PR. The agent reviewed diffs, ran the code in a full environment, cross-referenced tickets, and left inline comments with an 88% acceptance rate and a 50% reduction in time spent on pull requests.

If humans accept the agent's feedback 88% of the time, can it approve certain PRs outright?

We spent two weeks tracking which PRs the agent reviewed where the human reviewer added nothing beyond approval. The pattern was consistent: small changes, no sensitive areas touched, tests passing, no infrastructure modifications. So we wrote a policy.

The policy

Two principles guided the Low-Risk Change Policy.

First, engineers cannot self-classify a change as low-risk. An Ona Automation evaluates every PR against objective criteria automatically, which removes the temptation to game the system and makes the boundary auditable.

Second, the AI agent reviews every PR regardless of classification. The question is not whether the agent reviews, but whether a human also needs to.

The six criteria

A change qualifies as low-risk only if it meets all of the following:

1. Fewer than 1,000 lines changed (additions and deletions combined)
2. No protobuf changes added or modified
3. No database migrations added or modified
4. No infrastructure or CI configuration changes
5. No authentication or authorization logic changes
6. No audit logging or monitoring changes

If any single criterion is not met, the change is routed to human review.

How the review works

When a pull request is opened, the AI agent reviews it in an isolated environment with independent context. It evaluates the change against the low-risk criteria and code quality, then posts a structured comment:

Approved. The change meets all low-risk criteria. The comment explains the reasoning for each criterion.

Escalated to human review. One or more criteria are not met, or the agent flagged something worth a human look. The comment explains why and a label is added for tracking.

Every PR is reviewed by the AI agent. Low-risk PRs are approved automatically. All others are escalated. A human always merges.

Governance

The AI agent can approve the review, but a person always clicks the merge button. That merge is the traceable approval event for SOC 2: the agent handles the review workload, the human controls what ships. The agent's review comment stays in version control alongside the merging engineer's identity and timestamp.

The engineering platform team owns the classification tooling. Any changes to the evaluation logic, the criteria, or the agent's review prompt require explicit approval from the Head of Product Design and Engineering. Swapping the AI model counts as a material change to the policy.

Auto-approve was the biggest lever, but we made two other changes at the same time: we stopped global auto-assignment of reviewers (which had created noise nobody acted on) and made PR authors responsible for choosing their own reviewers. The agent still reviews every PR regardless. For low-risk changes, its review is the only one needed. For everything else, it catches surface-level issues before the human reviewer opens the diff.

The results

On March 13, 2026 at ~15:07 UTC, the ona-automations bot auto-approved its first pull request. The effect was a step function, not a gradual trend.

Time to first approval dropped from a median of 2 hours 49 minutes to under 5 minutes. Before the bot, only 13% of PRs received approval within 10 minutes. After, 73% did.

The bot only approves the review, not the merge. A human still clicks the merge button, yet lead time still dropped by 74%. The approval wait was the real blocker. Before auto-approve, engineers would context-switch away after opening a PR because they knew review could take hours. By the time approval came, they were deep in another task. With approval arriving in minutes, they're still in context and merge immediately. We didn't need auto-merge to get the speed benefit.

Lead time followed within days as the team adapted to the faster feedback loop, and deploys per week tripled.

We compared 4-week windows before and after the switch, looking only at human-authored PRs to isolate the effect on developer velocity:

The team was roughly the same size throughout (39 unique contributors before, 43 after), but each developer went from merging 34 PRs per month to 96: a 2.9x increase in individual throughput with no headcount change.

The policy also changed how engineers write PRs. Large, unfocused changes are more likely to trip the criteria and get routed to human review, so engineers naturally gravitate toward smaller, focused PRs. That is a win for everyone: smaller PRs are easier for humans to review, easier for the agent to review, and faster to ship.

Faster approval shortens lead time, which increases deploy frequency, which shrinks batch sizes, which lowers risk per change. DORA research describes this virtuous cycle, and we got there by removing the review bottleneck rather than adding more reviewers.

What we learned

Start by observing, not by deciding. We did not start with a policy. We watched which PRs humans rubber-stamped, and the policy codified what we saw.

Automated classification is non-negotiable. Self-classification creates an incentive to game the system. Let the automation draw the line.

The governance model matters more than the AI model. Automated classification, explicit criteria, audit trails, human merge authority, policy ownership. Swap the model and the system still works. Remove the governance and it falls apart.

Human merge authority is the trust anchor. The AI approves the review, a human merges the code. That separation is what makes the system acceptable to security teams, auditors, and engineers who are skeptical of AI-only review, and it is what keeps us SOC 2 compliant.

If your engineers produce PRs faster than they can review them, more AI coding tools will make it worse. Look at where time actually goes. For us, it was waiting for approval.

Try it yourself

Start with the code review automation template, which runs on every PR opened across your configured projects and leaves structured review comments. The auto-approve layer is a policy decision on top of that: define your low-risk criteria, build the classification automation, and let the agent handle the rest.

Set up code review → | Read how we became a 99th percentile org →