The Core Shift
Rootly, an incident management platform provider, says it has abandoned its long-standing rule that pull requests should stay small. The company argues that the rule made sense when humans wrote most code by hand, but it no longer fits a workflow where AI agents can generate complete features in one pass.
For the past two years, Rootly had enforced a strict small-PR culture: stacked pull requests, atomic changes, and diffs limited to a few hundred lines. Co-founder and CTO Quentin Rousseau explained that smaller diffs were easier for humans to review and roll back. AI agents, however, tend to work at the level of features rather than increments, producing database migrations, models, services, controllers, tests, and frontend components together.
Context Bugs, Not Just Code Bugs
Rootly’s engineering team describes many AI-related defects as context bugs: the code runs, but it is applied in the wrong system or business context. A migration might remove a field still used by a background job, or a service might write to a table that another team depends on.
The company tried asking AI agents to generate stacked pull requests, but found that the result increased review complexity. Individual PRs could look technically correct, while the overall feature became harder to reason about. Reviewers had to jump between related PRs to understand cause and effect. Rootly concluded that the small-PR rule was designed to optimize human coding limits; once AI changed those limits, the rule became an added cost.
Reviewing for Blast Radius
Rootly has built an internal AI code reviewer that checks each PR against engineering standards and produces a structured report with risk assessment, standardized scoring, confidence scoring, and issues grouped by severity.
The tool is not meant to imitate a human reviewer. Instead, it asks one question: if this change is wrong, which user-facing capabilities could it break? It distinguishes changes that alter business behavior from those that mainly affect performance or interface presentation, then assigns risk accordingly. The key metric is no longer lines changed, but blast radius.
Rootly has also shifted safety from merge time to release time. Important features are shipped behind feature flags, which allow teams to enable or disable functionality without redeploying code. After code reaches production, a feature stays off by default, then rolls out progressively: first internally, then to a small customer group, then to 10% of users, and finally to everyone.
A Wider Industry Debate
The same concern is appearing elsewhere. At QCon London 2026, Michael Webster discussed how headless AI agents affect software delivery pipelines, warning that large AI-generated pull requests can turn human review into a bottleneck and create persistent technical debt. Rewind has also said its Diff Vader review tool borrows from Rootly’s risk-based model, assigning risk labels rather than judging PRs by line count.
At the AI Native Dev conference in London in June 2026, participants including Patrick Debois discussed why PR-based workflows may become an anti-pattern inside companies when development happens at agent speed. PRs still matter in open source, where trust and alignment must be built gradually. But in internal teams with shared goals and context, long review cycles are harder to justify. AI also makes process waste more visible because token consumption can be measured and billed.
What Comes Next
Rootly’s change does not mean code review disappears. It means review shifts from reading smaller diffs to managing production risk. Teams using AI agents will need clearer business context, feature flags, staged rollout, monitoring, and rollback plans. The practical lesson is not simply to accept huge PRs, but to ask better questions: who could be affected, how will the change be released, and how can it be safely reversed?