Why Rootly Killed Its Small PR Rule for AI-Generated Code

The End of a Sacred Rule

For two years, Rootly enforced a strict small-PR culture. Every change had to be atomic, stacked, and capped at a few hundred lines. Reviewers loved it. Rollbacks were trivial. Then AI agents showed up and ruined the math.

Quentin Rousseau, Rootly's co-founder and CTO, recently explained why the company abandoned the rule. The short version: small PRs were built for human typing speed. AI doesn't type. It generates whole features in one shot—migrations, models, controllers, tests, frontend bits, all at once. Squeezing that into tiny review chunks doesn't just add overhead. It makes things worse.

The Context Problem

Here's the thing about AI bugs. They're not syntax errors or logic slips. The code runs fine. It's just used in the wrong place. Rootly's engineering team gives a concrete example: a database migration removes a field that a background job still calls. Or a service writes to a table that another team reads. You can't catch that by staring at a diff in isolation.

AI agents think in features, not increments. They see the whole picture—or at least the picture they were trained on. That means the code they produce is contextually complete, but the context might be wrong. Small PRs were designed to surface those context gaps early. But when an agent dumps 800 lines of perfectly coherent code, breaking it into five stacked PRs doesn't help. It just spreads the context across five screens.

Stacked PRs, Stacked Confusion

Rootly tried it anyway. They asked their AI agents to generate stacked pull requests. The result? Technically sound code that made less sense overall. Reviewers would comment on PR #3, but the fix depended on code in PR #5. They'd flip between tabs, tracing logic across branches, trying to hold the whole feature in their heads. It was a mental tax with zero payoff.

The team realized the old rule wasn't neutral. It was actively harmful. Small PRs had been a tool for human efficiency. Now they were a bottleneck in an AI-driven pipeline.

Enter the Internal AI Reviewer

So Rootly built its own AI code reviewer. But they didn't try to make it mimic a human. Instead, it answers one question per PR: if this change is flawed, what user-facing features break?

The reviewer separates changes that alter actual business behavior from those that only affect performance or UI polish. Each gets a different risk level. It produces a structured report—risk assessment, standardized score, confidence score, and a categorized list of issues. Human reviewers get that, not a raw diff.

The key is that the AI reviewer isn't pretending to be a senior engineer. It's a risk filter. It points humans at the spots most likely to cause production incidents.

Feature Flags Move the Goalposts

Rootly's shift didn't happen in a vacuum. They'd already changed where safety lives. With feature flags, the merge point isn't the danger zone anymore. The release point is.

Every significant feature now ships behind a flag, default off. The real review happens during progressive rollout: first the internal team, then a small customer, then 10% of users, then everyone. That's where context leaks surface—not at merge time.

So the question "how many lines is this PR?" becomes meaningless. What matters is: how far can this break spread?

The Industry Is Catching On

Rootly isn't alone. Rewind, a backup and version control service, built a tool called Diff Vader that borrows Rootly's risk-based model. They assign a risk label per PR based on the review, not the line count. Their team put it bluntly: a PR's risk has almost nothing to do with its size.

At the 2026 London QCon, Michael Webster talked about headless AI agents and the strain they put on software delivery. His point: AI-generated mega-PRs create bottlenecks for human reviewers and pile up technical debt.

And at a London AI-native developer conference, a panel—including Patrick Debois, the so-called DevOps father—asked why PR workflows become an anti-pattern at agent speed. Debois argued that PRs make sense in open source, where contributors don't share context and trust has to be built. But inside a company, with a common goal and shared context, waiting for PR review just slows everything down.

What Actually Predicts Incidents?

Rootly's new approach is to ask questions that actually predict production incidents. The PR template still includes "why" and "what" sections, but now they're filled in by the human who directed the agent—not by the AI itself. Rootly explicitly tells AI assistants to skip those fields. The point is to capture context: why this change, why now, what business need does it serve? And every PR has to describe how to roll back safely, including any data fixes.

That's the real shift. Instead of trying to review AI code faster, Rootly is betting on rollbacks. Make it easy to revert, and you don't need to catch every flaw at review time.

As Rousseau wrote in a companion post, "Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead." The title says it all.

Letting Go of What Felt Right

Ditching the small-PR rule wasn't easy. Rousseau admits it felt wrong at first. The rule had been a cornerstone of their engineering culture. But it was built for a world where humans write every line by hand.

Now, with AI agents shipping complete features, that world is gone. The old rule doesn't just fail—it actively gets in the way. The new goal is simple: deliver reliable software fast. That means measuring blast radius, not line counts. It means designing for rollback, not for perfect review.

It's a hard pill to swallow for anyone who grew up on the gospel of small PRs. But Rootly's bet is that the future belongs to teams willing to rethink their assumptions.