On July 30, 2026, the official GitHub blog showcased the "stacked session" working method in Copilot: developers can create multiple dependent sessions in the same repository, allowing the next task to inherit the context and code output of the previous task, and then form pull requests merged in order. Its problem isn't whether the model can write code, but whether the team can still review it thoroughly after AI has made too many changes at once.
Why does an old project need a session stack?
GitHub's case shows a personal application that has continued since 2014, still using React 15, Less, and the older React-Bootstrap. Developers first have Copilot plan front-end modernization, then gradually implement it; When removing React-Bootstrap began to go beyond the current task scope, she didn't continue to expand the original session. Instead, she first created pull requests for existing work, then created new sessions to carry on the preceding context.
Copilot then accomplished three things: saving the current modification as a pull request; Create a new stack session for component replacement and generate a pending confirmation schedule; Create the next pull request based on the previous branch. In this way, each modification has its own review boundaries while maintaining a clear order of dependencies.
It targets a new type of range runaway in AI programming
AI programming reduces the cost of generating code, but also makes 'major overhauls' all too easy. A single prompt can quickly escalate into tens of thousands of lines of modifications, mixing functionality, refactoring, dependency upgrades, and style adjustments. Even if the code works, reviewers find it difficult to determine which changes cause regression.
Stacking sessions breaks down long tasks into incremental parts that can be tested and reviewed independently: first merge the underlying preparation, then merge the features that depend on it; When a problem occurs on a certain floor, it is also easier to locate and withdraw. It shifts the AI agent's work unit from a single long conversation to a set of small tasks with delivery relationships.
Don't overlook these four checkpoints when using it
- Each session only retains a clear goal, avoiding just random refactoring.
- After the lower-level pull requests change, the upper-layer branch must be re-synchronized and conflicts handled.
- Tests should follow each layer of modification, rather than running uniformly after the entire stack is finished.
- The order of mergers must be clear; When upper-layer code dependencies have not yet entered the main branch, they should not be mistaken for independently redistributable.
Stacking sessions do not help developers decide which boundaries to split, nor do they automatically prove code is correct. Its true value is that long-running coding agents remain subject to traditional software engineering constraints: small-scale modifications, independent verification, clear dependencies, and rollback reviews. For legacy system upgrades and multi-step migration, this is more reliable than aiming for a one-time generation and complete completion.
