How a review works
The four stages of a DiffGuardian review — local diff, whole-repo resolution, feature split, and explained findings.
A DiffGuardian review is not a line-by-line pass over a patch. It is a structured read of the change in the context of the repository it lands in.
#The four stages
#1. Read the diff locally
The diff is read from your local git checkout. It is never uploaded to DiffGuardian.
This works for a pull request from your code host and, equally, for uncommitted work on a branch or a worktree — there does not have to be a pull request for there to be a change worth reading.
#2. Resolve it against the whole repository
DiffGuardian maintains a local index of the repository — a code knowledge graph of symbols, call paths, and dependencies. The change is resolved against that graph, so the review can see the ripple effects and contract breaks that a diff-only read slips past: the caller three files away that now receives a different shape, the assumption a helper was relying on.
#3. Split the change into features
A large pull request is rarely one thing. DiffGuardian decomposes it into the discrete features it actually ships, so you review a change you can hold in your head rather than forty files in file-name order. Trace It is how you step through them.
#4. Explain and flag
For each feature you get:
- A plain-English summary of what changed and why it appears to have changed.
- Findings — bugs, security concerns, and code-quality problems, each anchored to the file and lines that produced it.
- Structure — dependency graphs and stack maps drawn from the real call graph, so you can see the blast radius before you approve.
#Controlling how hard it looks
Settings → Features holds the dials:
- AI review effort — Quick, Medium or High. The higher settings run extra passes: a planner that decides where to look before the deeper passes run, and a checker that tries to disprove each finding so fewer false alarms reach you.
- Let the reviewer investigate the code — lets the review search the repository, read files it needs and check who changed a line, so it can catch breakage outside the diff. It costs noticeably more tokens and works with Anthropic and OpenAI models.
- Skip AI for small diffs — below a changed-line threshold you set.
- Automatic AI — when off, DiffGuardian never calls a model on its own. Summaries, the features list, diagrams and per-hunk overviews wait for you to press Generate. Cached results still appear, and Ask, Explain and any Regenerate button keep working.
On the Basic plan, AI reviews are metered at 5 per calendar month; everything above is otherwise identical on both plans. See Plans.
#Reading the results
Every finding cites its source. Follow the citation before you act on it: the point of DiffGuardian is that you end up understanding the change, not that the model has an opinion about it.
Findings are generated by a language model and can be wrong or incomplete. Treat them as a well-informed reviewer's first pass, not as a verdict — see the AI Disclaimer in the app for the full statement.
#What DiffGuardian never does
- It does not approve, merge, or close anything on its own. An AI review produces suggested comments; they reach your code host only when you adopt them and submit the review yourself, under your own token — see Writing review comments.
- It does not act in the background. Every posting action is one you took.
- It does not send your code to DiffGuardian's servers, on any plan.