You're paying too much for code review

I wrote in August that humans shouldn't spend their time reading code anymore. (TLDR: the opportunity cost isn't worth it.)

That doesn't mean that you should dispense with code review entirely. It just means that you should have agents perform the reviews (as well as other forms of agentic QA). But which agents? There are more companies offering hosted code review than you can shake a stick at.

So I took the unscientific but popular approach of examining the data I already had close at hand; specifically, PRs submitted to Jeff Dickey's Rust cache Mr. Boxington (which every developer working in Rust should use).

Jeff has three reviewer products wired up: Greptile, CodeRabbit, and Cursor Bugbot, all of which have generous free plans for open source projects. I also tested the open source Kodus reviewer, which offers a low cost bring-your-own-keys hosted option as well as host-your-own, and Mjolnir's in-harness reviews.

Here's how they did across 95 pushes of 47 PRs (that is, on average two pushes of each PR were reviewed before merge):

A "material finding" means primarily incorrect, user-observable behavior, but also performance regressions or tests that don't test what they purport to test. False positives include "the problem was deemed not important to fix" as well as actual incorrect findings.

In short: all systems are able to find material problems without drowning in nitpickery; that problem from six months ago is solved.

Simpler can be better

Mjolnir and Kodus are both powered by DeepSeek Flash (high effort), but Kodus is throwing in a ton of extra context and structure while Mjolnir is just using vanilla DeepSeek Harness with a prompt lifted from Codex's /review command.

While code diving Kodus to understand how it made DSF so much worse, Opus and I found a bunch of issues, but nothing that obviously looks like "if only this were fixed, Kodus would outperform the simpler design."

Turns out a smart model armed with bash is pretty hard to beat for code review as well as for authoring. (Mjolnir also had a more complex reviewer with multiple subagents and fancy tools until about a month ago; in early 2026 this improved review quality, but re-testing with modern models failed to find any improvement over the simple approach tested here.)

Simpler can be cheaper

Mjolnir-powered-by-DSF performs roughly equally to Greptile at about 1/20 of the price. Someone should wire this up as a service for teams who want reviews to run in CI instead of their coding harnesses.

No reviewer is perfect

Each reviewer found defects that the others did not. It turns out that you can recover many of these with multiple passes of the same reviewer as well; here is what that looks like for the Mjolnir reviews:

Clearly there's diminishing returns, but "run multiple reviews in parallel and union the findings" seems like an underappreciated option. What if you have money to burn?

I've shown DeepSeek Flash as the Mjolnir (and Kodus) reviewer model because of its unique place on the cost:intelligence spectrum when you're paying API prices, but can you get better reviews if you're willing to pay more?

It turns out that: no, you can't: DeepSeek is freakishly good at code review. But if you're willing to accept slightly fewer bugs spotted, Terra is 6x faster as well as meaningfully less expensive. (Because DeepSeek's massive advantage in cache hit pricing is less meaningful in a relatively brief code review session, while Terra's output-token-frugality is more meaningful.)

Conclusion

Adding agentic review to your development process will almost certainly catch real bugs for minimal effort; you can pay a bunch of money for a hosted service, or you can use Codex /review for results that are just as good and a lot cheaper. If you don't use Codex, or if you want your harness to automatically perform a review before pushing, try out Mjolnir. After this evaluation, we've updated its defaults to two parallel reviews and its Auto model priority order to Terra > DSF > Haiku.

Appendix: How this evolved / what I'd do differently

I'm trying to write more articles to keep up with the faster pace at which I can now run experiments like this with the help of LLMs, without relying on AI to do the writing for me. That means I'm going to ship some articles with loose ends that would take longer to clean up than I can now justify. To satisfy my OCD and perhaps yours, I'll document some of the loose ends in this piece here:

1. I did almost all of the work before Terra was released. Then when it came out, I added it to the test mix, and it turned out to be really good. Terra is now the highest priority review model in Mjolnir, but I didn't go back and rebuild the main mj and Kodus comparisons on Terra.
2. I was sloppy with my data mining and did all the mj testing against the 47 PRs from the (at the time) most recent 30 days of mbx activity before realizing that Bugbot only had results on some of those. (It's enabled for Jeff's account only.) So ideally I would rerun all the other models against the Bugbot set; instead, I just ran the Greptile and CodeRabbit live-data-eval code against the Bugbot ticket and used that commonality to extrapolate "here's how Bugbot would have probably done" on the "main" 47.
3. The first mj/DSF review found 43 material defects, so that's the number I used both in the first comparison chart and the diminishing-returns chart. But 43 is unusually low, that run just got unlucky, and using the median of 52 would be more correct.