<div><img width="770" height="329" src="https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205.jpg" class="attachment-large size-large wp-post-image" alt="AI coding, teams, vibecoding, shadow, vibecoding vibe, coding, GitHub, agents, Gemini, Canvas, Gemini, code, Augment Code, code, kernel compliance-as-code software secure software Terraform infrastructure" style="margin-bottom: 0px;" decoding="async" srcset="https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205.jpg 770w, https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205-290x124.jpg 290w, https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205-360x154.jpg 360w, https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205-400x171.jpg 400w" sizes="(max-width: 770px) 100vw, 770px" /></div><img width="150" height="150" src="https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205-150x150.jpg" class="attachment-thumbnail size-thumbnail wp-post-image" alt="AI coding, teams, vibecoding, shadow, vibecoding vibe, coding, GitHub, agents, Gemini, Canvas, Gemini, code, Augment Code, code, kernel compliance-as-code software secure software Terraform infrastructure" decoding="async" />GitHub introduces native stacked pull requests, helping development teams break large changes into smaller, dependency-ordered PRs that are faster and easier to review.
<div><img width="770" height="329" src="https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205.jpg" class="attachment-large size-large wp-post-image" alt="AI coding, teams, vibecoding, shadow, vibecoding vibe, coding, GitHub, agents, Gemini, Canvas, Gemini, code, Augment Code, code, kernel compliance-as-code software secure software Terraform infrastructure" style="margin-bottom: 0px;" decoding="async" srcset="https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205.jpg 770w, https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205-290x124.jpg 290w, https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205-360x154.jpg 360w, https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205-400x171.jpg 400w" sizes="(max-width: 770px) 100vw, 770px" /></div><img width="150" height="150" src="https://devops.com/wp-content/uploads/2022/02/coding-gb646cb77a_1280-e1644931732205-150x150.jpg" class="attachment-thumbnail size-thumbnail wp-post-image" alt="AI coding, teams, vibecoding, shadow, vibecoding vibe, coding, GitHub, agents, Gemini, Canvas, Gemini, code, Augment Code, code, kernel compliance-as-code software secure software Terraform infrastructure" decoding="async" /><p><span style="font-weight: 400;">For years, stacked pull requests have been something of an open secret in software engineering. Teams at Meta and Google have used internal versions of the workflow for over a decade, and open source developers cobbled together their own approach with tools like ghstack. Now GitHub is making it a native feature. The company announced this week that stacked pull requests are in public preview, rolling out to all repositories over the coming days.</span></p>
<p><span style="font-weight: 400;">The idea behind stacking is simple, even if the mechanics take some getting used to. Instead of building one large pull request that captures an entire feature, developers break the work into an ordered series of smaller PRs. Each one sits on top of the last, representing a single layer of the change. A schema update might be the base layer, with business logic stacked on top of that, and a UI change stacked on top of that. Reviewers can look at each layer on its own, without wading through a diff that spans a thousand lines.</span></p>
<p><span style="font-weight: 400;">That distinction matters more than it might seem. Research on code review patterns has consistently found that review quality drops as pull requests grow. One analysis of 1.5 million pull requests found that changes under 200 lines get approved roughly three times faster than larger ones, and carry about 40% fewer defects. Every additional 100 lines adds close to 25 minutes of review time, and once a PR passes the 1,000-line mark, the odds of catching real problems fall sharply. Reviewers simply run out of the mental bandwidth needed to do the job well.</span></p>
<p><span style="font-weight: 400;">“Review capacity sets delivery pace on most teams,” said Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at <a href="https://futurumgroup.com/" target="_blank" rel="noopener">The Futurum Group</a>. “Breaking that change into ordered layers lets a reviewer verify the schema before judging the logic built on top of it.”</span></p>
<p><span style="font-weight: 400;">GitHub’s version of stacking works through a new CLI extension, </span><span style="font-weight: 400;">gh-stack</span><span style="font-weight: 400;">, along with support on github.com, the GitHub mobile app, and through coding agents like GitHub Copilot using a dedicated skill. Developers start with a branch and PR for the first change, then add branches and PRs on top of it, with each new PR targeting the layer beneath it. A stack map at the top of each pull request shows how that specific layer fits into the larger change, so reviewers get context without having to review the whole stack at once.</span></p>
<p><span style="font-weight: 400;">The merge experience is where GitHub’s approach earns its keep. Merging the latest ready PR in a stack lands that change along with every unmerged layer underneath it, all in one operation. Teams can also merge partial stacks, landing lower layers while the PRs above them stay open, automatically rebasing and retargeting against the new base. Existing branch protections, required checks, and merge queues still apply throughout, since stacking is built into GitHub rather than layered on top of it as a separate tool.</span></p>
<p><span style="font-weight: 400;">Early adopters are already describing the shift in how they work. Vercel’s Next.js team said stacked PRs helped them ship larger features while keeping individual changes small and easier to review. TED’s engineering team pointed to a more specific pressure: as AI coding tools have made developers more productive, the pull requests they generate have grown large enough to overwhelm reviewers. Stacking, in their telling, restores the balance by breaking that output into dependency-ordered chunks that are easier to verify, both faster and more accurately.</span></p>
<p><span style="font-weight: 400;">That AI angle is worth sitting with. Coding agents are increasingly capable of producing entire features in one pass, and that output has to go somewhere. Without a mechanism for splitting it up, teams risk trading one bottleneck (writing code) for another (reviewing it). Stacked PRs give teams a way to turn agent-generated work into a series of bounded review units, such as a schema change followed by service logic followed by an interface update, so a reviewer can validate the foundation before signing off on what’s built on top of it. That only holds, though, when the work has a genuine dependency chain. Stacking unrelated changes just because multiple agents happened to produce them in parallel adds complexity without the benefit.</span></p>
<p><span style="font-weight: 400;">“Verification debt is what makes small changes worth the extra branches,” Ashley said. “Teams measuring output by merged volume will keep hiring reviewers to chase machine-speed generation. Engineering leaders have to size work to what a reviewer can hold.”</span></p>
<p><span style="font-weight: 400;">Merge queue support for stacked PRs is rolling out progressively over the coming weeks, which suggests GitHub is still smoothing out how the feature behaves under real-world CI load. Teams that have relied on third-party stacking tools, such as Graphite, will likely watch closely to see how much of that workflow GitHub absorbs natively and how much room remains for specialized tooling on top.</span></p>
<p><span style="font-weight: 400;">What’s clear already is that GitHub is treating pull request size as a productivity and quality problem worth solving at the platform level, not just a workflow preference for individual teams. As AI tools generate more code faster, the way that code gets reviewed may end up mattering more than the way it gets written.</span></p>