Show HN: Perspica – A semantic diff for reviewing code

[sshah03]

https://github.com/sshah03/perspica

I started using this a little over half a year ago to help me navigate through some large AI coded PRs people were submitting, because I felt like if I looked at the PR on Github I would just auto pass it through because I didn't want to deal with it. Thought I'd clean it up and share it in case this style of review was useful to anyone else.

Obviously it relies on an LLM run to get true semantic groupings of what changes were done, and why, but can also be used without an LLM to get more mechanical groupings/group names of changes made, along with the right order to view them in. The manual tree-sitter parsed analysis is deliberately conservative for now, but if people want to avoid the LLM analysis I can spend more time on that.

You can use it for other peoples PRs, or for your own when you've relied heavily on Claude Code or Codex for that particular PR. If the change came from your own Claude Code or Codex session, it reads your prompts and marks which changes you asked for and which the agent decided on its own as well to help you validate it before submitting for others to review.

Demo video done on some public project PRs is in the repo; for a look at what it looks like when it pulls in information about your own claude/codex sessions you'll have to use it yourself for now, but I'll work on getting an example of that up soon so people can take a look before spending time to get this to work locally for themselves.

I also added support for perforce style side by side diffing because I always kind of liked it, though it's not quite as slick yet.

[vivekpolavarapu]

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

[sshah03 → vivekpolavarapu]

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.

[sshah03]

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.

[jacobn → sshah03]

Neat! Scala support would be great, thanks!

[sshah03 → jacobn]

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.

[xcc3641]

Matching renamed and edited functions across files risks high false-positive rates. What similarity threshold determines fallback to line diffs?

[childintime → xcc3641]

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.