Noon van der Silk - Make Reviews Possible Again With This One Simple Trick

Noon van der Silk

About<br>Archive<br>Between Books<br>Talks<br>Links<br>Atom Feed

Make Reviews Possible Again With This One Simple Trick

Posted on July 24, 2026

by Noon van der Silk

A stack of branches.

You might’ve already guessed what it is: stacked branches. But if you didn’t<br>already know that, don’t worry, we’ll go over it shortly.

But first, let’s discuss the problem.

AI-generated code is hard to review

Pretty much everyone using AI has this problem at the moment; it’s moderately<br>easy to generate code that is mostly coherent, mostly tackles the problem<br>you’re solving, and in fact it’s so easy, we mostly get a little over-excited<br>and do too much at once: this makes code hard to review.

This is creating stress on the reviewers, on several fronts. There’s just the<br>plain apathy of staring a giant diff that probably does what the author<br>says, even passes your test suites, but also probably contains some<br>quirky/not-your-codebase’s-idiom things that you’d challenge if you were<br>motivated.

There’s also the loss of knowledge; it’s just straight-up extremely difficult<br>to read such large pieces of work and understand everything. Especially when<br>you can’t totally trust that every line and comment comes from some deep<br>fundamental understanding of the (human) author.

There’s many other problems; not all of which will be addressed by this idea;<br>but the key idea here that we will go for is: less is better. It’s easier to<br>review something when the amount of changes are small; and when you can focus<br>on just thinking about “one thing”, while performing any specific review.

Standard techniques

There are many and ever-growing techniques to deal with this problem:

Just add more tests: Theory is, if it works then It Works. This can be<br>risky or great, depending on your testing infrastructure. But we all know<br>that tests don’t cover everything that it’s possible to express with code.

Just do less: Just have smaller PRs. This is hard, because it seems modern<br>AI systems tend to be a little bit purposefully addictive/gamified: they’re<br>often finding new things to do while doing a piece of work. It’s also at<br>odds with most work pressures: deliver more better faster.

Group-reviews: Get everyone on a call (or in person?!), and talk through<br>the code. This can be useful, but you can’t do it for everything. Also, it<br>doesn’t work for some team members and thinking styles.

Author and merger responsibility: You can just make a declaration, that,<br>say, if a (big) PR is found to introduce a bag big or some misunderstanding,<br>you just fire the author the and merger. Or maybe something less drastic,<br>like downvote them on their performance reviews. In any case, this one is<br>punitive and pressure-based. It makes authors and reviewers more nervous;<br>and doesn’t really empower them in any meaningful way. Ultimately, it will<br>just slow you down, and upset people.

Stop caring, the market will decide for you: Does you product get better?<br>Do things work? Are you getting more features? Then who is really to say<br>what is “correct”? Isn’t the ultimate arbitrar of truth the users anyway?<br>Shouldn’t we just get more things in front of them as fast as possible?

Obviously, this framing is both correct and crazy. In theory it’s true that<br>only visible functionality matters; but it’s also true that something can<br>be visibly accurate but wildly off in ever-so-slightly different<br>circumstances. We’re not yet at the point where it’s possible to operate<br>this way. Maybe we’re approaching this with better-tested ecosystems and<br>the combination of theorem provers in connection with code; but ultimately<br>we’ll always need to review our stated intention, even in that promised<br>land.

So let’s just agree that, for the short term, we’re going to need<br>some kind of human review.

Actually no, just let AI review it: Naturally, we can just have the AI<br>perform it’s own review. Pragmatically, this can be very effective,<br>certainly for catching missed things, bugs, security issues, etc. But I<br>feel for gaining certainity that what you asked for is actually done<br>correctly, we’re still going to want some oversight.

Let’s then see an old idea that can still be compatible with any of these<br>approaches, if we so wished it.

An old idea: create stacked branches

I’m not inventing stacked branches here. Many many people love them, there’s<br>jj, created in part to get more joy from<br>them, and startups focused around the idea.

A stacked branch is conceptually simple:

Think about the large bit of work you did,

Break it into (coherent) chunks (each one perhaps passing CI alone),

Create a branch per chunk,

Have each branch depend on the prior one: 1 ← 2 ← 3 ← …

Submit them as PRs in that order

Now, you have each coherent change readable by itself; they can be merged in<br>order, and everything will be fine.

You can read more here.

The new workflow

Manually maintaining stacked branches is a little annoying. Yes you can...