Reviewing large changes with Jujutsu

Funnily enough this is roughly the review system I've started using as well, but with git instead of jj. When I need to review someone's work (be it agent or colleague), I'll pull it, reset changes until the base branch, and go through it with VS Code or Zed's diff view, staging code as I go along. I take notes in a markdown file as I write and post it to GitHub using claude code to format it correctly (note that claude doesn't write any of the review - it just handles the busywork of formatting it into comments and review body). I won't say this flow is perfect as I still have to use VS Code, but that's mostly because I've not been able to replicate this flow in neovim.

Recently I’ve started to cultivate a new workflow while reviewing code. With the growing use of coding agents, the size of pull requests seems to be increasing. Whether or not that’s a good thing is another matter, but I still need to stay abreast of the new code being introduced, and for now, therefore, I need to review it.

There’s a certain artistry to making a code change that minimizes diffs.

• Instead of wrapping a whole function with a try-catch or tracer, rename it and make the old name wrap the newly renamed function.
• refactor large chunks of code into functions in the same order it was originally written in
• don’t make unnecessary changes — LLMs really struggle with this
• decompose changes into multiple commits or PRs
• separate refactors and nits from the core changes, and comment on the important bits so people can focus on the right stuff. People gladly approve “refactor” PRs with a lot of trust if it looks right

People still seem to respect a nice clean PR, and don’t realize how much slower a messy PR takes to get merged. I use LLMs to generate the final product but I spend a lot of my time making the code-change reviewable. Even AI code review products perform better on smaller PRs.

There's a general pattern I like: to really study something, copy it bit by bit from one place to another.

I've had it happen before with extracting code out of a big ugly blob and into its own library. Magically, the parts that I had to move seemed to just fall into place, and I could understand the connections between them, and clean up the issues that had become obvious during the move.

One of the nice things about the author's workflow is it lets you move code around without changing its location in the file tree. Now I'm wondering if I could do the same trick to sift through the rest of that blob of code.

Nice! I might actually adopt this exactly as described.

Now we can review the code in whichever tool we're most comfortable with

What are you guys using? I'm usually just going back and forth between the Github UI and Helix or vim, but I'd love something for the terminal that also allows me to jump to definitions and such.

Is there any way to squash (or generally: interact with) individual "hunks" within the same file when using jj? As far as I know, jj's granularity is at the level of a file?

Imagine a single large file with many changes. I want to go through the various changes and, one by one, squash them rather than all at once or none.

The article only squashes entire files, not individual parts/changes of the same file.