Interesting! Will try it out. The semantic diff makes it easier for the reviewer to understand what is being shipped. This could work well with the Panel Review we shipped recently -- It reviews the agent's riskiest changes with an AI panel. This reduces blindspots and minimizes agent mistakes. More here: https://truverif.ai/panel-review
Looks interesting! I was trying to figure out a good way to add some of the benefits of this right into the actual gh review flow, but haven't quite figured out the smoothest way to do it yet.
If you're interested in using this, but your language of choice is presently unsupported, just leave a reply here with the language and I'll prioritize adding it. Also any other requests, or suggestions that would make this genuinely useful to you as well.
It's a lot stricter across files, than within a file. Within a single file, it labels as renamed/edited when the old and new are 75% the same code (ignoring formatting) along with a couple of other rules. Across files, it pairs code that's identical, or at minimum kept the same name and is at least 60% identical, if it was renamed in addition to being edited+moved it's never matched.
There's no similarity-based fallback to a line diff because the line diff is always there. These labels sit on top of it, so a wrong label can't hide anything, and you can see both sides of any match it claims.
Admittedly those percentages are a bit arbitrary, and I probably need to think about it a little bit more. If you do run into issues with it, please let me know.
Interesting! Will try it out. The semantic diff makes it easier for the reviewer to understand what is being shipped. This could work well with the Panel Review we shipped recently -- It reviews the agent's riskiest changes with an AI panel. This reduces blindspots and minimizes agent mistakes. More here: https://truverif.ai/panel-review
Looks interesting! I was trying to figure out a good way to add some of the benefits of this right into the actual gh review flow, but haven't quite figured out the smoothest way to do it yet.
If you're interested in using this, but your language of choice is presently unsupported, just leave a reply here with the language and I'll prioritize adding it. Also any other requests, or suggestions that would make this genuinely useful to you as well.
Neat! Scala support would be great, thanks!
Thanks! Added enough that you should be able to give it a try. I'll work on improving Scala support over the next few days.
Matching renamed and edited functions across files risks high false-positive rates. What similarity threshold determines fallback to line diffs?
Quoting the reply of the author, as he was dead:
It's a lot stricter across files, than within a file. Within a single file, it labels as renamed/edited when the old and new are 75% the same code (ignoring formatting) along with a couple of other rules. Across files, it pairs code that's identical, or at minimum kept the same name and is at least 60% identical, if it was renamed in addition to being edited+moved it's never matched.
There's no similarity-based fallback to a line diff because the line diff is always there. These labels sit on top of it, so a wrong label can't hide anything, and you can see both sides of any match it claims.
Admittedly those percentages are a bit arbitrary, and I probably need to think about it a little bit more. If you do run into issues with it, please let me know.
[dead]
[flagged]