--- title: Make Reviews Possible Again With This One Simple Trick description: AI-generated code tends to produce large, hard-to-review diffs. A practical solution is using stacked branches: breaking a monolithic branch into a sequence of... canonical: https://daily.dev/posts/make-reviews-possible-again-with-this-one-simple-trick-bagkdzx2a twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Make Reviews Possible Again With This One Simple Trick | daily.dev og:description: AI-generated code tends to produce large, hard-to-review diffs. A practical solution is using stacked branches: breaking a monolithic branch into a sequence of... og:url: https://daily.dev/posts/make-reviews-possible-again-with-this-one-simple-trick-bagkdzx2a og:image: https://api.daily.dev/og/posts/baGKdZx2A.png og:image:alt: Make Reviews Possible Again With This One Simple Trick og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Make Reviews Possible Again With This One Simple Trick **[Lobsters](https://daily.dev/sources/lobsters)** · 8 min read · 3 upvotes · 1 comments ## Summary AI-generated code tends to produce large, hard-to-review diffs. A practical solution is using stacked branches: breaking a monolithic branch into a sequence of smaller, coherent PRs that can be reviewed independently. The proposed workflow lets developers hack freely on a single branch, then ask an AI tool to automatically split the work into 4-5 numbered stacked branches. The post covers standard alternatives (more tests, smaller PRs, group reviews, AI review), explains the stacked branch concept, and discusses open questions including GitHub's poor UI for stacked PRs, CI cost concerns, atomic merging strategies, and the option to use jj for branch management. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 26 comments across lobsters, hackernews (as of 2026-07-31). **TL;DR:** The community is skeptical about stacked PRs as a solution, debating whether they're meaningfully different from multi-commit single PRs and raising concerns about rebase overhead and GitHub's poor tooling support. A minority see genuine value, especially for incremental merging, but many feel the approach papers over deeper planning problems. **Sentiment:** 20% positive · 50% mixed · 30% skeptical **The case for** - Stacked PRs allow incremental merging, so earlier parts of a feature can land before the whole suite is ready. - Breaking work into smaller, coherent units makes each individual piece more reviewable than one giant diff. - Tools like jj, Sapling, and git's --update-refs can ease the rebase burden of maintaining a stack. **The pushback** - Reviewers can't see the overall design until all PRs in the stack are reviewed, risking late-stage architectural pushback. - Any change to an early branch in the stack forces rebasing all dependent branches, adding significant overhead. - The approach may just be a workaround for poor planning rather than addressing the root cause of oversized changes. - GitHub's review tooling is poorly suited for stacked PRs, and even 'rebase and merge' rewrites commits rather than fast-forwarding. - Splitting into stacked PRs doesn't eliminate the need for full integration testing when everything merges. **By community** - lobsters (mixed): Lobsters commenters are split between seeing stacked PRs as a legitimate workflow improvement and dismissing them as a band-aid over poor engineering discipline, with significant debate about whether they differ meaningfully from multi-commit single PRs. - hackernews (skeptical): The single HN comment immediately flags the cascading rebase problem when an early branch in the stack is rejected. **Hottest debate:** Whether stacked PRs offer a genuinely different review experience compared to multiple commits in a single PR, or are mechanically distinct but practically equivalent. **Open questions** - When a base branch in the stack is rejected, what's the least painful way to rewrite the entire dependent stack? - Should GitHub natively support fixup commits at merge time to avoid the need for stacked PRs altogether? - Is there a way to give reviewers an overview of the full feature design before they start reviewing individual stacked PRs? **Highlights** > Discussion about stack branches have been popping up more and more frequently recently, and I really disagree with them! Has anyone got any specific thoughts on the following? 1) They fundamentally don't address the problem at hand - The feature you are implementing is too wide-reaching/too poorly planned/etc, and you are applying a salve instead of practising good engineering principles. 2) Once all the PRs in the stack are ready to be merged, you have an arduous process ahead of you of sufficient testing. This feature was already determined to be too large for a reviewer to competently review, but now you will have to test/QA for all integration issues in one large change! 3) The reviewer has no concept of the overall implementation until all reviews are completed. I _frequently_ review stacked PRs that I end up pushing back because the overall approach cannot be seen from the "base" PR of the stack, and when you get to PR 3 in the stack, you see that the data structures introduced in PR 1 are not the best fit. These problems have all been long-addressed, by simply planning, and using feature flags/versioning. If your feature is enormous, and you want to split it into stacked PRs, you should have some form of design doc/ADR/similar to document the structure of the feature. This should be reviewed separately and prior to the code implementation. Secondly, you should implement each PR in the "stack" in a sensible, testable manner. For example, adding your data structures/models first, which allows you to be unblocked on 5 additional changes of adding API endpoints. If there is a frontend component, then implement a very thin sliver that allows the new functionality of the feature to be tested end-to-end in each individual PR. Put this behind a feature flag and merge it to your main branch on approval. I'm sure that there are valid uses of stacked PRs, but by and large, I think they are just being used as a means of accommodating poorly thought out features, often LLM driven. > — [conor on lobsters · 2 points, 1 comments](https://lobste.rs/s/2shapa/make_reviews_possible_again_with_this_one#c_5bu8in) > GitHub-style PRs make it unwieldy to iterate on PRs that are thousands of lines long, even if you could break it up into a series of well-reviewable patches. You also can't 'rewrite'/update a previous commit without destroying attached review history, so you tend to see lots of 'addon' commits being added 'Fix X in response to review feedback' etc etc. It makes it hard to keep track of, whereas it would be logically quite a bit nicer to have new 'versions' of commits so that I can review entire logical changes at once — even after it's been tweaked following a round of review. (I saw a good blog post that mentioned 'interdiffs' just a few days ago I think, I regret that I can't find it again to link it here) At the end, with the commit history being so messy, you also get incentivised to squash merge, whereas it might be nicer to have a small number of clean commits instead. (You can then see why some people prefer a 'patch series-driven' workflow, which as far as I can tell is essentially what stacked PRs approximate) Another argument in favour of splitting PRs up: PRs are the unit of merge on GitHub and similar; sometimes a PR is structured such that it would be acceptable to land the first 1, 2, 3 (whatever) commits before the entire suite of work is ready. In cases like those, you can see why you might stack PRs and merge them incrementally. [In a sense, is the tension here that PRs are both the unit of merge and the unit of review?] > — [reivilibre on lobsters · 2 points, 2 comments](https://lobste.rs/s/2shapa/make_reviews_possible_again_with_this_one#c_w66vgt) > I’m sort of unconvinced here. What does this approach give you over creating one PR with multiple commits and telling people to review the commits? > — [nick4 on lobsters · 2 points, 5 comments](https://lobste.rs/s/2shapa/make_reviews_possible_again_with_this_one#c_fozpxx) > > applying them at merge time (maybe stubbable with a merge bot like what the Rust project uses) It's honestly crazy that GitHub doesn't do this! And while I'm on the subject, "rebase and merge" in GitHub still doesn't do a fast-forward merge, it rewrites commits. Maybe there's a good reason for it, but I don't understand how GitHub still drops the ball on what should be core functionality. > — [nick4 on lobsters · 2 points](https://lobste.rs/s/2shapa/make_reviews_possible_again_with_this_one#c_wbfrla) **Source threads** - [lobsters](https://lobste.rs/s/2shapa/make_reviews_possible_again_with_this_one) · 4 points · 25 comments - [hackernews](https://news.ycombinator.com/item?id=49067853) · 1 points · 1 comments ## Community discussion Top comments from developers on daily.dev. **@rzaasadov** · 0 upvotes > This feels like a natural workflow for AI-assisted development. Generating code is easy but organizing it into small, reviewable, and logically separated changes is where AI can provide even more value. ## Similar posts on daily.dev - [Build Wide, Ship Narrow](https://daily.dev/posts/build-wide-ship-narrow-ubltyfimm) · Hacker News · 0 upvotes · 0 comments - [GitHub adds Stacked PRs to speed complex code reviews](https://daily.dev/posts/github-adds-stacked-prs-to-speed-complex-code-reviews-ufanab95z) · InfoWorld · 0 upvotes · 0 comments - [AI Code Review Bottleneck 2026: Why PRs Are Stuck in Review](https://daily.dev/posts/ai-code-review-bottleneck-2026-why-prs-are-stuck-in-review-o7qcycgq0) · Alex CloudStar · 2 upvotes · 1 comments - [How to review AI generated PRs](https://daily.dev/posts/how-to-review-ai-generated-prs-50unq3881) · thoughbot · 1 upvotes · 0 comments --- Tags: [#ai-coding](https://daily.dev/tags/ai-coding), [#code-review](https://daily.dev/tags/code-review), [#git](https://daily.dev/tags/git) [View this post on daily.dev](https://daily.dev/posts/make-reviews-possible-again-with-this-one-simple-trick-bagkdzx2a) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Make Reviews Possible Again With This One Simple Trick","url":"https://daily.dev/posts/make-reviews-possible-again-with-this-one-simple-trick-bagkdzx2a","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/make-reviews-possible-again-with-this-one-simple-trick-bagkdzx2a"},"datePublished":"2026-07-27T14:34:00.129Z","dateModified":"2026-10-14T02:23:27.743Z","description":"AI-generated code tends to produce large, hard-to-review diffs. A practical solution is using stacked branches: breaking a monolithic branch into a sequence of...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/7c42ca8924f8b2dc989f37cd2b73cc74?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/7c42ca8924f8b2dc989f37cd2b73cc74?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/make-reviews-possible-again-with-this-one-simple-trick-bagkdzx2a","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"ai-coding,code-review,git","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Make Reviews Possible Again With This One Simple Trick"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/make-reviews-possible-again-with-this-one-simple-trick-bagkdzx2a","comment":[{"@type":"Comment","text":"This feels like a natural workflow for AI-assisted development. Generating code is easy but organizing it into small, reviewable, and logically separated changes is where AI can provide even more value.","datePublished":"2026-07-28T14:28:39.197Z","url":"https://daily.dev/posts/baGKdZx2A#c-eidjxuBcl","author":{"@type":"Person","name":"Rza Asadov","url":"https://daily.dev/rzaasadov","image":"https://media.daily.dev/image/upload/s--obkknPEU--/f_auto/v1784480937/avatars/avatar_BPb4HehqaZ95FfYqQyzvN?_a=BAMAMicg0"}}]} ```