Rootly Killed Its Small-PR Rule. Here's What Replaced It

Two Years of Small PRs, Gone

For two years, Rootly ran a strict small-PR policy. Every change had to be atomic, stacked, and under a few hundred lines. That made sense when humans typed out every line. Smaller diffs are easier to review, easier to reason about, and easier to roll back if something breaks.

Then AI agents started writing the majority of the code. And that old rule became a drag. Rootly's engineering team recently published a post explaining why they dropped the small-PR rule. Honestly, it's a story that hits home for a lot of teams, not just theirs.

AI Agents Think in Features, Not Diffs

Here's the thing about AI agents: they don't think in increments. Give them a task and they'll produce the whole implementation—database migrations, models, services, controllers, tests, frontend components—all in one go. That's a completely different unit of work from what a human would hand over.

Rootly's CTO, Quentin Rousseau, put it bluntly: when humans wrote code, small diffs were gold. Now they're just overhead. The old rule was built for human efficiency, and AI has blown past that constraint.

Stacked PRs and AI: A Mismatch

They tried to force AI agents to generate stacked PRs—the whole sequence of dependent changes, each building on the previous one. The result? Code that was technically correct but contextually worse. Reviewers would look at one PR, and comments would reference changes in another PR down the stack. You'd find yourself flipping between five tabs, trying to hold the whole picture in your head. It was a nightmare.

One of the biggest issues with AI-generated bugs is that they're context bugs. The code runs fine. It's just used in the wrong scenario. For example, a database migration deletes a field that a background job still calls, or a service writes to a table that another team reads from. Those kinds of issues don't show up in a line-by-line review. They show up when you understand the whole system.

From Line Counts to Blast Radius

So Rootly shifted their focus. Instead of asking "how many lines changed?" they started asking "what's the blast radius?" If this change has a bug, what user-facing features break? That's the question that actually matters.

They built an internal AI code reviewer that doesn't try to mimic a human reviewer. It doesn't nitpick style or suggest variable renames. Instead, it looks at every PR and produces a structured report: risk assessment, a standardized score, a confidence score, and a list of specific issues sorted by severity. The key distinction is that it categorizes changes into two buckets: those that alter actual business behavior, and those that only affect performance or UI. Each gets a different risk level, giving human reviewers a framework to jump into, rather than a raw diff to stare at.

Feature Flags: The New Safety Net

Rousseau emphasizes that feature flags have moved the safety boundary from the merge step to the release step. Every significant feature now ships behind a feature flag. The PR gets merged, the code goes to production, but the feature is off by default. The real review happens during progressive rollout: first the team enables it internally, then a small group of customers, then 10% of users, and finally everyone.

This is a different mindset. You're not trying to catch every possible bug before merge. You're betting on your ability to detect problems early in the rollout and roll back quickly if something goes wrong. The size of the code change becomes irrelevant. What matters is the scope of potential damage.

The Industry Is Catching On

Rootly isn't alone in this thinking. At the 2026 QCon London conference, Michael Webster talked about headless AI agents and their impact on software delivery. He pointed out that large AI-generated PRs create serious bottlenecks for human reviewers and pile up technical debt. Other companies are echoing the same sentiment.

Rewind, a backup and version control service, recently said their code review tool Diff Vader borrows Rootly's risk-based model. They wrote that a PR's risk has almost nothing to do with line count. Diff Vader assigns a risk label to each PR based on the review, not the number of lines changed.

PRs: An Antipattern in the Age of Agents?

At the AI Native Developer Conference in London, a panel including Patrick Debois—often called the father of DevOps—discussed why PR-based workflows become an antipattern inside companies once development moves at agent speed. Debois argued that PRs make sense in open source, where contributors don't share a strategic direction and need to build trust gradually. But inside a team with shared context and goals, when agents are iterating fast, the PR review cycle becomes hard to justify.

What's interesting is that the cost of AI agents is forcing process standardization. In the old days, inefficiencies in the process were hard to see. Now, every wasted token shows up on a bill. So teams are being forced to think about what actually adds value.

What Replaces the Small PR Rule?

Rootly's new approach is to ask questions that actually predict production incidents. Each PR requires a "why" and a "what" section, where the human using the agent explains the motivation, scope, and potential impact. They explicitly tell AI assistants not to generate this content, because the whole point is to capture context: why this change, why now, what business need does it serve? Every PR also has to describe how to roll back safely, including any necessary data fixes.

Rousseau admits that killing the small-PR rule felt wrong at first—it had become a sacred cow. But it was necessary to support "fast delivery of reliable software." In a companion post titled "Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead," he digs deeper into this shift toward production-side safety.

The Takeaway

Look, the small PR rule wasn't stupid. It was the right call for a world where humans wrote every line. But that world is gone. AI agents don't think in increments—they think in features. If you're still trying to force them into human-sized chunks, you're just adding friction without adding safety.

What matters now is blast radius, feature flags, and rollback capability. That's where you should be spending your energy. Not on counting lines.