Integrating Stacked Pull Requests Into Legacy System Architectures

Moving to stacked pull requests changes how large software teams manage development. By shifting from monolithic updates to smaller, sequenced units of change, engineering teams reduce cognitive load and speed up review cycles. However, as GitHub engineer Samin Karim explains, the challenge was not just building the feature. It was integrating this workflow into a complex, legacy system without compromising security or compliance. For engineering leaders, this shows that durable technical advantages often come from boring systemic improvements that solve for developer experience at scale. Understanding how these systems handle dependencies and state is the key to unlocking velocity.

The hidden complexity of simple workflows

The most common mistake in systems design is assuming a new feature is just a UI addition. When Karim’s team at GitHub approached stacked pull requests, they realized the merge box, which validates if a PR is ready, was already evaluating hundreds of conditions in real time. Adding stacks meant the system could no longer check one PR at a time; it had to validate the entire chain.

> "There is actually so much that happens behind the scenes because there are of course are your checks passing, are your builds passing? Do you have rules set up? Do you require an approval? And then of course do you have conflicts? ... And there is hundreds of conditions that we evaluate for."
>
> -- Samin Karim

This creates a hidden computational cost. Every time a developer pushes a change, the system runs a ghost merge simulation to ensure the entire stack remains valid. By building this natively into the existing PR model instead of creating a separate abstraction, the team avoided a fragmented ecosystem but inherited the task of updating core code that had not been touched in over a decade.

When convenience creates security risks

Systems thinking requires identifying how new features can be exploited to bypass existing guardrails. In a mono-repo environment, code owners act as a security gate. Karim noted a consequence of stacked PRs: a developer could theoretically modify the CODEOWNERS file in the bottom PR of a stack to bypass review requirements for subsequent PRs in that chain.

To prevent this, the system was designed to ignore CODEOWNERS changes within the middle of a stack, forcing the system to always reference the main branch as the source of truth. This is a classic example of where developer convenience must be constrained by systemic integrity. If the team had optimized purely for ease of use, they would have created a security hole.

Why native beats hackier

Before native support, teams relied on third-party plugins or complex workarounds to simulate stacks. These hacks often required relaxing branch protection rules or configuring CI to run on every single PR, regardless of its target.

> "It is one of those things that when you are working on a new feature like stacked PRs, it literally exponentially increases the complexity of something like that. And those are the types of things that we really need to make sure that we did that properly to make sure security is in place, but also making sure it is reliable and available as well."
>
> -- Samin Karim

The move to native integration allows teams to unwind these workarounds. The long-term advantage is not just a cleaner UI; it is the ability to maintain strict security postures, such as SOC 2 compliance, without sacrificing developer velocity. The payoff is a system that works with existing infrastructure, which is a competitive advantage for organizations that can no longer afford the maintenance tax of bespoke, hacky tooling.

Key action items

• Audit your current PR hacks: Review where your team uses manual coordination, such as waiting for PR A to merge before B. Transition these to native stack workflows to eliminate human error. (Immediate)
• Decompose large features: Use a storytelling approach to PRs. Break down features into atomic, independently reviewable units that tell the story of the change. (Immediate)
• Leverage AI for decomposition: If your team uses coding agents, ensure they are instructed to use plan mode and stacked PRs to break down large tasks into smaller, manageable chunks. (Over the next quarter)
• Standardize repository context: Adopt agents.md as a standard to provide your coding agents with the necessary context, such as test commands and environment setup, that currently lives only in developers' heads. (Next 1-3 months)
• Evaluate your merge strategy: If you use rebase force-push, note that native stack support now includes signed commits for rebases, allowing for a clean, linear history without sacrificing security. (Immediate)
• Monitor ghost merge performance: As you scale your stack usage, keep an eye on CI/CD latency. While the system handles the complexity, ensure your test suites are optimized for atomic changes rather than massive, monolithic runs. (12-18 months)