Why Rootly Killed the Small-PR Rule: AI Agents Rewrite Code Review Logic

The Small-PR Rule: A Once-Good Idea

For two years, Rootly enforced a strict small-pull-request culture. Developers were told to keep changes atomic, often under a few hundred lines, and to stack PRs when needed. It made sense in the era of human-written code. Smaller diffs are easier to review, easier to reason about, and easier to roll back if something goes sideways. That was the logic, and for a long time, it worked.

But last week, the incident-management platform announced it's abandoning that rule. The reason? AI agents now write most of the code, and the old metric just doesn't hold up anymore.

AI Thinks in Features, Not Diffs

Quentin Rousseau, Rootly's CTO and co-founder, laid it out plainly: AI agents don't think in increments. They think in features. When you point an agent at a task, it doesn't produce a small patch that adds one endpoint. It produces the whole implementation—database migration, model, service, controller, tests, frontend component—all at once. That's a lot of code, but it's coherent code. It fits together because it was generated as a unit.

The problem is that our review process still assumes code arrives in small, human-sized chunks. We've built our entire workflow around that assumption, and it's starting to crack.

The Context Blind Spot

Rootly's engineering team points out that AI-caused bugs are rarely syntax errors or obvious logic mistakes. The code runs fine. It does what it was asked to do. The trouble is that it's doing the wrong thing in the wrong context.

Take a concrete example from their post: a database migration that drops a field still being called by a background job. Or a service that starts writing to a table other teams are actively reading. The code is technically correct—but it's blind to the broader business context. That's the kind of bug that slips through when you review diff-by-diff.

Stacked PRs: A Messy Compromise

Rootly didn't give up on small PRs without a fight. They tried having AI agents generate stacked pull requests, hoping to preserve the granular review process. The result? Code that was technically sound but contextually worse.

Reviewing one PR in a stack often required understanding changes in a sibling PR. Reviewers found themselves flipping between multiple pages, trying to piece together the full picture. The mental overhead was brutal. In the end, they realized something important: the small-PR rule was designed for human efficiency, not AI efficiency. Once you remove the human bottleneck, the rule becomes pure overhead.

Enter the AI Code Reviewer

So Rootly built its own AI code reviewer. But here's the twist: it doesn't try to mimic a human reviewer. Instead, it answers a single question for every PR: if this change has a flaw, which user-facing features break?

The reviewer categorizes changes into two buckets: those that alter actual business behavior, and those that only affect performance or UI polish. Each gets a different risk level. The output is a structured report—risk assessment, a standardized score, a confidence score, and a list of concrete issues sorted by severity. It's not a replacement for human judgment; it's a map for human reviewers to navigate the growing pile of AI-generated code.

Feature Flags: Shifting the Safety Boundary

One of the most interesting shifts Rootly describes is where safety lives now. It used to be that the merge button was the gate. Once code was merged, it was out there. Now, with feature flags, that boundary has moved to release.

Every significant feature ships behind a flag, and it's off by default. The real review happens during progressive rollout: first internal users, then a few customers, then 10% of users, then everyone. This is where you actually see how the change behaves in production, not in a synthetic review environment.

Rousseau argues that the size of a change is no longer a useful signal. What matters is the blast radius—how many users, features, or systems could be affected if something goes wrong.

Industry Echoes: Rewind and Others

Rootly isn't alone in this thinking. Rewind, a backup and version-control service, recently said its code review tool, Diff Vader, borrows from Rootly's risk-based model. They wrote that a PR's risk has almost nothing to do with its line count. Instead, Diff Vader assigns a risk label based on what the review finds.

And at the 2026 London AI Native Developer conference, a panel featuring Patrick Debois—often called the DevOps father—discussed why PR-based workflows become an anti-pattern once agents are moving at their own speed. Debois argued that PRs work well in open source because contributors don't share strategic direction and need to build trust. But inside a team with shared context and goals, when agents are iterating rapidly, the review cycle becomes increasingly hard to justify.

The Cost of Inefficiency

There's also a financial angle. When humans write code, inefficiencies in the process are hard to see. But with AI, every token consumed shows up on a bill. The panel noted that this is forcing teams to formalize their workflows—waste becomes visible, and that visibility drives change.

What Replaces the Small-PR Rule?

Rootly's new approach is to ask questions that actually predict production incidents. Each PR must include a 'why' and a 'what' section. Developers—or the humans orchestrating the agents—have to explain the motivation, the scope, and the potential impact. Notably, Rootly instructs its AI assistants not to generate these sections. The 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. That's a shift from reviewing code to reviewing the safety plan.

Letting Go of a Rule That Felt Right

Rousseau admits the transition was uncomfortable. The small-PR rule felt correct. It was a best practice that had been drilled into developers for years. But holding onto it was slowing them down without making things safer.

In a separate post titled 'Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead,' he goes deeper into this production-focused safety mindset. The message is clear: you can't review your way to safety when the code is coming at you at machine speed. You need to design for failure and make rollback easy.

The Bottom Line

Rootly's conclusion is straightforward: in a world where humans write every line, small pull requests were the right call. But when you're dispatching agents to deliver complete features, that rule becomes obsolete. The metrics that matter now are blast radius, feature flag coverage, and rollback speed.

It's a hard pill to swallow for anyone who's spent years perfecting the art of the small diff. But as AI keeps writing more of our code, the way we review it has to change too. The old rules were made for a different game.