Devin's Stacked PRs Feature Explained: Automatically Splitting Large Tasks into Reviewable PR Stacks

Devin's New Capability: Automatically Splitting Large Tasks into Stacked PRs

AI software engineer Devin recently launched a new feature called Stacked PRs (Stacked Pull Requests). The core value of this feature is that Devin can now automatically break down large development tasks into a series of small, independently reviewable PRs, while automatically handling rebase, conflict resolution, and CI validation across the entire PR stack.

For any engineer who has dealt with large code changes, the significance of this feature is immediately apparent. A PR involving dozens of files and thousands of lines of changes often turns Code Review into a disaster—reviewers struggle to focus, issues get overlooked, and feedback cycles stretch indefinitely. Research shows a significant negative correlation between PR size and review quality: Google's engineering practices guide recommends keeping individual changesets within 200-400 lines, beyond which reviewers' attention and ability to detect defects drops sharply. However, in practice, feature development often involves changes across multiple system layers, and engineers frequently face a dilemma: either submit a massive PR and wait for lengthy reviews, or spend significant time manually managing PR splits. Stacked PRs was born precisely to address this pain point.

What Are Stacked PRs? Core Concepts Explained

Starting with the Concept

Stacked PRs (also known as PR chains or PR stacks) aren't a concept originated by Devin—they're a well-known workflow practice among senior engineers. The core idea is: breaking a large feature change into multiple logically progressive small PRs, where each PR builds upon the previous one, forming a "stack."

For example, if you're implementing a new user authentication system, the traditional approach might be to submit a single massive PR containing database changes, backend APIs, and frontend interfaces. Under the Stacked PRs workflow, this would be split into:

• PR 1: Database schema changes
• PR 2: Backend authentication logic built on PR 1
• PR 3: API endpoints built on PR 2
• PR 4: Frontend integration built on PR 3

Each PR focuses on a single responsibility, allowing reviewers to examine each layer sequentially with more precise feedback. This pattern draws from the "commit-by-commit review" culture long used internally at Meta (formerly Facebook) and Google—in these companies' internal tools, code changes are naturally submitted and reviewed as small, atomic units, rather than accumulating into large chunks as GitHub PRs tend to do.

Why Were Stacked PRs Rarely Used Before?

Although Stacked PRs are theoretically elegant, they've been quite difficult to implement in practice. The biggest barrier is maintenance cost: when a PR at the bottom of the stack is modified or merged, all PRs above it need to be rebased, potential conflicts resolved, and CI validation retriggered.

Rebase is a powerful but complex Git operation that essentially "replays" a sequence of commits from one branch onto the latest node of another branch. Unlike Merge, Rebase rewrites commit history, making code changes appear as if they were made on top of the latest codebase. In the Stacked PRs scenario, if PR 1 is modified and merged, the base points of PR 2, PR 3, and PR 4 all change, requiring sequential rebasing to transplant them onto the new base. During this process, if multiple PRs modify nearby regions of the same files, Git cannot automatically determine how to merge these changes, producing merge conflicts that require manual developer intervention. In a stack with 4-5 layers, a single bottom-level modification can trigger cascading conflict resolution needs—an extremely tedious and error-prone process.

Before Devin, several tools existed specifically for managing Stacked PRs. Graphite is the most well-known, created by former Facebook engineers, offering CLI tools and a web dashboard for visually managing PR stacks. Meta's internal ghstack combines GitHub PRs with Phabricator-style commit-by-commit review. There are also open-source tools like git-branchless and spr. While these tools lowered the operational barrier, they still required developers to understand underlying Git logic and manually intervene in conflict scenarios.

This is precisely what makes Devin's feature upgrade significant—it fully automates these previously manual, repetitive "grunt work" tasks, and combines AI's code comprehension capabilities to intelligently resolve conflicts based on semantics rather than performing purely mechanical operations.

How Devin Implements Stacked PRs Automation

Three Core Automation Components

According to the official introduction, Devin handles three core automated tasks in the Stacked PRs workflow:

1. Automatic Rebase: When a lower-level PR in the stack changes, Devin automatically rebases all upper-level PRs onto the latest base, eliminating the need for engineers to manually execute a series of git commands. This means that when reviewers' feedback on a lower PR is incorporated, the entire stack automatically updates to maintain consistency—engineers don't need to memorize complex git rebase --onto syntax or worry about operational mistakes causing code loss.

