Why Your Hobby Project's Pull Requests Might Be Too Small

The End of the Small PR Era

If you've spent any time coding as a hobby, you've probably heard the golden rule: keep your pull requests small. Break changes into tiny, reviewable chunks. Stack them. Stay under a few hundred lines. That advice made sense when humans wrote every line. But Rootly, an incident management platform, just announced they're throwing that rule out the window. Their reason? AI agents now write most of their code, and the old metric—lines of code—no longer tells you anything useful.

What Rootly Did

For two years, Rootly enforced a strict small-PR culture. Quentin Rousseau, co-founder and CTO, explained that they required stacked PRs and atomic changes capped at a few hundred lines. When humans hand-coded everything, smaller diffs were easier to review and safer to roll back. Then AI agents came along. These agents think in terms of features, not increments. They spit out entire implementations in one go—database migrations, models, services, controllers, tests, frontend components. Suddenly, the small-PR rule became a bottleneck, not a safety net.

What's Wrong with AI-Generated Code?

The problem isn't that AI code is broken. It's that AI code can be contextually wrong. Rootly's engineering team gave a concrete example: a database migration deleted a field that a background job still called, or a service wrote to a table another team was reading. The code runs fine—it just does the wrong thing in the wrong situation. That's a context bug, not a syntax error.

When they tried to force AI agents to produce stacked PRs, the results were technically correct but worse from a business perspective. Reviewers had to jump between multiple PRs to understand one change. Comments on one PR depended on fixes in another. The mental load became unbearable.

Blast Radius Over Line Count

Rootly's shift is simple: stop measuring the size of a change and start measuring its blast radius. How many user-facing features could break if this change goes wrong? That's the real question. They built an internal AI code reviewer that evaluates every PR against engineering standards. It doesn't try to act like a human reviewer. Instead, it answers one question: if this change has a flaw, what breaks?

The AI reviewer sorts changes into two buckets: those that alter actual business behavior and those that only affect performance or UI. Each gets a risk level. Human reviewers get a structured report—risk assessment, standardized score, confidence score, and a list of issues by severity. No more staring at a raw diff.

Feature Flags Move the Safety Line

Rousseau emphasized that feature flags have moved the safety boundary from merge to release. Every important feature ships behind a flag, default off. When a PR merges and code hits production, nothing changes for users. The real review happens during gradual rollout: first the team, then a few customers, then 10% of users, then everyone. If something breaks, you flip the flag. Rollback is instant.

That's a lesson for hobbyists too. If you're building a side project, feature flags might feel like overkill. But even a simple toggle can save you from a late-night debugging session. The point is to reduce the cost of a mistake, not to prevent mistakes entirely.

The Industry Is Catching On

Rootly isn't alone. At the 2026 QCon London, Michael Webster talked about headless AI agents and how they're straining software delivery pipelines. Large AI-generated PRs create bottlenecks for human reviewers and pile up technical debt. Rewind, a backup service, adopted a similar risk-based review model. Their tool, Diff Vader, assigns a risk label to each PR based on review findings, not line count. As Rewind's team put it, the risk of a PR has almost nothing to do with how many lines it changes.

The PR Workflow Under Attack

Even the PR workflow itself is being questioned. At a 2026 AI-native developer conference in London, a panel featuring Patrick Debois—often called the father of DevOps—argued that PR-based workflows become an anti-pattern inside companies developing at agent speed. Debois said PRs make 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 iterate quickly, the PR review cycle is hard to justify.

There's also a cost angle. AI agents burn tokens, and those tokens show up on bills. Inefficiencies that were invisible in human-only development are now quantifiable. Waste costs money, and that forces teams to formalize their processes.

What This Means for Your Hobby Project

You might be thinking, "I'm just building a little app for fun. This doesn't apply to me." But there's a nugget here for any hobbyist who writes code, whether you're maintaining a blog, building a game, or automating your smart home. The old advice about small PRs was about managing risk and review load. If you're the only reviewer, you can skip the ceremony. But the principle—know what could break and have a rollback plan—still holds.

Here's what you can steal from Rootly:

• Stop counting lines. Count impact. What does this change touch?
• Write a short note explaining why you're making the change and what could go wrong.
• If you can, ship behind a flag. Even a simple boolean can save your weekend.
• Plan your rollback before you merge. What's the undo button?

Rootly now requires every PR to include a "why" and "what" section. Developers explain the motivation, scope, and potential impact. They explicitly tell AI assistants not to generate these sections, because the goal is to capture human context. And every PR must describe how to safely roll back, including any data fixes.

The Bottom Line

Rousseau admitted that killing the small-PR rule felt wrong at first. It had served them well. But the goal is to deliver reliable software quickly, and the old rule was getting in the way. In a separate essay, he went further, arguing that trying to review AI code faster is a losing game. Better to bet on rollbacks.

So the next time you're tempted to split your hobby project's change into ten tiny PRs, ask yourself: is this making things safer, or just adding overhead? For a solo project, the answer is probably the latter. Focus on what matters—knowing what could break and having a plan to fix it. That's a skill worth practicing, whether you're coding for work or for fun.