Why One Team Ditched Small Pull Requests in the Age of AI Code

The Rule That Made Sense

For two years, Rootly—the incident management platform—enforced a strict small-PR culture. Every change had to be atomic, capped at a few hundred lines, and stacked into tidy sequences. The logic was simple: when a human writes code, smaller diffs are easier to review and safer to roll back. A broken change gets caught quickly, and if something slips through, you revert a small, contained patch, not a sprawling mess.

That rule sounded right. It felt right. And for a while, it worked.

Then AI Agents Showed Up

Rootly’s co-founder and CTO, Quentin Rousseau, recently explained why the company threw the rule out. The reason? AI agents don’t write code the way humans do. They don’t think in increments. They think in features. Give an agent a task, and it’ll produce a complete implementation in one shot—database migrations, models, services, controllers, tests, and frontend components all at once.

That’s not a minor shift in workflow. It’s a fundamental change in how code gets written, and it breaks the assumptions behind the small-PR rule.

The Context Bug Problem

Here’s the thing about AI-generated bugs: they’re not syntax errors. The code runs fine. It just doesn’t fit the bigger picture.

Rootly’s engineering team puts it this way: “AI-induced bugs are context bugs. The code works, but it’s used in the wrong scenario.” They give a concrete example: a database migration that deletes a field still being called by a background job. Or a service that writes to a table other teams are reading from. The code is technically correct. It just breaks something else.

That’s a different kind of failure than a typo or a logic error. And it doesn’t show up in a small diff review.

The Stacked PR Experiment

Rootly didn’t abandon the rule overnight. They tried to make it work.

They attempted to have AI agents generate stacked pull requests—breaking a feature into logical chunks, each with its own PR. The result? The code was technically sound, but from a business context perspective, it was worse.

Reviewers found themselves bouncing between multiple PRs to understand what was going on. A comment on one PR depended on a change in another. The mental overhead of stitching together a feature from fragments was exhausting. And for what? The small-PR rule was designed to make human review easier, not harder.

They finally realized: the rule was optimized for human-written code. AI had removed the bottleneck it was designed to solve. Now the rule itself was the bottleneck.

Rethinking Code Review

So Rootly stopped reviewing AI code the way they reviewed human code. They built an internal AI code reviewer that evaluates every PR against their engineering standards. It produces a structured report: risk assessment, a standardized score, a confidence score, and a list of specific issues sorted by severity.

But here’s the key difference: it doesn’t try to mimic a human reviewer. Instead, it answers one question: “If this change has a flaw, which user-facing features would break?”

The AI reviewer separates changes that alter actual business behavior from those that only affect performance or UI polish, and it assigns different risk levels to each. That gives human reviewers something concrete to work with—not just a raw diff.

Blast Radius Over Line Count

Rootly’s new philosophy is simple: stop obsessing over how many lines a PR touches. Focus on blast radius—the potential damage if something goes wrong.

Feature flags have shifted the safety boundary. Instead of guarding the merge, they guard the release. Every significant feature ships behind a flag, defaulted off. The real review happens during progressive rollout: first internal users, then a small set of customers, then 10% of users, and finally everyone.

If something breaks, you flip a switch. You don’t revert a massive PR. You turn off a feature.

The engineering team sums it up: “Code size is no longer a meaningful metric. What matters is the scope of impact.”

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. He warned that AI-generated mega-PRs create serious review bottlenecks and pile up technical debt.

Rewind, a backup and version control provider, recently said its code review tool, Diff Vader, borrows Rootly’s risk-based model. The Rewind team wrote: “The risk of a PR has almost nothing to do with its line count.” Diff Vader assigns a risk label based on the review, not the diff size.

Even Patrick Debois—often called the DevOps father—has weighed in. He argues that PR-based workflows become an anti-pattern inside companies once agents are moving at speed. PRs make sense in open source, where contributors don’t share context and need to build trust gradually. But inside a team with shared context and goals, the PR review cycle becomes hard to justify when agents are iterating fast.

What Replaces the PR?

Rootly now asks questions that actually predict production incidents. The PR’s “why” and “what” sections require humans to explain the motivation, scope, and potential impact of a change. For AI-generated PRs, the human using the agent fills these in. They explicitly tell AI assistants not to generate this content, because the whole point is to capture context: why this change, why now, and what business need it serves.

Every PR also has to describe how to safely roll back, including any necessary data fixes. That’s the new safety net.

Letting Go of a Comfortable Habit

Rousseau admits that killing the small-PR rule was uncomfortable. It had felt so right for so long. But he argues it’s necessary to keep shipping reliable software quickly. He goes deeper in a separate post titled “Stop Trying to Review AI’s Code Faster: Bet on Rollbacks Instead.”

The takeaway? In a world where humans wrote every line, small PRs were the gold standard. But when you’re directing AI agents to ship complete features, that model breaks down. The new rules are about context, blast radius, and the ability to pull the plug when things go sideways.

For web design teams—especially those shipping fast and relying on AI tools—the lesson is clear: review the impact, not the size.