AI code review
The reviewer that shuts up.
SuperDiffs reviews your pull request, then throws away everything it cannot prove. Most PRs get a summary and silence. On the ones that matter, you get a comment worth reading.
- Free forever for open source
- No card to start
- Uninstall deletes your data
The retry path generates a fresh idempotency key, so a timed-out charge is retried as a new charge.
Failure scenario
Stripe accepts the first charge but the response times out. Attempt 2 sends a new key, Stripe treats it as a distinct payment, and the customer is charged twice for one order.
The problem
Most AI reviewers pay you in comments.
Independent audits of a leading AI code reviewer classified roughly 36% of its comments as noise — correct-looking, but not worth a developer’s attention. (see how we measure)
Share of comments judged noise
We do not print our own number here as a marketing figure. It moves every release, so it lives on the benchmark page with the dataset and the method that produced it.
Comment fatigue
A reviewer that comments on everything teaches the team to skim everything — including the one comment that would have caught the outage.
Muted, then uninstalled
The usual end state is a collapsed thread, a filter rule, and a cancelled seat. Noise does not annoy teams into paying attention; it annoys them into leaving.
Trust does not come back
After two false alarms the third finding gets the same shrug as the first two, even when it is right. Precision is not a nicety — it is the whole product.
How we are different
Three decisions the rest of the category skipped.
Every AI reviewer can find things. The hard part — the part that decides whether your team keeps the bot installed — is deciding what not to say.
A verification stage before anything is posted
Finding is the cheap half. Every candidate goes to a separate verification pass that re-reads the code it cites, demands a concrete failure scenario — inputs and state that produce a wrong result — and drops anything that cannot produce one. Dropped means dropped: not softened into “consider”, not filed under FYI.
It never re-posts something you already resolved
Each finding carries a strong fingerprint (path plus normalized snippet plus rule) and a weak one for when the code moves. Resolve a thread and it stays resolved through rebases, force-pushes and follow-up commits. The bot does not get a second opinion about a decision you already made.
resolved → fingerprint stored
force-push → re-anchored
same finding → suppressed
Accuracy we publish, including when it slips
Precision, noise rate and the release-over-release delta are on the benchmark page with the dataset and the harness that produced them. When a change makes the reviewer worse, that number goes up in public. It is the only claim on this site we can be held to.
How it works
Three steps, then it stays out of your way.
There is no dashboard to live in and no new review workflow to learn. The reviewer shows up in the pull request you were already looking at.
- 1
Install the GitHub App
Pick an organization or a single repository. SuperDiffs reads code and writes only to pull request conversations and checks — it cannot push to your branches.
contents: read · pull requests: write · checks: write
- 2
It reads the diff, and what the diff depends on
The changed hunks are pulled into a disposable sandbox with the surrounding definitions, your repository conventions, and — where you enable them — your own linters and SAST rules.
configured in .superdiffs.yml, committed with your code
- 3
It posts what survived verification
Inline comments anchored to the right line, each with a failure scenario and a committable suggestion, plus one summary and a check run. Everything else is dropped without a word.
typical PR: a summary, and nothing else
What you get
Built to be trusted on a Friday afternoon.
The features below exist to protect one thing: your willingness to read the next comment it posts.
Anchored, not top-levelled
A finding lands on the line it is about, or it lands on the file, or it is dropped. Nothing gets dumped into a wall-of-text summary comment because the anchor failed.
Committable suggestions
When the fix is unambiguous, the comment carries a suggestion block you can commit from the GitHub UI. When it is not, the comment says so instead of guessing.
Incremental by default
A push re-reviews the new commits, not the whole pull request. Findings you already dealt with are not rediscovered because you added a test.
Deterministic tools in the loop
Linters, type-checking and secret scanning run beside the model. Tool findings are the trusted tier: they carry the rule id that fired, not a probability.
It learns your conventions
Resolve a thread with a reason and it becomes a durable preference for the repository or the org. Suppression is memory, not a per-PR mood.
A prompt-injection boundary
Commands are honoured from identities with write access, checked against the GitHub permission API — never from PR descriptions, code comments or diff content trying to talk to the bot.
A comment budget you choose
Depth and volume are separate dials. Pick a profile and the reviewer is held to it — the cap below is enforced in the engine, not suggested to the model.
- quiet
- ≤ 10 comments · from major
- balanced
- ≤ 20 comments · from minor
- thorough
- ≤ 40 comments · from nit
Talk to it in the thread
Mention the bot in a comment to steer a review without leaving the pull request.
- @superdiffs review
- @superdiffs full-review
- @superdiffs summary
- @superdiffs resolve
- @superdiffs pause
- @superdiffs resume
- @superdiffs ignore
- @superdiffs config
- @superdiffs help
Excluded before you ask
Whole classes of finding are off by default because they generate volume without proven impact. Turn them on per organization if you disagree.
- denial-of-service
- rate-limiting
- resource-exhaustion
- input-validation-without-impact
- open-redirect
Design partners wanted
No logo wall here. We are new, and we would rather say so than borrow someone else’s credibility.
There are no customer counts, testimonials or logos on this site because we have not earned them yet. What we have is a reviewer we are willing to measure in public, and room for a small number of teams who want to shape it while it is still cheap to change.
What you get
- Team, free, for the first six months.
- A shared channel with the people writing the reviewer, not a support queue.
- Your noise rate measured on your repositories and reported back to you, monthly.
- Anything we learn from your repos that we publish, you see and approve first.
What we ask
- A real repository with real pull request traffic.
- Honest, specific complaints when a comment wastes your time.
- Half an hour a month to tell us what we got wrong.
FAQ
The questions we would ask.
What does a normal pull request look like with SuperDiffs installed?
A summary comment and a passing check. Most pull requests do not contain a defect worth a line comment, and a reviewer that pretends otherwise is the problem we set out to fix. When there is something, it arrives as one anchored comment with a failure scenario.
How is “verified” different from a confidence score?
A confidence score is the model rating its own work. Verification is a separate pass with a different job: re-read the cited code, produce inputs and state that make the defect happen, and fail the finding if it cannot. Findings that fail are discarded, not downgraded — the method is on the benchmark page.
Do you train models on our code?
No. Your code is used to review your pull request and nothing else, and zero-retention mode removes even the derived learnings. The retention windows, the subprocessor list and the deletion path on uninstall are in the trust center.
What happens when it is wrong?
Resolve the thread and tell it why. That becomes a stored preference for the repository or the organization, so the same class of comment does not come back — and the miss shows up in the numbers we publish rather than in a support ticket nobody reads.
Will it review every pull request from outside contributors?
It reviews them, and it never bills you for them. A seat is a pull request author on your team; bots and drive-by contributors are excluded from the count. See pricing for exactly how a seat is counted.
Which languages does it handle?
The reviewer is language-agnostic and the deterministic tool layer is not — linters, type checks and secret scanning are wired per ecosystem, and the supported list lives in the docs. If your stack is not covered by tools yet, you still get the verified model review.
Put it on one repository.
Install it where a noisy reviewer would annoy you most. If it talks too much, uninstall it — that removes your data too, and you can tell us exactly which comment lost you.