2. Intelligent Conflict Resolution: The most headache-inducing part of rebasing is merge conflicts. Traditional conflict resolution relies on developers examining conflict markers (<<<<<<< and >>>>>>>) file by file, understanding the intent of code on both sides, then manually choosing or merging. Devin can understand code context across the entire stack and automatically handle these conflicts, significantly reducing the frequency of manual intervention. The key to this capability is that AI doesn't just do text-level pattern matching—it understands the semantic intent of code to make reasonable merge decisions.

3. Cross-Stack CI Validation: Each PR's changes need to pass continuous integration checks. In the Stacked PRs scenario, CI faces unique challenges: each PR must not only pass tests at its own level but also ensure that the overall state after merging with lower PRs is healthy. Traditional CI systems typically run tests only against the merge result of a single PR with the target branch, but in a stacked structure, the CI environment for upper PRs needs to include lower PR changes that haven't yet been merged into the main branch. Devin performs CI validation across the entire stack, building a complete virtual merge state to ensure each layer of changes is functional and doesn't break existing functionality.

Practical Significance for Development Workflows

The real value of this automation mechanism is that it makes Stacked PRs—an "expert workflow"—accessible to everyone. Engineers no longer need to master complex git operations or rely on third-party toolchains to enjoy the review efficiency gains that small PRs provide.

More importantly, this reflects how AI programming assistants are evolving from "generating code" to "managing engineering processes." The development of AI programming tools has progressed through clear stages: from inline completion represented by GitHub Copilot, to conversational code generation with ChatGPT/Claude, to AI Agents like Devin and Cursor Agent that can autonomously complete multi-step tasks. The key shift in the current wave of evolution is that AI Agents are beginning to engage with aspects of software engineering "beyond code"—including task planning, change management, PR organization, and documentation maintenance. These aspects were traditionally viewed as "meta-work" requiring engineering judgment rather than automatable repetitive labor. Devin isn't just helping you write code—it's helping you organize how code changes are presented, enabling human reviewers to participate more efficiently in AI-led development processes. This resonates interestingly with the engineering wisdom that "writing code accounts for only 20-30% of development time"—AI is now covering the other 70-80% of coordination and management work.

A Deeper Industry Signal: AI Agents Beginning to Understand Collaboration

From Code Generation to Collaboration Optimization

The Stacked PRs feature reveals an interesting trend: AI programming Agents are beginning to prioritize "human-machine collaboration readability." Previously, concerns centered on AI-generated code being difficult to review and highly black-boxed, but splitting large changes into independently reviewable small PRs is precisely about proactively lowering the barrier for humans to review AI output.

This is a pragmatic attitude—AI acknowledges that its output still needs human oversight and actively optimizes that oversight process. Compared to the aggressive approach of pursuing "completing everything in one shot," this design better aligns with real software engineering team collaboration norms. In a sense, this is also an honest response to current AI code generation reliability: since AI-generated code still has a probability of errors, enabling humans to review each step of changes at finer granularity is a responsible strategy for engineering quality.

Potential Impact on Team Code Review Culture

It's foreseeable that if such features mature and become widespread, Code Review culture within teams may shift. Reviewers will no longer face massive AI-generated PRs of thousands of lines, but rather a series of logically clear, single-responsibility small changes. This both improves review quality and makes AI-generated code easier to trust and adopt.

This transformation may also reshape the role of human engineers within teams. When AI handles most code writing and change management, human engineers' core value will increasingly manifest in architectural decisions, business logic judgment, and quality assurance—and Stacked PRs provides a friendlier working interface precisely for this "reviewer role." Reviewers can focus on the design rationality of each layer of changes rather than being overwhelmed by massive code diffs.

Of course, the actual effectiveness of this feature still needs validation in real projects. The reliability of automatic conflict resolution in complex scenarios, whether code semantics remain consistent after rebasing—these issues still require engineers to stay vigilant. Particularly in scenarios involving state management, concurrency logic, or cross-service dependencies, AI's conflict resolution may introduce subtle semantic errors that are often difficult to catch through conventional testing. Teams adopting such tools still need to establish mechanisms and a culture for validating AI output.

Conclusion

Devin's Stacked PRs feature transforms a high-barrier senior engineering practice into an automated capability, making the workflow of breaking large tasks into reviewable small PRs no longer require tedious manual maintenance. This not only improves the reviewability of AI-generated code but also signals that AI programming assistants are moving from pure code generation toward deep participation in the entire development collaboration process. For developers looking to introduce AI-assisted programming into their teams, this is a direction worth watching—it foreshadows that future AI programming tool competition will not only be about code generation quality, but also about depth of understanding and support for software engineering collaboration workflows.