Why Rootly Ditched Small PRs and What It Means for Ad Tech

For years, the engineering playbook said: keep pull requests small. Atomic changes, under a few hundred lines, make review easier and rollbacks safer. That was the gospel at Rootly, an incident management platform, for two years. But in a recent blog post, the company announced it's done with that rule. The reason? AI agents write most of the code now, and the old logic just doesn't hold.

The post, written by co-founder and CTO Quentin Rousseau, makes a pointed argument: when humans write code line by line, small PRs make sense. A human can only hold so much context, and a 200-line diff is easier to eyeball than a 2,000-line monster. But AI agents don't think in increments. They think in features. Give one a task, and it'll spin up the whole implementation—database migrations, models, services, controllers, tests, and frontend components—in one shot.

That changes everything. If you force an AI to break that work into stacked PRs, you're not gaining safety. You're just adding overhead. Rootly tried it. They had agents generate stacked PRs, and the code was technically fine. But the review process turned into a nightmare. Comments on one PR depended on changes in another, so reviewers had to hop between pages, reconstructing context in their heads. The mental load was worse than reviewing a single large diff.

The Real Problem Isn't Code Size

Rootly's team landed on a key insight: the bugs that matter now are context bugs, not logic bugs. The code runs. It does what it's supposed to do. But it does it in the wrong situation. They give a concrete example: a database migration deletes a field that a background job still calls. Or a service writes to a table that another team is reading. The code didn't fail a unit test. It failed because it ignored the broader system context.

That's a different kind of risk. And it's not something a human reviewer can catch by reading a diff line by line. So Rootly built an internal AI code reviewer. It doesn't try to mimic a human reviewer. Instead, it answers one question: if this change is flawed, which user-facing features break?

The reviewer separates changes that alter actual business behavior from those that only affect performance or UI polish. It assigns risk levels accordingly. Then it hands the human reviewer a structured report—with risk scores, confidence scores, and a list of issues ranked by severity—instead of a raw diff. That's a shift from reviewing code to reviewing impact.

Feature Flags Move the Safety Line

Rousseau argues that feature flags have already moved the safety boundary from merge time to release time. Every important feature ships behind a flag. The flag is off by default. The real review happens during progressive rollout: first inside the team, then a small set of customers, then 10% of users, then everyone. If something breaks, you flip the flag off and the blast radius is contained.

That's why code size no longer matters. What matters is how far the damage spreads if something goes wrong. A small PR that touches a critical service can be catastrophic. A large PR that adds a new, isolated feature might be low risk. The metric that predicts production incidents isn't lines of code. It's blast radius.

Ad Tech's Parallel: Scale and Speed

Now, what does this have to do with advertising? More than you might think. Ad tech runs on speed. Campaigns launch, budgets adjust, targeting logic shifts—all in real time. Engineers are under constant pressure to ship new features and fixes. And increasingly, they're using AI agents to write that code.

If you're running an ad platform, the stakes are different than in Rootly's incident management world, but the principle holds. A small PR that tweaks a bid calculation could break revenue tracking for a major publisher. A large PR that adds a new reporting dashboard might be totally safe. The size of the diff tells you nothing about the risk.

What matters is whether the change can break something users depend on. In ad tech, that means revenue, campaign delivery, or data integrity. A change that alters how impressions are counted, or how budgets are allocated, or how personalization works, has a huge blast radius. A change that only affects the color of a button doesn't.

The Industry Is Catching On

Rootly isn't alone. At QCon London 2026, Michael Webster talked about headless AI agents and their impact on delivery pipelines. His point: AI-generated large PRs create serious bottlenecks for human reviewers and pile up technical debt. Backup and version control company Rewind has also adopted a risk-based review model. Its tool, Diff Vader, assigns a risk label per PR based on review findings, not on line count. Rewind's team put it bluntly: a PR's risk has almost nothing to do with how many lines it changes.

Patrick Debois, often called the godfather of DevOps, joined a panel at an AI-native developer conference in London. He argued that PR-based workflows become an anti-pattern inside companies once you're developing at agent speed. PRs made sense in open source, where contributors don't share strategic alignment and need to build trust gradually. But inside a team with shared context and goals, when agents are iterating fast, the PR review cycle is hard to justify.

Debois also pointed out that AI agents are forcing process normalization in a way humans never did. In the old days, inefficiencies in the dev process were invisible—just people being slow. Now, every token an AI agent consumes shows up as a line on the bill. Waste is literally quantifiable. That's pushing companies to rethink what's actually necessary.

What Replaces the Small PR Rule?

At Rootly, the new approach is to ask questions that actually predict production incidents. The PR template now requires developers to explain the “why” and “what” of a change: the motivation, the scope, the potential impact. For AI-generated PRs, the human using the agent fills this out. And Rootly explicitly tells AI assistants not to generate this content. The point is to capture context—why this change, why now, what business need does it serve. Each PR must also describe how to safely roll back, including any necessary data fixes.

That's a fundamentally different review process. Instead of checking syntax and style, you're checking intent and blast radius. The human becomes a risk manager, not a code inspector. The AI handles the line-by-line stuff. The human focuses on what could break in the real world.

Lessons for Ad Engineering Teams

So what can ad tech teams take from this? First, stop measuring PRs by lines of code. That metric is meaningless in the age of AI. Second, invest in feature flags and rollback capabilities. If you can turn off a feature instantly, you can afford to ship bigger changes. Third, build review processes that focus on risk, not on code aesthetics. Ask: what could this break? What's the blast radius? How do we roll back?

Rootly admits that killing the small PR rule was uncomfortable. It had felt right for so long. But they realized it was a rule designed for human speed, not agent speed. And in a world where you're orchestrating AI agents to deliver entire features, the old rule just gets in the way. The goal is to ship reliable software fast. That means embracing bigger changes, controlled by risk assessment and rollback, not by arbitrary line counts.

Rousseau sums it up in a separate post: “Stop trying to review AI's code faster. Bet on rollbacks instead.” That's a mindset shift that ad tech—and any software team using AI agents—would do well to consider.