Why This DevOps Team Killed Its Small PR Rule for AI Code

The End of the Small PR Era

For two years, Rootly—an incident management platform—ran what felt like a textbook engineering culture. Every pull request had to be small. Developers stacked PRs, kept atomic changes to a few hundred lines, and reviewed each diff with care. It worked. Humans wrote code then, and small diffs were easier to reason about and roll back.

Then AI agents showed up. And the rule started feeling like a relic. In a recent blog post, Rootly's co-founder and CTO Quentin Rousseau explained why the company officially abandoned its small-PR policy. The reasoning isn't about taste or preference—it's about how AI agents fundamentally change the shape of code contributions.

AI Thinks in Features, Not Diffs

When a human writes code, they naturally think in increments. A small change here, a tweak there. But an AI agent doesn't work that way. Given a task, it produces a complete implementation in one shot: database migration, model, service, controller, tests, and frontend component. It thinks in features, not diffs.

That means the old assumption behind small PRs—that smaller is always safer—breaks down. A 50-line change that touches a critical shared service can be far more dangerous than a 500-line change that introduces a new isolated feature. The size of the diff stops being a meaningful proxy for risk.

Context Is the Real Problem

Rootly's engineering team noticed something odd about AI-generated bugs. They're not logic errors in the traditional sense. The code runs fine. It's just used in the wrong context.

One example they cite: a database migration that deleted a field still being called by a background job. Or a service writing to a table that another team reads. These aren't syntax mistakes—they're context mistakes. The code is technically correct, but it doesn't fit the broader system.

That's a different kind of review challenge. You can't spot it by reading lines. You need to understand how the change interacts with everything else.

Stacked PRs Made It Worse

Rootly tried to keep the small-PR religion alive by asking AI agents to generate stacked PRs. The result? Code that was technically fine but actually worse from a business and system perspective.

Reviewers found themselves jumping between multiple PRs to understand a single change. Comments on one PR depended on changes in another. The mental overhead became exhausting. As Rousseau put it, the small-PR rule was designed for human coding efficiency. When AI removes the human efficiency bottleneck, the rule becomes pure overhead.

What Replaced the Rule

Rootly didn't just delete the rule and hope for the best. They built an internal AI code reviewer that looks at every PR with a different question in mind: 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 aesthetics. Each gets a risk score. The output isn't a human mimic—it's a structured report with risk assessment, a confidence score, and a list of specific issues sorted by severity. It gives human reviewers a map, not just a raw diff.

Feature Flags Shift the Safety Boundary

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 flag, defaulted off. The real review happens during progressive rollout: first internally, then with a small customer group, then 10% of users, then everyone.

This changes what matters. A merged PR is no longer a point of no return. If something breaks, you flip the flag. Rollback becomes a configuration change, not a code revert. So the size of the diff matters less than the blast radius of the feature.

The Industry Is Catching On

Rootly isn't alone. At QCon London 2026, Michael Webster talked about headless AI agents and their impact on software delivery. His point: large AI-generated PRs create bottlenecks for human reviewers and pile up technical debt.

Rewind, a backup service, recently said its code review tool Diff Vader borrows Rootly's risk-based model. The team there wrote that a PR's risk has almost nothing to do with its line count. Instead, Diff Vader assigns a risk label based on the review itself.

At an AI-native developer conference in June 2026, a panel including Patrick Debois—often called the DevOps father—discussed why PR-based workflows become an anti-pattern once agents are coding at speed. Debois argued that PRs make sense in open source, where contributors don't share strategic alignment and need to build trust. But inside a team with shared context and goals, the review cycle becomes harder to justify when agents iterate quickly.

What Actually Predicts Incidents

Rootly's new approach focuses on questions that actually predict production incidents. Their PR template now includes sections for 'why' and 'what'—developers explain the motivation, scope, and potential impact. For AI-generated PRs, the human using the agent fills these out. Rootly explicitly tells AI assistants not to generate this content, because the point is to capture context: why this change, why now, what business need.

Every PR also must describe how to roll back safely, including any necessary data fixes. That's a shift from reviewing code as a static artifact to reviewing it as a decision with consequences.

Letting Go of a Rule That Felt Right

Rousseau admits that killing the small-PR rule was uncomfortable. It had felt correct for so long. But he argues it's necessary to support 'fast delivery of reliable software.' In a follow-up post titled 'Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead,' he doubles down on moving safety to the production side.

The takeaway? In a world where humans hand-write every line, small PRs were the right call. But when you're directing AI agents to ship complete features, that rule becomes a bottleneck. The real metric isn't how many lines changed. It's how much damage a bad change could do—and how fast you can undo it.