Why Rootly Ditched Small PRs: Access Control Shifts to Release Gates

The Rule That Made Sense—Until AI Showed Up

For two years, Rootly enforced a strict small-PR culture. Stacked pull requests. Atomic changes capped at a few hundred lines. It worked. When humans write code by hand, smaller diffs are easier to review and safer to roll back. The logic felt bulletproof.

Then AI agents started generating entire features in one shot—database migrations, models, services, controllers, tests, front-end components. The small-PR rule didn't just stop helping. It started hurting.

Rootly's CTO Quentin Rousseau explained the shift in a recent blog post. The company realized that reviewing AI-generated code with human-era rules adds overhead without improving safety. The old metric—lines of code—no longer predicts risk. What matters now is blast radius: which user-facing features break if this change goes sideways?

The Context Bug Problem

AI-generated bugs are rarely syntax errors. They're context bugs. The code runs fine—it's just used in the wrong scenario. A database migration drops a field a background job still calls. A service writes to a table another team reads. These failures don't show up in code review because the code itself isn't wrong.

Rootly's engineering team tried stacking AI-generated PRs. The output was technically correct, but from a business context perspective, it was worse. Reviewing one PR required jumping to another to understand dependencies. Reviewers toggled between pages, mentally stitching together a feature that should have been reviewed as a whole. The small-PR rule, designed for human efficiency, became an extra tax on top of AI speed.

Reviewing AI Code Differently

Rootly's answer: don't review AI code the way you review human code. They built an internal AI code reviewer that examines every PR against engineering standards. It produces a structured report: risk assessment, standardized score, confidence score, and a list of issues sorted by severity.

The crucial difference? It doesn't try to act like a human reviewer. Instead, it answers one question: if this change has a defect, which user-facing features break?

The tool separates changes that alter actual business behavior from those that only affect performance or UI. Each gets a matching risk level. Human reviewers get a structured reference, not just a raw diff.

Access Control Moves to the Release Gate

Rousseau emphasizes that feature flags have shifted the security boundary from the merge stage to the release stage. Every important feature now ships behind a feature flag, turned off by default. The real review happens during progressive rollout: enable for the team, then a small customer group, then 10% of users, then everyone.

This changes what access control means. It's no longer about who can merge code. It's about who can flip the switch, and under what conditions. The merge is just a checkpoint. The release is where access decisions actually matter.

Rootly now asks questions that predict real incidents. Each PR includes a "why" and "what" section where developers explain the motivation, scope, and potential impact. For AI-generated PRs, the human using the agent fills these in. Rootly explicitly tells AI assistants not to generate these sections—the goal is to capture context: why this change, why now, what business need does it serve. Every PR must also describe how to roll back safely, including any necessary data fixes.

What Other Companies Are Seeing

Rootly isn't alone. Rewind, a backup and version control provider, recently said its code review tool Diff Vader uses a similar risk-based model. The team wrote that a PR's risk has almost nothing to do with lines changed. Diff Vader assigns a risk label based on review results, not diff size.

At a London QCon talk, Michael Webster discussed headless AI agents and their impact on delivery pipelines. He pointed out that large AI-generated PRs create bottlenecks for human reviewers and accumulate technical debt. The problem isn't just review time—it's that the review process itself becomes less meaningful when the code is generated wholesale.

The PR Workflow as Anti-Pattern

A panel at the London AI Native Developer Conference debated why PR-based workflows become an anti-pattern in enterprises once agents reach a certain speed. Patrick Debois, often called the DevOps father, argued that PRs make sense in open source because contributors don't share strategic alignment—they need to build trust. But inside a team with shared context and goals, when agents iterate quickly, the PR review cycle gets hard to justify.

Debois also noted that agent-driven development exposes inefficiencies in the process. In pure human development, waste hides in meetings and handoffs. With AI agents, token consumption is measurable, and waste shows up directly in costs. That quantification is pushing teams to formalize and streamline their pipelines.

Rollbacks Over Reviews

Rousseau wrote a companion piece titled "Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead." The title says it all. Instead of obsessing over perfect reviews, invest in making rollbacks cheap and reliable.

For access control, this means designing systems where rollback is an access decision: who can trigger a rollback, what data needs to be restored, and how quickly can it happen. Feature flags become the control plane for access. The old gate—merge approval—becomes less critical.

The New Metrics

The small-PR rule was optimal when everyone wrote code by hand. That era is over. Teams now schedule AI agents to deliver complete features, and the review process has to adapt.

What's the new metric? Not lines of code. Not even review time. It's blast radius: how many users could be affected, and how fast can you recover if something goes wrong?

Rootly's conclusion: in a world of agent-generated code, the small-PR rule is dead. Access control has moved to the release stage, and rollback capability matters more than diff size. The tools you use to gate access—feature flags, progressive rollout, rollback plans—are the ones that will actually prevent incidents.

If you're still measuring PRs by lines changed, you're measuring the wrong thing. Start measuring what breaks.