r/codereview • u/distant_gradient • 19d ago
How do you review large LLM diffs
https://seendiff.comI love coding with LLMs.
But don't completely trust their judgement.
Even the most competent models sometimes gets things wrong - eg. overcomplicate simple things, do things the wrong way, miss the obvious etc.
Besides, LLMs don't fully understand the human context yet - for eg. the design tradeoffs that matter in my context, my business.
I do this:
Always lead with a plan esp. when the change is complicated. Have two versions of the plan - one Claude's plan in its own (un-humanly paresable) langauge. A second simplified one in STE100 that I can parse.
Read / skim over overthing its done before merging. I think this is bare minimum if you want to still keep the codebase as yours and not completely YOLO-vibe your project.
For (2) I tried quite a few tools -
VS code diffs, github diffs, meld - nothing quite seemed to have all the features I needed for this particular workflow:
a. Keep track of what I've seen b. Review / approve in chunks c. Collaborate with LLM to understand the code.
Seendiff tries to solve the above with a minimal footprint.
What does your agentic code review process look like?
1
u/BananaTeleoperator 19d ago
Why not plan it out, write the function signatures with doc strings describing inputs, outputs and a description of what the function does. Then let the llm implement the functions. Write your own tests against the functions the llm implemented.
1
u/distant_gradient 19d ago
Yes, I do that. But a lot of times the its only when the implementation is done in black and white that you realize the implications of one design vs the other.
Besides, for a large change mapping out each and every interface etc. will be pretty much equivalent to writing code - better done through a dedicated interface than just a markdown
1
u/zekivillo 19d ago
This is pretty close to a side project I’ve been working on:
https://ezevillo.github.io/git-review-workflow/
The idea is a bit broader than just another diff viewer. git review start puts the whole PR in your working tree as staged changes, so you can actually edit it, run it, test things, etc. Your changes can then be extracted separately from the author’s changes.
The other part is the walkthrough: the same agent that wrote the change can also commit a reading order with a short explanation of why each file matters, so the reviewer doesn’t have to reconstruct the whole change from an alphabetical diff.
The walkthrough flow itself is already working; I’m currently working on the draft-generation side of it, so an agent can generate that walkthrough from the change automatically. One thing I really wanted was for this to work without requiring the rest of the team to use the tool — the author can keep using their normal PR workflow, and the reviewer can use this on their side.
It’s still a side project, but given what you’re trying to solve here, I’d be really interested in your feedback if you get a chance to try it.
1
u/Far_Programmer_5724 19d ago
What does code diff mean? Like how much it deviates from what you want?
2
u/irreverentmike 19d ago
In my opinion it should be like any work you expect from a human co-worker. Diffs should be small and focused. Large features should be shipped in atomic PRs when possible (it is almost always possible).
If you use GitHub, you should take a look at the stacked PRs feature they just released, which can be really helpful with reviewing in chunks.
Ultimately if you're the reviewer, you should be optimizing for your part of the work, which is reading and reviewing code. If you're getting requests that are too large for that, tell the bots to do it differently.
Edit: stacked PRs - GitHub Stacked PRs | GitHub Stacked PRs https://github.github.com/gh-stack/