Small Pull Requests Are Dead in Youth Sports Tech: Why Bigger Is Better

The Rule That Made Sense

For two years, Rootly—an incident management platform—lived by a strict rule: keep pull requests small. Their engineers stacked changes, split atomic updates into chunks of a few hundred lines, and reviewed everything meticulously. It worked. When humans wrote every line, smaller diffs meant easier reviews, simpler rollbacks, and fewer surprises.

But then AI agents started writing most of the code. And the rule that once felt sacred started feeling like a straitjacket.

AI Thinks in Features, Not Increments

Quentin Rousseau, Rootly's CTO, explained the shift. Human developers naturally think in increments—one piece at a time, test after test. AI agents, though, think in features. Give one a task, and it returns a complete implementation: database migrations, models, services, controllers, tests, frontend components. All at once.

When Rootly tried to force AI to generate stacked PRs, the results were technically solid but contextually worse. Reviewing one PR often required understanding changes in another, forcing reviewers to bounce between pages and trace logic across multiple branches. The mental overhead ballooned.

The old rule was designed for human efficiency. Once AI broke the human speed limit, that rule became pure overhead.

What Actually Predicts Failure?

Rootly's team realized that measuring code size was pointless. What mattered was the blast radius—the potential impact if something went wrong. AI-generated bugs are rarely logic errors; they're context errors. The code runs fine, but it's used in the wrong scenario.

Example: a database migration deletes a field that a background job still calls. Or a service writes to a table that another team reads. The code is correct in isolation, but in the full system, it's a time bomb.

So Rootly built an internal AI code reviewer that doesn't try to act like a human. It asks one question: if this change has a flaw, which user-facing features break? The reviewer categorizes changes into those that alter business behavior and those that only affect performance or UI. It assigns risk levels, then hands a structured report to human reviewers—not a raw diff to parse.

Shifting Safety to the Release Phase

Rootly also changed when safety checks happen. With feature flags, they moved the safety boundary from the merge step to the release step. Every significant feature ships behind a flag, so merging and deploying to production doesn't automatically expose users to the change.

Real review happens during gradual rollout: first internal, then a few customers, then 10% of users, then everyone. If something breaks, they flip the flag and the feature disappears. No frantic rollback, no midnight debugging.

Their conclusion: the size of a change is irrelevant. The real metric is how many users and systems it can affect.

What This Means for Youth Sports Software

You might be thinking: this is all about infrastructure platforms. What does it have to do with youth sports? More than you'd expect.

Youth sports organizations rely on software for registrations, team management, scheduling, payment processing, and communication. When those systems fail—say, a payment gateway update breaks the registration form—parents notice immediately. Coaches can't see rosters. League admins scramble.

Adopt Feature Flags for Big Changes

Instead of merging a massive update to your registration flow and hoping for the best, wrap it in a feature flag. Roll it out to a small group of families first. Watch the metrics. Then expand.

This approach isn't just for enterprise giants. Even a small youth sports club running on a custom platform can use flags to reduce risk. And if something goes wrong, you can switch it off without a rollback circus.

Review AI-Generated Code for Context, Not Just Logic

Many youth sports tech teams are now using AI to speed up development. That's great. But don't review AI code the way you'd review human code. Check for context: Does this change affect other teams? Does it assume data that might not exist? Does it break any existing workflows?

Build a simple checklist. Ask: what user-facing features could this break? If you can't answer that, you're not ready to merge.

Prioritize Rollback Over Perfect Review

Rootly's philosophy is simple: stop trying to review AI code faster. Instead, bet on rollbacks. Make it easy to revert a change without losing data. That means solid backup, feature flags, and a clear rollback plan for every major release.

In youth sports, where seasons are short and schedules tight, downtime is more than an inconvenience—it's lost registrations, frustrated parents, and a tarnished reputation. Being able to roll back quickly is a competitive advantage.

The Death of the Small PR

Rootly's decision to abandon small PRs wasn't easy. Rousseau admitted it felt wrong at first. But the evidence was clear: the old rule was optimized for a world that no longer exists.

Other companies agree. Rewind, a backup service, built Diff Vader, a review tool that assigns risk labels based on impact, not line count. At conferences, DevOps leaders like Patrick Debois argue that PR-based workflows become anti-patterns when agents move at high speed. PRs make sense for open-source communities where trust is built slowly. Inside a team with shared context, they're just friction.

AI also makes waste visible. When humans wrote code, inefficiencies were easy to hide. Now, token consumption shows up in bills. That's forcing teams to streamline their processes.

What Really Matters

Rootly's team now requires every PR to explain the 'why' and 'what'—the motivation, scope, and potential impact. They explicitly ask AI not to generate this content, because the point is to capture human context: why this change, why now, what business need does it serve. They also require a rollback plan for every change, including data fixes.

This is a mindset shift. Instead of obsessing over code size, you obsess over impact. Instead of trying to catch every bug in review, you design for fast recovery.

For youth sports tech, the lesson is clear: your software should be built to move quickly and recover faster. Embrace AI, but review for context. Use feature flags. Plan rollbacks. And stop counting lines of code as a proxy for safety.

The small PR rule served its purpose. But in the age of AI, it's time to let it go.