Today we’re proud to partner with GitHub to support Stacked PRs in Devin.
When tackling larger tasks, Devin will automatically create a stack of PRs to make the review process easier. Additionally, as you iterate on each PR in a stack and leave comments, Devin addresses them and automatically rebases any downstream PRs. You can also ask Devin to create a stack from existing large PRs that are hard to review.
In Devin Review, stacked PRs benefit from more focused context, while still maintaining awareness of the rest of the stack.
PR stacks are available today on Devin. Read more to learn about what are stacked PRs and how Devin handles all the operational burden for you.
The New Shape of Work
Coding agents can now handle ambitious tasks in one shot. At Cognition, we routinely see customers ask Devin to restructure auth flows, replace deprecated APIs across a system, or migrate entire services. Devin comes back with the job done. Tests are passing and the CI is green. The PR description is thorough and, as far as you can tell, accurate. The PR itself, however, is often thousands of lines long across dozens of files.
This is the new shape of work. When agents produce code, the engineer’s job shifts from implementation to review. And review doesn’t scale in the same way. The data on this is already stark: Faros AI’s 2025 telemetry study of over 10,000 developers across 1,255 teams found that teams with high AI adoption merged 98% more pull requests, while review time per PR rose 91% and average PR size grew 154%. Despite the individual productivity gains, organization-level delivery metrics didn’t improve.
Teams with high AI adoption, relative to low-adoption teams
Faros AI telemetry · 10,000+ developers · 1,255 teams · 2025
Source: Faros AI, The AI Productivity Paradox Report (2025), as analyzed in Farrag, The Productivity-Reliability Paradox (2026)
The obvious fix is to babysit an agent and review its work prompt by prompt, at the cost of the autonomy that made it valuable in the first place. But even as the unit of autonomy grows, the unit of review doesn’t have to.
Today we’re introducing automatic stacked PRs in Devin to close the gap. When Devin completes a large task, it no longer opens one monolithic PR; it breaks the changes into a stack of smaller, self-contained PRs, each one reviewable on its own. You review the way you always have, one focused diff at a time, as Devin handles the work of keeping the stack coherent.
Decomposition is the Real Bottleneck
The conventional story about AI-driven development is that generation got cheap, so review became the bottleneck. While true, it is not the interesting part. Review was always downstream of a different skill - decomposition - breaking work into increments that can be verified independently.
The industry has known this for a long time. Stacked PRs are not a new idea: instead of one branch holding the whole change, you split it into a chain of small dependent PRs, each reviewable on its own and building on top of its predecessor.
For example, the first PR introduces the schema, the next covers the API surface, and finally a PR implementing the UI. This not only improves the size of reviews, but also allows engineers to iterate on each part of the stack independently.
One change, two shapes of review
Add end-to-end authentication, session management, teams, and protected routes
47 files · +2,881 −61
one review unit · 2,942 changed lines
-
1 Core email/password auth, sessions, and protected routes
19 files · +585 −52
-
2 Password reset, email verification, rate limiting, and audit log
16 files · +498 −2
-
3 Account settings: profile, password change, and deletion
8 files · +393 −1
-
4 Teams: creation, invites, membership, and shared team notes
14 files · +636 −12
-
5 Dev setup (Makefile, seed script) and test suite
7 files · +774 −7
This workflow has powered development at Google and Meta for over fifteen years, and tools like ghstack, Sapling, and Graphite have steadily lowered the friction of using it on GitHub. Despite all of it, the median team never adopted the workflow.
This is not a culture problem, but rather structural. Decomposition is retroactive work. You rarely understand the true shape of a PR until you’ve made significant progress, and by then, splitting the diff means re-deriving your own work. Additionally, the mechanics of decomposition are miserable: careful Git rebasing or onboarding to a new tool.
However, agents don’t experience these burdens. They can revise their own work and learn how to use new tools. The hard part is knowing how to decompose well, and then operating the stack once you have its structure.
Decomposition as a capability
The seams of a good stack are almost always architectural: which pieces the work decomposes into and in what order they must land — the API change before the new UI, or the refactor before the feature it enables. Getting this right requires knowing the codebase, not just the diff, and this is where Devin has an unusual edge. Before it writes a line, Devin works from DeepWiki, a continuously indexed map of your repository’s architecture: the modules, the boundaries between them, and how they depend on each other. Devin sees those seams explicitly rather than inferring them from code, and layers on your organization’s accumulated knowledge and skills — like how migrations should ship or how PRs are organized — so those curated facts flow directly into how it plans the stack.
The same planning works in reverse. Hand Devin a large PR that already exists and it re-derives the structure after the fact. This means you can now point Devin at a 4k-line PR you have been avoiding.
Devin builds stacks on top of GitHub’s native stacked PRs. It announces the stack by name before the first PR exists, so you can watch it take shape as PRs are created. Devin also monitors the entire stack’s readiness: CI, reviews, and mergeability for every layer at once.
When review feedback lands on a lower layer, the mainline moves underneath the stack, or a bottom layer merges, Devin reacts automatically. It rebases affected layers, resolves resulting conflicts, and re-verifies CI across the stack. Every resolution visible in the session history, with a question surfaced only when a conflict reflects a genuine decision that needs a human. Reviewers and authors can iterate on individual layers freely, and the stack stays consistent without anyone doing bookkeeping by hand.
Devin is also deliberately conservative about when to stack at all. A stack is only created when Devin has intentionally split one piece of work into an ordered series designed to land together, not merely because one branch builds off another. If a change doesn’t decompose into steps that each make sense alone, it ships as one PR.
Available Today
As agents take on larger units of work, the answer isn’t to constrain their autonomy, but to make sure their output arrive in the shape engineers already know how to trust: small, ordered, and independently verifiable changes. Stacked PRs make decomposition something you get by default rather than a discipline you have to maintain. Give Devin a big task, or a big PR you’ve been dreading, and review it one focused diff at a time. Stacked PRs in Devin are available today at devin.ai.