I have been thinking about a similar “semantic diff” approach to code reviews for the past several weeks. I’d love to hear more about how you’re approaching this - there’s a handful of distinct scenarios I see frequently in PRs that I think should be reviewable in a more direct form (renames, moving blocks of code between files without changing the text, whitespace changes, etc - basically any action a modern IDE can do deterministically).

I’ve played with some bookmarklets that modify the GitHub PR ui and attempt highlight these situations, but my setup is brittle (just trying to identify basic patterns in the text diff, ex “these are [oldname] replaced with [newname]”, which is not necessarily the same thing as an IDE rename-this-function action). I’ve been wondering if the answer here is in doing a diff on a compiled intermediate form of the program, visualized in some way - this would have to be language-specific though, I guess, and is well outside my expertise.

Separate from the diff aspect of reviews, I would also appreciate some more control in a PR tool over how to layout a review (what files/hunks to be shown, in what order). My team attempts to do this with carefully organized commits, so that reviewers step through them one by one, but the GitHub UI leaves a lot to be desired here (files appear in a static order top to bottom; comments and discussions can’t be stuck to one commit and show up in other commits; general bugs in the web view). I would appreciate being able to control how others see my PR if there’s room for that in your product.

Anyways, I joined your waitlist and am curious to see what you come up with - I think there are improvements to that can be made to code reviewing (that don’t involve AI - everyone is already putting AI review in their PRs), and am willing to try anything that takes a swing at that.

>1. Hunk checkpoints

How long are your files that you can't easily "finish" a file?

Y'all are still reviewing code?

(Semi serious here.)