Why One EdTech Team Dropped Small PRs for AI Code Reviews

The End of a Sacred Rule

For two years, Rootly—an incident management platform—swore by small pull requests. Their engineers stacked PRs, kept atomic changes under a few hundred lines, and believed that smaller diffs were easier to review and roll back. It worked. When humans write code line by line, that discipline makes sense.

But then AI agents started doing most of the writing. And the rule stopped working.

In a recent blog post, Rootly's CTO Quentin Rousseau explained why the company abandoned its long-standing small-PR policy. The reason isn't that small PRs are inherently bad. It's that AI agents think in features, not increments. They produce whole implementations at once—database migrations, models, services, controllers, tests, and frontend components. Forcing that output into tiny, stacked PRs creates chaos, not clarity.

Context Is Everything

Here's the thing about AI-generated code: it's usually technically fine. The bugs are contextual. As Rootly's engineering team put it, "AI-induced bugs are context bugs. The code works, but it's used in the wrong context."

One example from their post: a database migration deleted a field that a background job still called. Another: a service wrote to a table that another team was reading. No syntax errors. No crashes. Just a slow, silent breakage.

For an online education platform, imagine an AI agent updating a course enrollment service. The code runs perfectly in isolation. But it drops a column that the recommendation engine uses on the dashboard. Students see missing suggestions. Nobody gets an error. That's the kind of bug that small PRs were supposed to catch—and they don't anymore.

Why Small PRs Backfire with AI

Rootly actually tried to make AI agents generate stacked PRs. The output had no technical errors, but it was worse from a business context perspective. Reviewing one PR often required looking at another PR to understand the changes. Reviewers had to jump between pages, reconstruct the logic in their heads, and carry a growing mental load.

The small-PR rule was designed for human efficiency. AI broke that efficiency limit, so the rule became overhead. As Rousseau put it, the old rule "turned into extra cost."

Shifting from Lines to Blast Radius

So what did Rootly do? They stopped reviewing AI code like human code. They built an internal AI code reviewer that examines every PR against engineering standards and produces a structured report: risk assessment, normalized score, confidence score, and a list of issues sorted by severity.

But here's the key difference: it doesn't try to act like a human reviewer. Instead, it answers one question: if this change has a bug, which user-facing features break?

The reviewer distinguishes between changes that alter actual business behavior and those that only affect performance or UI. Each gets a different risk level. Human reviewers get a structured reference, not just a raw diff.

This shift—from counting lines to measuring blast radius—is the core lesson for distance education teams. A PR that changes a payment gateway's logic deserves more scrutiny than one that tweaks a button color, regardless of how many lines they touch.

Feature Flags Move the Safety Boundary

Rootly also doubled down on feature flags. Every significant feature now ships behind a flag, defaulted off. The real review happens during progressive rollout: first the team, then a few customers, then 10% of users, then everyone.

That means the safety boundary moved from the merge step to the release step. A PR can be merged and deployed without being fully active. The risk of a bad change is contained by the flag, not by the size of the PR.

For an online course platform, think about launching a new assignment engine. Instead of merging a 50-line PR and hoping it's safe, you merge the whole feature behind a flag, test it with a pilot group, and gradually expand. If something breaks, you flip the flag off. No rollback dance.

Industry Validation and Pushback

Rootly isn't alone. Rewind, a backup and version control service, built a tool called Diff Vader that borrowed Rootly's risk-based model. "A PR's risk has almost nothing to do with the number of lines changed," Rewind's team wrote. Diff Vader assigns a risk label based on review results, not diff size.

At the 2026 London AI Native Developer Conference, a panel including Patrick Debois—often called the father of DevOps—discussed why PR-based workflows become an anti-pattern inside companies once development happens at agent speed. Debois argued that PRs make sense in open source because 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, PR review cycles are hard to justify.

He also noted something practical: AI-generated code costs money. Every token burned shows up on a bill. Inefficiencies that were invisible in pure human development become obvious when you're paying for AI output. That financial pressure is pushing teams toward more standardized, risk-aware processes.

What This Means for Distance Education

Online learning platforms are increasingly using AI agents to build features—from adaptive quizzes to discussion forums. Those teams face the same dilemma Rootly did. If you stick with small PRs, you'll drown in context-switching. If you abandon them entirely, you risk losing control.

The middle path is risk-based review. Instead of asking "how many lines did this change?" ask "what could break if this is wrong?" Then use feature flags to control exposure and roll back fast when something does break.

Rootly's team summarized it well: "The size of a code change is no longer a meaningful metric. What matters is the blast radius of a failure."

For distance education, that means building review processes that focus on user impact. A change to the login flow is riskier than a change to a course description page, no matter how many lines each touches. Review tools should reflect that reality.

Writing PRs That Capture Context

Rootly now asks developers to fill in the "why" and "what" sections of a PR: the motivation, scope, and potential impact. For AI-generated PRs, the human using the agent writes these. Rootly explicitly tells AI assistants not to generate this content, because the goal is to capture context—why this change, why now, what business need does it serve.

Every PR must also describe how to roll back safely, including any necessary data fixes. That's not just good practice; it's a survival skill when agents are writing code at scale.

Rousseau admitted that killing the small-PR rule felt uncomfortable at first. It had seemed so right. But it was necessary to support the real goal: "fast delivery of reliable software."

In a separate post, he expanded on this shift toward production-side safety. The title says it all: "Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead."

The Takeaway for EdTech Teams

If your team is using AI agents to build features, take a hard look at your PR review process. Are you still measuring lines of code? Are you forcing AI output into human-sized chunks? If so, you're probably creating more work, not less.

• Switch from size-based metrics to risk-based ones.
• Use feature flags to move the safety boundary to release time.
• Make PR descriptions capture business context, not just technical changes.
• Build or adopt review tools that assess blast radius, not diff size.
• Accept that small PRs were a human-era rule. AI changes the game.

The future of software delivery—especially in fast-moving fields like distance education—belongs to teams that can review AI code effectively. That means letting go of rules that no longer serve you and embracing tools that focus on what actually matters: preventing production incidents.

As Rootly's team concluded, small PRs made sense when everyone wrote code by hand. But when you're dispatching AI agents to deliver complete features, that model breaks. The teams that adapt will ship faster and break less. The ones that don't will drown in review cycles and technical debt.