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.
If you're changing how you would otherwise write code in order to avoid changing an indentation level, maybe instead switch from git diff to git diff -w so mere indentation changes don't pollute your view of the diff?
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.
One thing I want to do on top of this is to be able to put "comments to post" inline.
Something like:
# REVIEW: This line seems a bit odd to me
And then be able to call some CLI command and have those lines pushed over into "git forge" land as commands.
I have been, for larger changes, doing this kind of squashing (tho I actually end up doing jj split) and it works well enough but making comments tends to break the flow a bit for me.
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.
Also if you prefer the interactive git approach someone came up with a way to get that in jj as a configured merge tool, see https://zerowidth.com/2025/jj-tips-and-tricks/#hunk-wise-style. I have this configured locally (though I skipped the ui.diff-editor setting) so I can opt into it when I want to, which I typically only do if I want to use git's support for editing the diff hunk on the fly.
Ah. I never knew that jj's default diff-editor (the TUI one) let's you see individual hunks/changes of a file by using the left-arrow and right-arrow keys.
Because the default TUI tool was confusing and inconvenient, I switched to a different diff-editor (neovim with https://github.com/julienvincent/hunk.nvim). And this setup wouldn't give me hunk-level granularity either.
Thanks for the feedback, everyone!
Edit: This thread prompted me to re-visit hunk.nvim and better understand its keybinds. It finally clicked, and I do know now how to toggle hunks with it!
BTW, in addition to the builtin TUI for jj split, you can tell it to use any diff tool instead. You edit the diff it presents, deleting the parts you want to be in one commit, and everything left over goes into the other commit.
Yeah, I was aware of that. But that pushed me into a hunk-less corner:
Because the default TUI tool was confusing and inconvenient, I switched to a different diff-editor (neovim with https://github.com/julienvincent/hunk.nvim). And this setup wouldn't give me hunk-level granularity either.
So now I am back on the hunt for a better diff-editor than jj's default TUI one.
Edit: This thread prompted me to re-visit hunk.nvim and better understand its keybinds. It finally clicked, and I do know now how to toggle hunks with it!
One of the things I really like about magit is its ui for staging. I can stage a file by moving my cursor to the filename line and pressing “s”, or a hunk by moving to the hunk header line and pressing “s”, or I can highlight part of a hunk and stage just that. When I make a mistake I can highlight that part of the staged diff and press “u” to unstage it.
It isn’t so easy to move hunks between commits: that requires rebasing then using stage/unstage to split or amend commits. It would be really nice to have something like magit’s staging ui that works across multiple commits.
Neat. I have a technique that I use where I get codex to add a bunch of missing context as comments on all the touched areas (using an opinionated documentation pass skill). I've generally been looking at that as just an extra change which sometimes makes sense to push to the PR, but it breaks down a bit when reviewing PRs that have multiple commits as you can often only review just a single commit at once. This was the missing piece to make that really easy to review.
square_usual | 20 hours ago
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.
markerz | 19 hours ago
There’s a certain artistry to making a code change that minimizes diffs.
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.
0x2ba22e11 | 10 hours ago
If you're changing how you would otherwise write code in order to avoid changing an indentation level, maybe instead switch from
git difftogit diff -wso mere indentation changes don't pollute your view of the diff?mariusor | 3 hours ago
Sure, but I think there's a difference between "not polluting the diff" and "not being in the diff". :D
Small diffs make clean commits...
bitshift | 18 hours ago
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.
rtpg | 16 hours ago
One thing I want to do on top of this is to be able to put "comments to post" inline.
Something like:
# REVIEW: This line seems a bit odd to meAnd then be able to call some CLI command and have those lines pushed over into "git forge" land as commands.
I have been, for larger changes, doing this kind of squashing (tho I actually end up doing
jj split) and it works well enough but making comments tends to break the flow a bit for me.erock | 14 hours ago
Similar to how git-pr is setup: https://pr.pico.sh
casperin | 17 hours ago
Nice! I might actually adopt this exactly as described.
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.
ClashTheBunny | 29 minutes ago
I use vim with something I cobbled together using:
https://github.com/LunarVim/Neovim-from-scratch
But they link to the newer and possibly more maintained basic IDE.
gdon a symbol goes to the definition for me. It's all LSP based, so I guess it depends on how esoteric the language is...miguno | 17 hours ago
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.
sfink | 16 hours ago
jj squash -iakajj squash --interactive. You can select at the file/hunk/line granularity.jj splitandjj diffeditalso work at any granularity.lilyball | 14 hours ago
Also if you prefer the interactive git approach someone came up with a way to get that in jj as a configured merge tool, see https://zerowidth.com/2025/jj-tips-and-tricks/#hunk-wise-style. I have this configured locally (though I skipped the
ui.diff-editorsetting) so I can opt into it when I want to, which I typically only do if I want to use git's support for editing the diff hunk on the fly.miguno | 2 hours ago
Ah. I never knew that jj's default diff-editor (the TUI one) let's you see individual hunks/changes of a file by using the left-arrow and right-arrow keys.
I only saw this:
instead of this, after typing right-arrow:
Because the default TUI tool was confusing and inconvenient, I switched to a different diff-editor (neovim with https://github.com/julienvincent/hunk.nvim). And this setup wouldn't give me hunk-level granularity either.
Thanks for the feedback, everyone!
Edit: This thread prompted me to re-visit hunk.nvim and better understand its keybinds. It finally clicked, and I do know now how to toggle hunks with it!
dozens | 16 hours ago
Yes, with
jj splithttps://docs.jj-vcs.dev/latest/cli-reference/#jj-split
wrs | 13 hours ago
BTW, in addition to the builtin TUI for
jj split, you can tell it to use any diff tool instead. You edit the diff it presents, deleting the parts you want to be in one commit, and everything left over goes into the other commit.miguno | 2 hours ago
Yeah, I was aware of that. But that pushed me into a hunk-less corner:
So now I am back on the hunt for a better diff-editor than jj's default TUI one.
Edit: This thread prompted me to re-visit hunk.nvim and better understand its keybinds. It finally clicked, and I do know now how to toggle hunks with it!
[OP] fanf | 2 hours ago
One of the things I really like about magit is its ui for staging. I can stage a file by moving my cursor to the filename line and pressing “s”, or a hunk by moving to the hunk header line and pressing “s”, or I can highlight part of a hunk and stage just that. When I make a mistake I can highlight that part of the staged diff and press “u” to unstage it.
It isn’t so easy to move hunks between commits: that requires rebasing then using stage/unstage to split or amend commits. It would be really nice to have something like magit’s staging ui that works across multiple commits.
joshka | 14 hours ago
Neat. I have a technique that I use where I get codex to add a bunch of missing context as comments on all the touched areas (using an opinionated documentation pass skill). I've generally been looking at that as just an extra change which sometimes makes sense to push to the PR, but it breaks down a bit when reviewing PRs that have multiple commits as you can often only review just a single commit at once. This was the missing piece to make that really easy to review.