Why Cruise Lines Are Ditching Small Pull Requests for AI-Driven Code

The Rule That Made Sense

For two years, Cruise Lines ran a strict small-pull-request culture. Every change had to be atomic, stacked, and limited to a few hundred lines. The logic was simple: when humans write code by hand, small diffs are easier to review and safer to roll back. It worked. It felt right.

But something shifted. AI agents started writing most of the code. And the old rule began to feel like a relic.

AI Thinks in Features, Not Increments

Quentin Rousseau, co-founder and CTO of Cruise Lines, explained the turning point in a recent blog post. AI agents don't think in small increments. They think in features. When you ask an agent to build something, it doesn't produce a tiny patch. It produces the whole thing—database migrations, models, services, controllers, tests, and frontend components—all in one shot.

That's not a bug. It's just how the tools work. And it changes everything about how you review code.

The Context Trap

Here's the scary part: AI-generated bugs aren't syntax errors. The code runs fine. It just gets used in the wrong context. Cruise Lines' engineering team saw a database migration delete a field that a background job still called. Another service wrote to a table that another team was reading. The code was technically correct. It was just wrong in context.

Small PRs don't catch that kind of problem. In fact, they make it worse.

When Stacked PRs Backfire

At first, Cruise Lines tried to force AI agents to generate stacked pull requests. It was a disaster. The code wasn't technically broken, but it made no sense from a business perspective. Reviewers had to jump between multiple PRs just to understand one comment. They'd open one page, then another, then a third, trying to piece together the logic. The mental load was brutal.

The team finally realized the truth: small PRs were designed for human coding efficiency. AI broke that assumption. Now the rule was just overhead.

A New Way to Review

So Cruise Lines stopped reviewing AI code the way you'd review human code. They built an internal AI code reviewer. It examines every PR against engineering standards and produces a structured report—risk assessment, standardized score, confidence score, and a list of specific issues sorted by severity.

The key difference? It doesn't try to act like a human reviewer. It asks one question: if this change has a defect, what user-facing feature breaks?

Risk Over Line Count

The AI reviewer separates changes that alter actual business behavior from changes that only affect performance or UI. It assigns different risk levels to each. That gives human reviewers a structured reference, not just a raw diff to stare at.

Rousseau is clear: the size of a code change no longer matters. What matters is the blast radius—the scope of what could go wrong.

Feature Flags Move the Safety Boundary

Cruise Lines now uses feature flags for every important feature. When a PR is merged and code hits production, the feature is off by default. The real review happens during gradual rollout: first the team enables it internally, then a small set of customers, then 10% of users, and finally everyone.

That shifts the safety boundary from the merge step to the release step. Merging is no longer the scary moment. Releasing is.

What the Industry Is Saying

Cruise Lines isn't alone. At the 2026 London QCon, Michael Webster talked about headless AI agents and how they're bottlenecking human reviewers. He mentioned that large AI-generated PRs pile up persistent technical debt.

Rewind, a backup and version control company, built a tool called Diff Vader that borrows Cruise Lines' risk-based model. Their team wrote that a PR's risk has almost nothing to do with its line count. Diff Vader assigns a risk label based on review results, not diff size.

Even Patrick Debois—often called the DevOps father—joined a panel at the AI Native Developer conference in June 2026. He argued that PR workflows become an anti-pattern inside companies once agents move at their own speed. PRs make sense in open source, where contributors need to build trust. But inside a team with shared context and goals, the review cycle is hard to justify when agents iterate fast.

Debois also pointed out something practical: AI token costs are forcing teams to formalize their processes. In the old days, inefficiency in a human pipeline was invisible. Now every wasted call shows up on the bill.

What Cruise Lines Does Now

Cruise Lines asks two questions in every PR: why and what. Developers have to explain the motivation, scope, and potential impact of the change. For AI-generated PRs, the human who used the agent fills these out. Cruise Lines explicitly tells its AI assistants not to generate these sections, because the goal is to capture context—why this change, why now, what business need it serves.

Every PR also has to describe how to roll back safely, including any necessary data fixes.

Letting Go of a Rule That Felt Right

Rousseau admits that killing the small-PR rule was uncomfortable. It had been a pillar of their process for two years. It felt right. But it wasn't serving them anymore.

In a companion post, he put it bluntly: stop trying to review AI's code faster. Bet on rollbacks instead. That's the shift—from trying to catch every issue in review to making it cheap and safe to undo a bad change.

The Bottom Line

In a world where humans wrote every line, small PRs were the optimal pattern. They made review manageable and rollbacks simple. But now that teams are orchestrating AI agents to ship complete features, that pattern is obsolete.

Cruise Lines' move away from small PRs isn't just a change in workflow. It's a recognition that code review is no longer about line counts. It's about understanding risk, protecting user-facing features, and being ready to roll back fast when something goes wrong.

For any team still clinging to the small-PR rule, it might be worth asking: is this rule helping us ship reliable software, or is it just something we've always done?