How Rafting Teams Are Ditching Small PRs for Bigger Runs

The Old Rule: Small PRs, Small Rapids

For years, the mantra in software development was simple: keep your pull requests small. A few hundred lines of code, atomic changes, stacked PRs—all designed so that a human reviewer could wrap their head around the diff without breaking a sweat. It was the equivalent of scouting a Class II rapid before running it. You could see the whole thing, plan your line, and if something went wrong, you could bail out without much damage.

Rootly, an incident management platform, lived by this rule for two years. Their CTO, Quentin Rousseau, explained that when humans were writing all the code, small PRs made perfect sense. Smaller diffs were easier to review, easier to revert, and easier to reason about. But then AI agents showed up, and they changed the game.

AI Agents Write Whole Features, Not Increments

Here's the thing about AI agents: they don't think in terms of increments. They think in terms of features. Give one a task, and it'll generate the entire implementation—database migrations, models, services, controllers, tests, and frontend components—all in one go. That's like a rafting guide looking at a river and deciding to run the entire canyon in one push, rather than eddy-hopping from one pool to the next.

Rootly tried to force their AI agents to produce stacked pull requests, the way a human might break up a big change into reviewable chunks. The result? The code was technically fine, but it missed the bigger picture. Reviews of one PR often depended on changes in another PR, forcing reviewers to hop between multiple pages and stitch together the full context. It was mentally exhausting, and the output was worse than letting the agent do its natural thing.

Context Is Everything—On the River and in Code

Rousseau and his team realized something crucial: AI-generated bugs are context bugs. The code runs fine, but it's used in the wrong scenario. A database migration might drop a field that a background job still calls. A service might write to a table that another team is reading. On the river, it's the same—you can paddle a perfect stroke, but if you're in the wrong eddy, you'll end up in the wrong channel.

That's why Rootly's engineering team now focuses on something they call the "blast radius." It's not about how many lines of code you changed; it's about what could break if that change goes wrong. A one-line change to a critical payment service has a huge blast radius. A 500-line change to a dashboard's color scheme? Not so much.

Building an AI Reviewer That Asks the Right Question

So Rootly built an internal AI code reviewer. But here's the kicker: it doesn't try to act like a human reviewer. Instead, it asks one question for every PR: "If this change has a bug, which user-facing features will it break?"

That's a fundamentally different approach. Instead of giving a line-by-line critique, the AI reviewer categorizes changes into two buckets: those that alter the system's actual business behavior, and those that only affect performance or UI. Each gets a risk level, and the human reviewer gets a structured report—with a risk score, a confidence score, and a list of specific issues sorted by severity.

It's like having a scout who doesn't just tell you the rapid is Class IV, but also tells you which specific rocks are most likely to flip your boat.

Feature Flags Move the Safety Boundary

Rousseau also highlighted how feature flags have shifted the safety boundary from merge time to release time. Every important feature now ships behind a feature flag, so even after the PR is merged and the code is in production, the feature is off by default. The real review happens during a gradual rollout: first the team, then a small set of customers, then 10% of users, then everyone.

That changes everything. The merge isn't the point of no return anymore. It's just a checkpoint. The real test is when real users hit the feature. So the size of the PR becomes irrelevant—what matters is how you manage the rollout and how quickly you can roll back if something goes wrong.

The Industry Is Catching On

Rootly isn't alone in this thinking. At the 2026 London QCon, Michael Webster talked about headless AI agents and how they're creating bottlenecks in software delivery pipelines. Big AI-generated PRs are overwhelming human reviewers and piling up technical debt.

Rewind, a backup and version control service, built a tool called Diff Vader that borrows Rootly's risk-based review model. They 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 results.

Even Patrick Debois—the guy often called the "DevOps guy"—weighed in at a panel discussion. He argued that PR-based workflows become an anti-pattern inside companies when you're developing at agent speed. PRs make sense in open source, where contributors don't share context and need to build trust. But inside a team with shared goals and context, the PR review cycle is hard to justify when agents are iterating fast.

What This Means for Rafting Teams

So what does all this have to do with rafting? Think about your own team's "PRs"—the changes you make to your equipment, your training, your safety protocols. Maybe you're a guide who's always insisted on small, incremental tweaks to your raft setup. A new paddle here, a different rigging there. That made sense when you were learning, when you needed to understand every detail before committing.

But now, with AI agents writing code, the rules have changed. And for rafting, the lesson is about risk management and adaptation. When you're running a new river, you don't want to make tiny changes that each require a full review. You want to think in terms of the whole run. What's the blast radius if something goes wrong? How quickly can you flip the raft back over? Can you roll back to a safer line?

Rollbacks Beat Faster Reviews

Rousseau's bottom line is this: stop trying to review AI's code faster, and instead bet on rollbacks. That's a mindset shift. Instead of spending hours scrutinizing every line, you make sure you can safely and quickly revert a change if it breaks something in production.

For rafting, it's the same philosophy. You don't spend forever analyzing every ripple before you commit to a line. You practice your rollbacks, you know your escape routes, and you trust that you can recover if you flip. The size of the rapid doesn't matter as much as your ability to handle the consequences.

The New Metric: Blast Radius, Not Line Count

Rootly's team summed it up: "The size of the code change is no longer a useful metric. What matters is the scope of the impact." For rafters, that translates to: don't obsess over the length of the rapid. Pay attention to what could go wrong and how you'd respond.

So next time you're planning a trip, think like Rootly. Skip the small-PR mentality. Focus on the blast radius. And make sure your rollback game is strong.