Sailing into the Future: How AI Is Changing the Way We Review Code in Yacht Racing Software

From Small PRs to Big Waves

For years, software teams building sailing and yacht racing platforms have lived by the small pull request (PR) rule. Keep changes tiny, keep them atomic, and you can review them quickly and roll them back without capsizing the whole system. It made sense when humans wrote every line by hand. But the wind has shifted. AI agents now write most of the code, and that old rule is starting to feel like an anchor dragging on the keel.

Rootly, an incident management platform, recently explained why it abandoned its own small PR rule. The company's engineers found that AI agents think in features, not increments. A single agent can produce a complete implementation—database migrations, models, services, controllers, tests, and frontend components—in one go. That's like a crew that can hoist every sail, trim every sheet, and navigate the course in a single maneuver. But when you try to chop that into a series of stacked PRs, you end up with a tangled mess.

The Context Problem

AI-generated bugs are context bugs. The code runs fine—it just gets used in the wrong scenario. Rootly's team gave a concrete example: a database migration deleted a field that a background job still called, or a service wrote to a table that another team was reading. In sailing terms, it's like setting the spinnaker for a downwind leg when the wind has shifted to a beat. The sail works, but it's the wrong sail for the moment.

When Rootly tried to force AI agents to produce stacked PRs, the result was technically correct but contextually worse. Reviewers had to jump between multiple PRs to understand the full picture. Comments on one PR often depended on changes in another, forcing reviewers to flip through pages and trace logic across screens. It was like trying to read a chart while the boat is heeled over and spray is flying—pure mental overload.

Reviewing AI Code Differently

Rootly realized they were still reviewing AI code the way they reviewed human code. That had to stop. They built an internal AI code reviewer that doesn't try to imitate a human reviewer. Instead, it answers one question: if this change has a bug, which user-facing features break? It categorizes changes by whether they alter actual business behavior or just affect performance or UI presentation, then assigns risk levels accordingly. The result is a structured report with risk assessments, standardized scores, confidence scores, and a list of specific issues sorted by severity.

This is a shift from reviewing raw diffs to reviewing risk. It's like a race committee that stops measuring each sail's area and instead asks: if this sail rips, how many boats will be affected? The answer changes how you plan the race.

Feature Flags and Rollbacks

Rootly now relies on feature flags to move the safety boundary from merge time to release time. Every important feature ships under a feature flag, defaulted off. When a PR merges and code goes to production, nothing changes for users. The real review happens during progressive rollout: first the feature is enabled for the team, then for a small group of customers, then 10% of users, and finally everyone. If something goes wrong, you flip the flag and roll back instantly.

This approach makes PR size irrelevant. What matters is the blast radius—how many users and features could be affected. Rootly's engineers put it bluntly: code size is no longer a useful metric; the real metric is failure impact scope.

Industry Momentum

Rootly isn't alone. Rewind, a backup and version control service, built a code review tool called Diff Vader that borrows Rootly's risk-based model. Rewind's team wrote that a PR's risk has almost nothing to do with line count. Diff Vader assigns a risk label based on review results, not change size.

The topic of agent-driven pull requests is hot in industry events. At a 2026 London AI-native developer conference, a panel including Patrick Debois—often called the father of DevOps—discussed why PR workflows become an anti-pattern in enterprises once agents reach full speed. Debois argued that PRs make sense in open source, where contributors may not share strategic direction and need to build trust gradually. But inside a team with shared context and goals, when agents iterate quickly, the PR review cycle becomes hard to justify.

Panelists also noted that AI's costs are forcing process standardization. In the old human-only days, inefficiencies in the pipeline were hard to see. Now, with AI, every wasted token shows up as a line item on the bill. It's like a sailing team that suddenly has a fuel gauge on the whole regatta—you can't ignore the excess anymore.

What Makes a Good PR Now

Rootly now asks questions that actually predict production incidents. The PR's "why" and "what" sections require developers to explain the motivation, scope, and potential impact. For AI-generated PRs, the human using the agent fills these in. Rootly explicitly tells AI assistants not to generate these sections, because the goal is to capture context: why this change, why now, what business need does it serve. Each PR must also describe how to roll back safely, including any necessary data fixes.

This is a shift from reviewing code to reviewing intent. In sailing, it's like a skipper who doesn't just look at the sail trim but asks: why did we set this sail, and what's our plan if the wind shifts?

Letting Go of the Old Rule

Quentin Rousseau, Rootly's co-founder and CTO, admitted that abandoning the small PR rule was uncomfortable. It had felt right for so long. But to support the goal of "delivering reliable software fast," it had to go. He elaborated on this shift in another article titled "Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead."

The bottom line is this: in the era of all-human code, small PRs were the best practice. But now that teams are dispatching AI agents to deliver full features, that practice no longer applies. For sailing software developers, the lesson is clear: focus on the blast radius, lean on feature flags, and make rollbacks your safety net. That's how you keep the boat upright when the AI winds pick up.