{"id":4736,"date":"2026-08-04T17:15:18","date_gmt":"2026-08-04T17:15:18","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/04\/turn-one-giant-ai-generated-pull-request-to-a-reviewable-stack\/"},"modified":"2026-08-04T17:15:18","modified_gmt":"2026-08-04T17:15:18","slug":"turn-one-giant-ai-generated-pull-request-to-a-reviewable-stack","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/04\/turn-one-giant-ai-generated-pull-request-to-a-reviewable-stack\/","title":{"rendered":"Turn one giant AI-generated pull request to a reviewable stack"},"content":{"rendered":"<p class=\"wp-block-paragraph\">Think about the last big feature you shipped. Be honest. Did you cram it into one giant pull request, or did you split it into smaller scoped pull requests? For years, you have silently had to decide between watching a pull request grow so large that reviewing it becomes a nightmare or breaking it into a chain of smaller pull requests that you have to babysit, sync by hand, and untangle conflicts every time a change is introduced below.<\/p>\n<p class=\"wp-block-paragraph\">Both options have trade-offs. One is hard to <em>review<\/em>, while the other is hard to <em>maintain.<\/em> Your decision that day leans towards the less painful option.<\/p>\n<p class=\"wp-block-paragraph\">Now add coding agents. They are incredibly productive and are <em>projected to drive a 50% productivity gain across every SDLC stage by 2028,<\/em> <a href=\"https:\/\/github.blog\/ai-and-ml\/github-copilot\/github-recognized-as-a-leader-in-the-gartner-magic-quadrant-for-enterprise-ai-coding-agents-for-the-third-year-in-a-row\/\"><em>according to Gartner<\/em><\/a>. But, they can\u2019t take away the choice of how you structure your pull requests. They amplify the need to make it.<\/p>\n<p class=\"wp-block-paragraph\">In this post, follow along with an example of how you can use stacked pull requests to simplify reviews.<\/p>\n<figure class=\"wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio\">\n<div class=\"wp-block-embed__wrapper\">\n<div class=\"mod-vh position-relative\"><\/div>\n<\/div>\n<\/figure>\n<h2 class=\"wp-block-heading\">A closer look: Adding product search to a shopping assistant<\/h2>\n<p class=\"wp-block-paragraph\">Let\u2019s say you issue a prompt to add product search to a shopping assistant, walk away and minutes later, literally, you come back to review, steer, and approve. But look closely at what tends to land in that single pull request:<\/p>\n<ul class=\"wp-block-list\">\n<li>A new data model and its seed data<\/li>\n<li>An API route and its validation<\/li>\n<li>The client wiring and the UI and the empty\/fallback\/error states<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">\u2026all of this and more in one ginormous 1,000+ line diff.<\/p>\n<figure class=\"wp-block-image size-large\"><img data-opt-id=652122561  fetchpriority=\"high\" decoding=\"async\" data-recalc-dims=\"1\" height=\"260\" width=\"1024\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/pr-size-counter.gif?resize=1024%2C260\" alt=\"Animated gif showing the pull request size grow from 0 lines to over 1,500 lines.\" class=\"wp-image-97905\" \/><\/figure>\n<p class=\"wp-block-paragraph\">For agents largely trained on how code has traditionally been written over the years, this pattern is their default way of shipping. Let\u2019s play this out.<\/p>\n<p class=\"wp-block-paragraph\">You want to add product search on as existing web application and your starting state is:<\/p>\n<ul class=\"wp-block-list\">\n<li>A mock AI Assistant showing responses from a random-line generator<\/li>\n<li>Inconsistent product data hardcoded and scattered across components<\/li>\n<li>No catalog module, no API, no data layer\u2014no nothing<\/li>\n<\/ul>\n<figure class=\"wp-block-image size-large\"><img data-opt-id=691997400  fetchpriority=\"high\" decoding=\"async\" data-recalc-dims=\"1\" height=\"681\" width=\"1024\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/zava-starting-state.png?resize=1024%2C681\" alt=\"Screenshot of the starting state of the website without a product search.\" class=\"wp-image-97907\" \/><\/figure>\n<p class=\"wp-block-paragraph\">An issue is opened to implement the feature, and a typical flow would be to create a feature branch, assign it to a coding agent (or multiple custom agents), get a first draft of the whole implementation code and updated tests\u2026<\/p>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.22.43-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/agent-full-implementation.mp4\" preload=\"none\"><\/video><\/figure>\n<p class=\"wp-block-paragraph\">\u2026you read the code (well, you <em>maybe<\/em> read the code). Then, you still need to manually verify feature behavior and make any necessary updates, push and open a pull request with its long-yet-shallow AI generated description, ensure CI checks are green, and self-review diff then request reviewers. You get started\u2026<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code language-plaintext\"><code>&lt;reviewer's hat&gt;<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">Reviewer: <em>1,721 lines changed!! This description isn\u2019t very helpful. I\u2019ll review this later.<\/em><\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code language-plaintext\"><code>&lt;\/reviewer's hat&gt;<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">And what follows is familiar:<\/p>\n<ul class=\"wp-block-list\">\n<li>The large pull request becomes hard to review\u2014so it just\u2026sits there.<\/li>\n<li>Reviewers lose context and the feedback quality drops.<\/li>\n<li>It becomes even slower to merge.<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">This kicks off a manual, messy, time-consuming process that\u2019s prone to conflicts before the feature lands, and it eventually lands under-reviewed.<\/p>\n<h2 class=\"wp-block-heading\">GitHub stacked pull requests<\/h2>\n<p class=\"wp-block-paragraph\"><strong>Stacked pull requests<\/strong> introduce a different and better structure of delivery. The principle is simple: decomposition. Instead of shooting for a single pull request that addresses the issue in its entirety, you break down the feature into logical layers and identify the dependency chain to arrive at your desired goal. This gives you, and your agents, a native way to decompose work that otherwise lands in a giant pull request into a chain of small, focused and independently reviewable layers.<\/p>\n<p class=\"wp-block-paragraph\">That large pull request that\u2019s hard to review becomes a <strong>stack<\/strong> of smaller, logically ordered pull requests, each scoped to a <strong>single concern, small<\/strong> enough to hold in a reviewer\u2019s head and with just <strong>enough context<\/strong> naturally flowing from the previously reviewed pull request.<\/p>\n<p class=\"wp-block-paragraph\">Let\u2019s make it happen.<\/p>\n<h2 class=\"wp-block-heading\">The stack structure<\/h2>\n<p class=\"wp-block-paragraph\">Let\u2019s look at the steps involved when decomposing the problem and arranging the layered stack.<\/p>\n<p class=\"wp-block-paragraph\">First, and importantly, <strong>set the stack base<\/strong>. This matters because CI checks and merge rules throughout the stack management lifecycle get evaluated against the stack base.<\/p>\n<p class=\"wp-block-paragraph\">Then, <strong>identify the core foundational unit of work<\/strong> and put it closer to the base (lowest in the stack), and layer dependent work above it.<\/p>\n<figure class=\"wp-block-table\">\n<table class=\"has-fixed-layout\">\n<thead>\n<tr>\n<th><strong>Stack\u00a0Layer\u00a0(L#)\/Branch<\/strong>\u00a0<\/th>\n<th><strong>What to ship<\/strong>\u00a0<\/th>\n<th><strong>Depends on<\/strong>\u00a0<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1 (feat\/catalog-data)\u00a0<\/td>\n<td>A typed catalog with seed data, validation, and a data access module\u00a0<\/td>\n<td>main (stack base)\u00a0<\/td>\n<\/tr>\n<tr>\n<td>L2 (feat\/search-api)\u00a0<\/td>\n<td>Validated \/api\/products\/search endpoint\u00a0<\/td>\n<td>feat\/catalog-data\u00a0<\/td>\n<\/tr>\n<tr>\n<td>L3 (feat\/chat-grounding)\u00a0<\/td>\n<td>Chat calls the API and answers from real product data\u00a0<\/td>\n<td>feat\/search-api\u00a0<\/td>\n<\/tr>\n<tr>\n<td>L4 (feat\/grounded-ui)\u00a0<\/td>\n<td>Product citation cards + state\u00a0<\/td>\n<td>feat\/chat-grounding\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p class=\"wp-block-paragraph\">Now the independent concerns are clear: <strong>data, API, wiring, UX<\/strong>, making it possible to allocate different reviewer audiences for each. Data is reviewed by a <strong>data owner<\/strong>, UX by a <strong>UI owner.<\/strong><\/p>\n<p class=\"wp-block-paragraph\">GitHub\u2019s native support for stacked pull requests can be launched from the pull request UI and extends seamlessly to the terminal with the <code>gh stack<\/code> CLI.<\/p>\n<h3 class=\"wp-block-heading\">Install the stacked pull requests CLI extension<\/h3>\n<p class=\"wp-block-paragraph\">Run the following:<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code language-plaintext\"><code>gh extension install github\/gh-stack<\/code><\/pre>\n<\/div>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.24.13-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/gh-stack-xtension-install.mp4\" preload=\"none\"><\/video><\/figure>\n<p class=\"wp-block-paragraph\">In ancient times, you\u2019d be set to start working. Not today though. There are agents working alongside you. These agents need to learn how stacks work and how to create and manage them on your behalf. The <code>gh-stack skills<\/code> teaches them this.<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code language-plaintext\"><code>gh skill install github\/gh-stack<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">Or, if you prefer:<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code language-plaintext\"><code>npx skills add github\/gh-stack<\/code><\/pre>\n<\/div>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.25.24-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/gh-skill-install.mp4\" preload=\"none\"><\/video><\/figure>\n<p class=\"wp-block-paragraph\">For the specific feature from the above example, your development workflow has custom agents, each with defined work streams and that follow a strict scoping discipline to achieve the goal of small, single-scoped pull requests.<\/p>\n<figure class=\"wp-block-table\">\n<table class=\"has-fixed-layout\">\n<thead>\n<tr>\n<th><strong>Layer\/branch<\/strong>\u00a0<\/th>\n<th><strong>Agent<\/strong>\u00a0<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1 (feat\/catalog-data)\u00a0<\/td>\n<td>Data modeler agent\u00a0<\/td>\n<\/tr>\n<tr>\n<td>L2 (\u00a0feat\/search-api)\u00a0<\/td>\n<td>Backend agent\u00a0<\/td>\n<\/tr>\n<tr>\n<td>L3 (\u00a0feat\/chat-grounding)\u00a0<\/td>\n<td>Frontend agent\u00a0<\/td>\n<\/tr>\n<tr>\n<td>L4 (\u00a0feat\/grounded-ui)\u00a0<\/td>\n<td>Frontend agent\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p class=\"wp-block-paragraph\">The last piece of the setup is to <strong>confirm CI exists<\/strong>. As mentioned earlier, each pull request will be evaluated against the stack base, and these checks will run for <strong>every layer.<\/strong><\/p>\n<p class=\"wp-block-paragraph\">Now the work begins.<\/p>\n<h3 class=\"wp-block-heading\">Layer one: Data catalog foundation<\/h3>\n<p class=\"wp-block-paragraph\"><em>Most agent workflows today are automated and execute autonomously in loops, but for the sake of illustration, we\u2019ll cover each step at a time.<\/em><\/p>\n<p class=\"wp-block-paragraph\">At this point, all agents are familiar with how stacked pull requests work, so a typical workflow at this stage would be:<\/p>\n<ol class=\"wp-block-list\">\n<li>Invoking the <strong>Data Modeler agent<\/strong> with an appropriate prompt<\/li>\n<li>The agent initializes a new stack and sets the first branch\u2014<code>feat\/catalog-data<\/code> with main as its base using <code>gh init stack<\/code><\/li>\n<li>Checks out, works and runs validation<\/li>\n<li><code>(All checks == green) ? commit the layer : Iterate<\/code><\/li>\n<\/ol>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.31.04-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/layer1-data.mp4\" preload=\"none\"><\/video><\/figure>\n<p class=\"wp-block-paragraph\">Reviewer\u2019s note for the future: <em>Are the types correct? Is the data validated? Is the query helper safe?<\/em> Period.<\/p>\n<h3 class=\"wp-block-heading\">Layer two: Product search API<\/h3>\n<p class=\"wp-block-paragraph\">Follow a flow similar to:<\/p>\n<ol class=\"wp-block-list\">\n<li>Invoking the <strong>Backend agent<\/strong> with an appropriate prompt<\/li>\n<li>The agent adds the next layer <code>feat\/search-api<\/code> <strong>on top of layer one<\/strong>, its base: <code>feat\/catalog-data<\/code>, to import the completed data access module with <code>gh stack add<\/code><\/li>\n<li>Checks out, works and runs validation<\/li>\n<li>Developer tests the API manually<\/li>\n<li><code>(API works &amp;&amp; All checks == green) ? commit the layer : Iterate<\/code><\/li>\n<\/ol>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.31.38-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/layer2-backend.mp4\" preload=\"none\"><\/video><\/figure>\n<p class=\"wp-block-paragraph\">Reviewer\u2019s note for the future: <em>Is input validated? Is the response contract stable? Are error\/empty states handled here or pushed downstream?<\/em> Period.<\/p>\n<h3 class=\"wp-block-heading\">Layer three: Wire chat to the API<\/h3>\n<p class=\"wp-block-paragraph\">In this next layer, you:<\/p>\n<ol class=\"wp-block-list\">\n<li>Invoke the <strong>Frontend agent<\/strong> with an appropriate prompt<\/li>\n<li>The agent adds the next layer <code>feat\/chat-grounding<\/code> <strong>on top of layer two<\/strong>. Its base: <code>feat\/search-api<\/code>, which will branch off with <strong>both the data access module and validated API<\/strong>.<\/li>\n<li>Checks out, works and runs browser tests with Playwright<\/li>\n<li><code>(All checks == green) ? commit the layer : Iterate<\/code><\/li>\n<\/ol>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.34.04-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/layer3-frontend.mp4\" preload=\"none\"><\/video><\/figure>\n<p class=\"wp-block-paragraph\">Reviewer\u2019s note for the future: <em>Is every answer tracing back to a real API response? What happens when the API fails or returns nothing?<\/em> Period.<\/p>\n<h3 class=\"wp-block-heading\">Layer four: Grounded UI and citations<\/h3>\n<p class=\"wp-block-paragraph\">You\u2019ll notice that layer three and layer four, despite having the same author, (Frontend agent), are layered distinctively. This is deliberate. The UI owner should not have to check the underlying data flow and vice versa, and this structure allows for that independence.<\/p>\n<p class=\"wp-block-paragraph\">So, the frontend agent:<\/p>\n<ol class=\"wp-block-list\">\n<li>Adds the next layer <code>feat\/grounded-ui<\/code> <strong>on top of layer three<\/strong>, its base: <code>feat\/chat-grounding<\/code><\/li>\n<li>Checks out, works and runs browser tests with Playwright<\/li>\n<li><code>(All checks == green) ? commit the layer : Iterate<\/code><\/li>\n<\/ol>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.34.39-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/layer4-frontend.mp4\" preload=\"none\"><\/video><\/figure>\n<p class=\"wp-block-paragraph\">Reviewer\u2019s note for the future: <em>Does every citation link back to a real product? Are loading, empty and error states all covered?<\/em> Period.<\/p>\n<h3 class=\"wp-block-heading\">Submit the stack<\/h3>\n<p class=\"wp-block-paragraph\">The four local stacked branches are ready. Next is to push them to remote with <code>gh stack push<\/code>, then create pull requests linking them on GitHub with <code>gh stack submit<\/code>.<\/p>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.35.24-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/gh-stack-submit.mp4\" preload=\"none\"><\/video><\/figure>\n<h3 class=\"wp-block-heading\">The stack map and CI on each layer<\/h3>\n<p class=\"wp-block-paragraph\">Switching over to GitHub, all four pull requests are open and at the top of each one, you see a <strong>stack map,<\/strong> which is a one-click navigation system between pull requests in the stack.<\/p>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.35.57-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/stack-map.mp4\" preload=\"none\"><\/video><\/figure>\n<h2 class=\"wp-block-heading\">Reviewing and updating the stack<\/h2>\n<p class=\"wp-block-paragraph\">Time to switch hats and look at a reviewer\u2019s journey through stacked pull requests.<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code\"><code>&lt;reviewer\u2019s hat on&gt;<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">The stack map is a reviewer\u2019s compass \u2013 a navigation aid between the top of the stack and its bottom, heading towards a successful merge. The movement is directional: <strong>read<\/strong> top-down,<strong> review<\/strong> bottom-up.<\/p>\n<ul class=\"wp-block-list\">\n<li>Read top-down, for context. This gives you the end goal at the very beginning of the review process, so you can set a bearing. <em>\u201cOh, so we want to display product cards on the chat interface.\u201d<\/em><\/li>\n<li>Review bottom-up to build on the predetermined checkpoints. The implementation on each layer only makes sense once the preceding layer is understood.<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">You are no longer looking at a single 1,720+ line-sized pull request to be reviewed in one sitting, as we saw in our example, but instead, the review can be distributed in small, self-contained targets in a stack.<\/p>\n<figure class=\"wp-block-video\"><video height=\"720\" width=\"1280\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-04-at-8.45.18-AM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/compare-before-and-after-improved.mp4\" preload=\"none\"><\/video><\/figure>\n<p class=\"wp-block-paragraph\">As the assigned human in the loop reviewer, you come in and look at layer one, the pull request at the bottom of the stack, and see that the automatic Copilot Code Review (CCR) caught two issues which you agree should be fixed.<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code language-plaintext\"><code>&lt;developer's hat back on&gt;<\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">Changes are requested at the bottom of the stack, so you:<\/p>\n<ul class=\"wp-block-list\">\n<li>Hand the feedback to the layer one author, data modeler agent that owns the branch<\/li>\n<li>Suggestions are applied, tested, committed and pushed<\/li>\n<li>Once the fix lands on feat\/catalog-data, the natural next question is: <em>what does this mean for layers two, three, and four?<\/em><\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">Since branch <code>feat\/catalog-data<\/code> was pushed out of turn after the review, GitHub flags it plainly: \u201cSome branches in this stack have diverged and must be rebased\u201d paired with \u201cUnable to merge as a stack\u201d flag and that blocks the merge.<\/p>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.38.03-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/gh-stack-rebase.mp4\" preload=\"none\"><\/video><\/figure>\n<p class=\"wp-block-paragraph\">Back on the pull request UI on GitHub, a one-click <strong>Rebase stack<\/strong> button appears. Before using the button, there is something important worth noting. Triggering a web-based rebase using this button runs it on GitHub\u2019s servers, which means it resets the committer to whoever clicked the button, the resulting commits aren\u2019t signed, and if branch protection expects signed commits, that one click quietly breaks.<\/p>\n<p class=\"wp-block-paragraph\">The safer, equivalent move from the terminal would be <code>gh stack rebase<\/code> to perform that same cascading rebase locally as you interactively resolve conflicts, but this time using your own Git configuration, then <code>gh stack push<\/code>.<\/p>\n<p class=\"wp-block-paragraph\"><strong>Finally, you\u2019ll propagate through the stack.<\/strong> The rest of the stack, both local and on GitHub, now needs to catch up, and it couldn\u2019t be easier than a single sync command <code>gh stack sync<\/code>.<\/p>\n<p class=\"wp-block-paragraph\">An all-in-one flow starts with fetching from origin, cascading a rebase of every branch above <code>feat\/catalog-data<\/code> onto the new commit, pushes the rebased branches and syncs pull request state from GitHub. This way, the change ripples upward without anyone touching layers two, three, or four by hand.<\/p>\n<p class=\"wp-block-paragraph\">Back on GitHub, all checks re-run, pass and the stack map settles back into a clean, mergeable line from main to <code>feat\/grounded-ui<\/code>.<\/p>\n<figure class=\"wp-block-video\"><video height=\"2160\" width=\"3840\" controls poster=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-03-at-8.39.10-PM.png\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/08\/gh-stack-sync-lc.mp4\" preload=\"none\"><\/video><\/figure>\n<div class=\"wp-block-group post-content-cta has-global-padding is-layout-constrained wp-block-group-is-layout-constrained\">\n<p class=\"wp-block-paragraph\">Get started with <a href=\"https:\/\/docs.github.com\/pull-requests\/how-tos\/stacked-pull-requests\">stacked pull requests &gt;<\/a><\/p>\n<\/div>\n<p>The post <a href=\"https:\/\/github.blog\/engineering\/turn-one-giant-ai-generated-pull-request-to-a-reviewable-stack\/\">Turn one giant AI-generated pull request to a reviewable stack<\/a> appeared first on <a href=\"https:\/\/github.blog\/\">The GitHub Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Think about the last big feature you shipped. Be honest. Did you cram it into one giant pull request, or [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4737,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[8],"tags":[],"class_list":["post-4736","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-github-engineering"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4736","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4736"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4736\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/4737"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4736"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4736"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4736"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}