Bugbot

You will like that it stays in its lane. It reads pull requests for logic errors and leaves formatting alone, which is the deciding daily trait, because a reviewer that comments on style trains your team to skim its comments and then they skim the one that mattered. Custom rules let you teach it the conventions your team argues about.

Pick it if you are already inside this ecosystem and want review on the same invoice. Pick Greptile when the bugs you miss come from context outside the diff.

The dangerous setting is the one that sounds responsible. Making this a required check means a non-deterministic reviewer holds a veto over shipping, and on the afternoon it flags something wrong the choice is between waiting and overriding a control you just told your auditors was mandatory. Teams resolve this by overriding routinely, which quietly retires the check.

What it does right: it reviews the diff rather than reasoning about the whole repository, which bounds what it can be confidently wrong about and keeps its comments anchored to lines someone actually changed.

1. The published figure counts flags that were resolved, not flags that were correct, and a comment dismissed by a reviewer may well be counted as handled. No denominator, no sample definition and no methodology link accompany it. 2. Reviews run on whichever model the vendor's pool offers rather than a pinned version, so two reviews of the same diff are not the same experiment.

Together those make the headline unreproducible in principle rather than merely unpublished. The observation: a company with this much telemetry could report a false-positive rate cheaply, and reports a resolution rate instead.

The strategic function is obvious once you see the packaging. Usage billing on individual plans makes it easy to try and slightly annoying to keep, while the same capability arrives bundled the moment a team signs, which converts a personal habit into an organisational contract. The distribution underneath is one of the largest installed bases in the category, and none of it had to be bought.

There is no acquirer here; the parent is one. Position: strong, and the review product is a moat around the editor rather than a business of its own.

One sentence on the demo: it found a real bug and one imaginary one. The commercial case is that this is not a new purchase, it is a line inside an agreement my procurement team already processed, so the security review, the data terms and the invoice are all settled work. At $2,400 a month for sixty it competes with a dedicated review vendor and saves us managing a second relationship. It attaches to pull requests as a check, so nothing changes in our pipeline.

Onboarding is a dashboard toggle. Approved.

There is no configuration surface I would recognise as one. I cannot supply a key, cannot run any part of this on my own hardware, cannot attach my own tool servers and cannot see which model reviewed my code on a given day. The extension point offered is a rules file, which lets me describe preferences to a system I am otherwise locked out of.

The grudging note is that review is one of the few places where a hosted service makes sense, since it runs against a hosted repository anyway. That is an argument about architecture, not about ownership, and I still own none of this.