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.

▲

pksunkara a day ago | parent [-]

> Separate from the diff aspect of reviews, I would also appreciate some more control in a PR tool over how to layout a review

I am quite interested in knowing more about this. Would you mind give me a small example? Do you want to control individual hunks order or just files?

	▲	wizardmeridian a day ago \| parent [-]
		Individual files, for sure. I feel like plenty of times You have a changeset that involves an new/updated internal helper module of some kind, and also changes/additions to other places that use it, and its helpful to see them in a particular order, but file or folder hierarchies put things into a different order. I feel like a PR comment along the lines of "Look here [link-to-file] first" happens more than occasionally on my team. As for changing the display of hunks within one file, I think that could be interesting for a couple reasons (but I totally get that could be obnoxious to both build and present a UI for). I can try to dig up an example later, but off the top of my head there's two situations I've seen infrequently this might help with? (I'm sorry if I'm vague - I cannot share any of the code I do for work, which is 99% of the PRs I deal with). 1. A specific file was refactored in such a way that code was moved, deleted, and added, and the interpreted hunks together are intermingled. I feel like I see diffs where it's hard to tell what's going on because there are delete/addition/delete/addition blocks alternating, but they form separate contexts/actions (and often have different indentation levels or other styling quirks) it's just the diff algorithm displaying them poorly that is causing the problem. This is normally the spot where I might switch between a side-by-side diff viewer and a unified viewer, but sometimes neither is good. (This could probably be solved with more careful individual commits, although sometimes this is unavoidable). 2. We have a few large modules (singluar classes in 2000+ln files) that often have a wide public interface, with multiple functions eventually calling the same internal helper (a trivial example would be a multiple separate search functions providing different kinds of windows/orderings/etc of a data source, sharing an private function that really does most of the main work), but this private function is not first in the file. It'd be helpful to order this to be seen first - "here's what I changed' followed by 'here's how it is used now'. Maybe what I want could just be solved with a commit-by-commit ordering of things, but just showing multiple commits together on screen, with later commits coming further down the page (as opposed to showing the whole unified diff of a group of commits - Github does that, and that is pretty much never what I want other than 'what's changed since I last saw this'). I can attempt to find some specific examples later this week and try to explain these situations clearer if the above is confusing.