Why Rootly Ditched Small PRs: A Historical Shift in Code Review

The End of an Era: Rootly's Small PR Rule

For years, the software industry has held a near-sacred belief: small pull requests are better. They're easier to review, simpler to roll back, and they keep the codebase clean. Rootly, an incident management platform, was a true believer. For two years, they enforced a strict culture of small PRs, requiring stacked pull requests and atomic changes limited to a few hundred lines. It felt right. It was right—for a world where humans wrote every line of code.

But as Rootly's CTO Quentin Rousseau explains in a recent blog post, that world has changed. AI agents now generate most of the code. And the old rule, once a pillar of efficiency, has become an anchor dragging the team down.

The AI Agent Revolution in Code Generation

AI agents don't think in increments. They think in features. When you ask an agent to build a new capability, it doesn't produce a single, isolated change. It spits out a complete implementation: database migrations, models, services, controllers, tests, and frontend components—all in one go. This is a fundamental shift in how code comes into existence, and it has profound implications for review practices.

Rootly tried to force AI agents to generate stacked pull requests—the kind that break work into small, logical chunks. The result was technically correct but contextually worse. Reviewers had to hop between multiple PRs to understand a single change, and comments on one PR often referenced solutions in another. The mental overhead was immense. It was like trying to read a novel one page at a time, but each page was in a different book.

The Contextual Nature of AI Bugs

The team also noticed something about the bugs AI introduces. They're not your typical syntax errors or logic flaws. AI-generated code runs fine—it just does the wrong thing in the wrong context. For example, a database migration might delete a field that a background job still calls. Or a service might write to a table that another team is actively reading. These are context bugs, not code bugs.

This realization led Rootly to a critical insight: the size of a PR tells you almost nothing about its risk. A one-line change could bring down the entire system, while a thousand-line change might be perfectly safe. The metric that matters is the blast radius—how much damage could this change do if it goes wrong?

From Line Count to Blast Radius: A New Review Philosophy

Rootly's response was to stop reviewing AI code the way they reviewed human code. They built an internal AI code reviewer that examines every PR against engineering standards and produces a structured report: risk assessment, standardized score, confidence score, and a list of specific issues ranked by severity.

But here's the key difference: this AI reviewer doesn't try to mimic a human reviewer. It answers one question: if this change has a flaw, which user-facing features would break? It categorizes changes into those that alter actual business behavior and those that only affect performance or UI appearance, assigning appropriate risk levels to each. This gives human reviewers a structured reference, not just a raw diff.

Feature Flags: Shifting the Safety Boundary

Rousseau emphasizes that feature flags have moved the safety boundary from the merge stage to the release stage. Every significant feature now ships behind a feature flag, so when a PR is merged and pushed to production, the feature is off by default. The real review happens during progressive rollout: first to the internal team, then to a small set of customers, then to 10% of users, and finally to everyone.

This approach makes the merge itself less risky. The true gate is the rollout, not the PR review. And that's a profound shift in thinking. As the team puts it, "The size of a code change no longer matters; what matters is the impact of a failure."

The Industry Catching On: Rewind and Diff Vader

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

This is a growing trend in the industry. At the 2026 London QCon conference, Michael Webster discussed the rise of headless AI agents and their impact on software delivery pipelines. He noted that AI-generated large-scale PRs create serious bottlenecks for human reviewers and accumulate persistent technical debt. The conversation is spreading.

Debating PRs in the Agentic Era

At the London AI Native Developer Conference in June 2026, a panel including Patrick Debois (often called the father of DevOps) explored why PR-based workflows become an anti-pattern in enterprises once development runs at agent speed. Debois argued that PRs make sense in open-source communities, where contributors have divergent strategic goals and need to build trust gradually. But inside a team with shared context and objectives, when agents are iterating rapidly, PR review cycles are increasingly hard to justify.

The panel also discussed how AI agent costs are forcing process formalization. In the pure human era, inefficiencies in the pipeline were easy to ignore. Now, with AI, token consumption is quantifiable, and waste shows up directly in the bill. It's a new kind of visibility.

Asking the Right Questions: Why and What

Rootly's new philosophy focuses on questions that actually predict production incidents. Each PR now requires a 'Why' and 'What' section, where developers explain the motivation, scope, and potential impact of the change. For AI-generated PRs, the human using the agent fills these in. And they explicitly instruct AI assistants not to generate this content, because the goal is to capture context: why this change, why now, what business need does it serve. Every PR also describes how to safely roll back, including any necessary data fixes.

Rousseau admits that abandoning the small PR rule was uncomfortable. It had felt so right for so long. But it was necessary to support the goal of delivering reliable software quickly. In another article, titled "Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead," he elaborates on this shift toward production-side safety.

A Historical Turning Point for Code Review

This moment marks a significant historical shift in software engineering practice. The small PR rule was a product of its time—a time when human effort was the bottleneck and incremental review made sense. Now, with AI agents capable of producing entire features at once, the old rules don't just fall short; they actively hinder progress.

As Rootly's team summarizes: in the era of human-written code, small pull requests were indeed the best practice. But now that teams rely on AI agents to deliver complete features, that approach is obsolete. The industry is moving toward a new paradigm where risk assessment and rollback capability matter more than the size of a change. It's a shift that will shape how we build software for years to come.