Why Small Pull Requests Died in the Age of AI Agents: A Lesson for Painters

The End of an Era: Small PRs and Small Strokes

For years, the software world swore by small pull requests. The logic was simple: small changes are easier to review, easier to test, and easier to roll back. It was a discipline that kept codebases healthy and human brains from melting under the weight of massive diffs. Rootly, an incident management platform, embraced this wholeheartedly. They enforced stacked PRs, atomic changes, and capped every pull request at a few hundred lines. It felt right. It was right—for a world where humans wrote every line.

But here's the thing: that world is gone. AI agents now write most of the code. And Rootly, after two years of strict small-PR enforcement, threw the rule out. Their reasoning? AI agents don't think in increments. They think in features. When an agent builds a feature, it outputs the whole thing: database migrations, models, services, controllers, tests, and frontend components—all in one shot. Reviewing that as a series of tiny PRs is like trying to appreciate a mural by looking at one-inch squares.

The Painter's Parallel: From Brushstrokes to Composition

There's a lesson here for painters, and it's not a stretch. Think about how you approach a canvas. If you're classically trained, you might start with a sketch, then block in values, then add color, then refine details. Each step is small, deliberate, and controllable. That works when you're the only one painting. But what if you had an AI assistant that could generate an entire composition in one go—sky, figures, lighting, texture? Would you still insist on painting it in tiny sections? Probably not. You'd want to see the whole piece, assess its impact, and then decide where to intervene.

That's exactly the shift Rootly describes. They tried to make AI agents produce stacked PRs, and the result was technically correct but contextually worse. Reviewers would look at one PR and find comments that depended on changes in another PR. They'd have to flip between pages, trace logic across multiple diffs, and their mental load skyrocketed. The small-PR rule, designed for human efficiency, had become a bottleneck.

Context Is Everything: The Nature of AI Bugs

Rootly's engineers noticed something crucial: AI-generated bugs are context bugs. The code runs fine—it just gets used in the wrong scenario. One example they cite: a database migration deletes a field that a background job still calls. Another: a service writes to a table that another team is reading. The code itself isn't broken; it's misapplied.

This is a profound insight for painters, too. When you're working on a piece, you might have a technique that works in isolation—a certain brushstroke, a particular glaze—but fails when placed in the context of the whole composition. The stroke is fine; it's the placement that's wrong. Similarly, you can't judge a painting by the size of its brushstrokes. A tiny stroke might be perfect, or it might be a disaster. What matters is how it interacts with everything else.

Enter the AI Reviewer: A New Way to Assess Risk

Rootly's solution was to stop reviewing AI code the way they reviewed human code. They built an internal AI code reviewer that examines every PR against engineering standards and produces a structured report: risk assessment, standardized score, confidence score, and a list of specific issues sorted by severity. But here's the key: it doesn't try to play human reviewer. Instead, it asks one question: if this change has a bug, what user-facing features will it break?

That's a game-changer for painters, too. Instead of asking, "Does this brushstroke look good?" you might ask, "If this element fails, what part of the painting suffers?" It's a shift from aesthetics to impact. You're not judging the stroke in isolation; you're judging its blast radius.

The AI reviewer also distinguishes between changes that alter system behavior and those that only affect performance or appearance. Each gets a different risk level. For painters, this is like separating compositional changes (which shift the meaning of the piece) from technical changes (which affect how the paint behaves). A change in color palette might be high-risk, while a change in brush type might be low-risk. The reviewer gives you a structured way to think about what matters.

Feature Flags: The Safety Net That Changes Everything

Rootly also shifted their safety boundary from "merge" to "release." Now, every important feature ships behind a feature flag. When a PR is merged and code goes to production, the feature is off by default. The real review happens during progressive rollout: first internal, then a small group of customers, then 10% of users, then everyone.

For painters, this is like painting a draft, showing it to a few trusted eyes, then to a gallery audience, and only then to the public. You don't have to get it perfect before you share it. You can test the waters. The old model was: paint in small sections, review each section, then assemble. The new model: paint the whole thing, hide it behind a curtain, and reveal it gradually. If something's wrong, you can pull the curtain back.

The Death of Lines of Code as a Metric

Rootly's team is blunt: "The size of a code change is no longer a useful metric. What matters is the scope of impact." That's a radical statement. For decades, we measured productivity by lines of code, and review quality by the size of the diff. Now, that's meaningless. A one-line change could take down the entire service; a thousand-line change could be trivial.

Painters, too, have long been obsessed with the size of brushstrokes. The Impressionists were criticized for their loose, visible strokes, while the Academic painters favored smooth, invisible ones. But the size of the stroke doesn't determine the quality of the painting. A tiny stroke can be the focal point; a huge one can be background noise. What matters is the impact on the whole.

The Industry Is Catching On

Rootly isn't alone. Rewind, a backup and version control company, recently said their code review tool, Diff Vader, borrows Rootly's risk-based model. They argue that a PR's risk has almost nothing to do with its line count. Instead, they assign a risk label based on the review, not the size.

At the AI Native Developer Conference in London, Patrick Debois—often called the father of DevOps—joined a panel discussing why PR workflows become an anti-pattern when agents develop at high speed. Debois noted that PRs make sense in open source, where contributors need to build trust. But inside a team with shared context and goals, when agents iterate quickly, the PR review cycle becomes hard to justify.

For painters, this is a warning against rigid processes. If you're working alone, you might not need a formal review process at all. But if you're collaborating with AI or other artists, you need to adapt. The old rules—like "always work in small sections"—might not serve you anymore.

What Really Predicts Failure? Ask Better Questions

Rootly's new philosophy is to ask questions that actually predict production incidents. Their PR template now requires developers to write "why" and "what" sections: the motivation for the change, its scope, and its potential impact. For AI-generated PRs, the human using the agent fills these in. They explicitly tell AI not to generate this content, because the goal is to capture context: why this change, why now, what business need does it serve. And every PR must describe how to safely roll back, including any necessary data fixes.

This is a beautiful lesson for painters. Before you make a drastic change to a painting, ask yourself: why am I doing this? What am I trying to achieve? What could go wrong, and how would I fix it? It's not about avoiding mistakes; it's about being prepared for them.

The Uncomfortable Shift: Letting Go of What Feels Right

Rousseau admits that abolishing the small-PR rule was uncomfortable. It had felt so correct for so long. But to support "fast delivery of reliable software," it was necessary. He elaborates in another post titled "Stop Trying to Review AI's Code Faster: Bet on Rollbacks Instead." The emphasis is on production safety, not on review speed.

For painters, this might mean letting go of the "small strokes" mentality. It might feel safer to work in tiny increments, but that safety is an illusion. The real safety comes from understanding the whole composition, from being able to step back and say, "If this fails, what breaks?" It's about building a safety net, not about limiting your brushwork.

Conclusion: The New Rule Is No Rule

In the end, Rootly's team sums it up: when everyone wrote code by hand, small PRs were the best practice. But now that teams orchestrate AI agents to deliver complete features, that practice is obsolete. The same applies to painting. When you're painting by hand, small strokes might be necessary. But when you're working with AI that can generate entire compositions, you need to think in terms of features, not increments.

So, next time you're about to critique a painting—or a pull request—ask yourself: what's the blast radius? What would break if this element failed? And remember, the size of the stroke doesn't matter. What matters is the impact.