A reviewer that has read the codebase.
Most automated review is pattern-matching on a patch with no idea what the rest of the system does. This one has the repository checked out and the tests running, so it can go and look.
Findings you can check, not opinions.
Because it can build and test your code, its comments come with proof. If it says a change breaks something, it can name what. If it says a case is untested, it can write the test that fails.
Comments land in your own pull requests, under a name your team recognises, so nobody is guessing where a review came from. Behind each one you can see exactly what it ran and read to get there.
Where you allow it, the fix arrives as its own pull request rather than a suggestion — under the same rules as everything else, so it still cannot merge anything itself.
- · Run your test suite against the change, and against what it replaces
- · Follow the change out to the callers it affects, beyond the files in the diff
- · Check it against decisions your team made before, and say which one
- · Write the failing test for a case the change does not handle
- · Flag a change that reaches production with no way back
- · Open the fix as its own pull request, where you allow that
It gets better at your codebase specifically.
It remembers your decisions
Why a module is shaped the way it is, which approach was tried and dropped, which pattern your team settled on. So a review can cite the decision rather than re-open the argument.
Corrections stick
When a reviewer overrules it, that sticks and is attributed to them. Nobody has to make the same correction on next week's pull request.
It stays inside your walls
What it learns about your codebase never reaches another customer. That rules out learning across customers on purpose — the alternative does not survive a security review.
A reviewer that comments on everything gets muted.
The way automated review fails is volume. Fourteen comments on every pull request and your team stops reading it within a fortnight — at which point it is worse than nothing, because people have learned to scroll past.
So what it comments on is something you set and change, and you can see whether a change made reviews more useful or just louder. Most teams start narrow — one kind of finding, on one repository — and widen when the signal earns it.
Point it at a pull request you already reviewed.
Ideally one a person has been through, so you can compare. That comparison is the fastest honest read on whether this is useful for your codebase.