From small pull requests to blast radius: AI changes the rules
AI code review automation is the use of autonomous coding agents and models to generate, inspect, and approve code changes at scale, shifting software teams from line-by-line diff scrutiny toward risk-based decisions about deployment safety, rollback strategy, and overall system impact rather than manual micro-edit checking.
Rootly’s decision to drop its long‑standing small pull request rule is a clear sign that the economics of code review have changed. For two years, the company enforced stacked PRs with atomic changes capped at a few hundred lines because human-written code was easier to review and revert when broken into small diffs. Once AI agents began generating most of its code, that premise fell apart. These agents think in features, not increments, producing end‑to‑end implementations with migrations, models, services, controllers, tests, and UI in one sweep. Forcing those outputs into tiny PRs led to tangled context and reviews spread across tabs instead of clearer safety. Rootly concluded that the small‑PR rule had been optimized for human writing speed and had become plain overhead in an agentic AI development world.
The company responded by changing what it optimizes for. Instead of gatekeeping PR size, it focuses on blast radius: how much can go wrong if this change ships. That mindset prioritizes feature flags, rollbacks, and runtime safeguards over counting lines. Rootly even built an internal AI code reviewer that evaluates every PR against engineering standards and outputs a structured assessment, including risk level, standardization score, confidence, and findings by severity. Pull request automation is no longer about slowing code to human speed; it is about using agents to spot structural risks while humans concentrate on whether the change is worth deploying at all.
Honk at Spotify: codebase migration agents as infrastructure
Spotify’s Honk shows what happens when agentic AI development is treated as infrastructure rather than a developer sidekick. Built to address what its engineers call the maintenance problem, Honk is a background coding agent designed to “rewrite all of our codebase all the time” by owning fleet‑wide migrations. The problem is simple to describe and painful to live with: developers spend less than one hour per day writing code, and a large part of that hour disappears into dependency bumps, framework upgrades, and platform‑driven refactors instead of new features.
Before large language models were involved, Spotify’s fleet management system already automated part of this work. Platform teams wrote scripts that targeted thousands of Java components, and the system would clone each repository, apply a transformation, and open a pull request for code owners to review. This pull request automation shrank the time for 70% of the fleet to adopt a new internal service framework version from almost a year to under a week. That is a quotable shift: “Before we had fleet management, it would take us almost a year… With fleet management in place, we’re down to just under a week.”
The long tail remained stubborn. Scripts failed on edge cases and complex architectural coupling. Adding more logic meant wrestling with abstract syntax trees until only one engineer truly understood the migration script. Here Honk enters as a codebase migration agent: instead of hand‑coding every rule, an LLM-based agent reasons about diverse codebases, different build systems, and context‑dependent changes, wrapped as a CLI that can run across the entire fleet. The story is not about flashy AI demos; it is about turning repetitive, error‑prone maintenance into an always‑on background process that frees developers to work on system design rather than chase yet another logging framework upgrade.
Linux kernel: AI makes supersized updates the new normal
At the other end of the spectrum, the Linux kernel shows what happens when AI code review automation collides with one of the most conservative, process‑driven projects in software. Linus Torvalds recently described a release candidate as “huge,” calling it the biggest rc6 in years by commit count. A week later he was still worried about the size of rc7, but blunt about why: “the new normal with a lot of fixes, many of them due to review by various AI tools”.
This is not about monolithic changes slipping through; Torvalds stresses that most of the fixes are small, spread across drivers, filesystems, networking, and architecture code. But the aggregate effect is undeniable: AI‑assisted review and contribution pipelines swell the number of acceptable patches. Instead of acting as a hard brake, maintainers are adjusting to higher throughput. Torvalds says he is not thrilled about the size yet still expects the Linux 7.2 release next weekend unless a serious issue appears. In other words, release cadence is holding while commit volume grows, powered by AI tools that now sit in the review loop rather than at its edges.
This “new normal” comes with trade‑offs. Torvalds has previously criticized poor AI‑generated contributions and the flood of near‑duplicate bug reports. But he has also made it clear that the project is not anti‑AI and is open to machine‑made patches. The lesson for other teams is sharp: once AI agents join your review process, you will likely see more, smaller fixes rather than fewer, larger ones. The real adaptation is not deciding whether AI belongs, but redesigning review and triage processes so that human attention targets the few risky areas hidden inside a sea of automated changes.
Risk, not lines of code: how review standards are being rewritten
Across Rootly, Spotify, and the Linux kernel, a common pattern appears: AI agents are taking over the complex, large‑scale code changes that used to demand painstaking manual review, and teams are redefining what “good” code review looks like in response. Rootly’s experience is blunt on this point. Its engineering team notes that AI agents produce feature‑complete implementations, often with migrations and cross‑service effects bundled into one output, turning AI bugs into context bugs where technically correct code is applied to the wrong place. Trying to force these outputs into stacked, tiny PRs not only wasted time but produced worse context and more mental gymnastics.
Instead, Rootly stopped treating AI like a junior engineer that needed smaller tasks. It built an AI reviewer that rates every PR’s risk and consistency with internal standards, and uses that to decide where humans must dive deeper. Another company, Rewind, has followed this risk‑based model with its own tool, Diff Vader, which assigns a risk label to each PR based on review findings rather than line count. This is a direct rejection of the old small‑PR dogma: a 50‑line change can be higher risk than a 500‑line one if it touches fragile parts of the system.
The broader implication is that AI code review automation changes incentives. When agents can generate and revise code across services and repositories, the bottleneck moves from typing speed to decision‑making. The right question is no longer “Is this PR small enough to review in ten minutes?” but “What is the blast radius if this agentic AI development path is wrong, and do we have safe rollbacks?” Rootly’s own CTO closes by arguing that killing the small‑PR rule, though uncomfortable, was necessary to support the goal of shipping reliable software quickly, and he points readers toward a separate argument: stop trying to review AI code faster and bet on rollback safety instead.
What developers should do next: work with agents, not against them
Taken together, these stories show that AI agents are not a marginal productivity boost; they are reshaping how teams think about ownership, review, and long‑term maintenance. Spotify’s Honk started as a replacement for brittle scripts but evolved into a fleet‑level codebase migration agent, built as a CLI capable of handling many build systems and repositories at once. Rootly’s AI reviewer shifted the review conversation from PR size to risk profiles and production safeguards. Linux kernel maintainers, meanwhile, are learning to live with supersized release candidates filled with AI‑assisted fixes while still shipping on schedule.
For developers, the uncomfortable conclusion is that traditional gatekeeping practices—small‑PR rules, “no big diffs” slogans, and human‑only review requirements—will continue to erode. Agentic AI development means agents think in features and fleets; humans must move up a level to think in systems and outcomes. Teams that cling to line‑count heuristics will drown in overhead, while those that invest in feature flags, automated rollbacks, and risk‑aware pull request automation will see their review standards evolve instead of break. The tools are already here; the question is whether teams will adapt their processes as decisively as the code their agents now rewrite.
