Mjolnir: Automated Cross-Vendor Adversarial Review

A common pattern offered by tools like Codex and Claude is AI code review, with adversarial review arguably the most popular way to frame it. That is: treat the implementation in a given branch, PR, or diff as amateur or even hostile code that needs to be examined with a fine-tooth comb for every bug and every design problem. However, this sometimes runs from the same session you’re currently using, with the same model, from the same vendor — therefore with the same blind spots. So it will find a few bugs, or find some non-issues and elevate their status so that it finds SOMETHING, but I’ve found the quality of these reviews to be low overall, and really broken code slips through surprisingly frequently.

Others have noticed this and started doing something I think is fairly clever (and they’re quick to share their special trick for elevating vibe coding to new heights in Hacker News comments): they fire up a competing vendor’s model, point it at the PR, have it do an adversarial review — and end up finding 3–4 times more bugs. In my investigation of this tactic, I’ve found the quality of reviews done this way is a good deal higher: fewer false positives (assuming a capable model), fewer silly assumptions, fewer inexplicable blind spots. I’ve been using it by hand for important PRs for close to a year.

Why does this work better than using the same vendor tool? I have a few theories:

• Even the same vendor and model in a fresh session will often review better than the session you’ve been working in. There may be some silly assumption baked into the session that you never intended to give the model, quietly justifying a bad decision or tradeoff.
• Different models have different training data, different post-training routines, different people evaluating the quality — it’s like getting a fresh perspective, which was one of the main reasons to do manual code reviews in the human-powered era. Having a model evaluate its own work often gives you a reviewer that shares the implementer’s blind spots.

Now, as I said, I’ve been doing this for a long time, and it’s a lot of manual copy and pasting (see fig 1-1 below). The reviewer finds a load of problems; you paste the results into the implementer tool and tell it “there are these findings, fix the ones you think are valid, tell me why if you think they’re invalid,” and that works — but then you probably want the reviewer to review the fixes to see if they’re actually fixed, and you repeat this back-and-forth a few times.  The following mobius-loop-like diagram demonstrates this well:

It makes managing multiple threads harder and takes a fair amount of concentration, and it moves repetitive work to you instead of the LLM.

In my first stab at automating this, I stuck with the human-oriented PR-based workflow, but the two models often hit technical issues, and one of them would frequently get stuck trying to post a reply or a comment. Weirdest of all, they both post under your account — so you end up with a sometimes-public discussion between two models, both posting as you. It is weird and hard to follow.

Enter Mjolnir

With this you get:

1. Automated adversarial review, cross-vendor by default (when available). You pick your team: pure Claude, pure Codex, Codex coder with a Claude reviewer, or vice versa.

2. You configure an implementer model, a reviewer model, and subagents to do detailed role-based reviews based on SlopCop’s toolset.

3. Model selection is automated to be price-performance optimal for reviewers and for validation of the review — under the hood it literally picks the cheapest model on the Pareto frontier of benchmark data that clears a quality floor. But you can select your own models, and your own effort levels, depending on your budget and your appetite for accuracy versus speed.
4. The normal pattern is: implementation lands, subagents find issues, the reviewer validates and prioritizes them, your primary model implements fixes, and the process repeats until we have a solid implementation. You can observe all of this flowing through the UI as it happens and evaluate the found issues yourself in real time.

Here’s a live one, straight from the terminal. The implementer added the helper and then reported it lives at “fizz.py:64:66” — in a nine-line file. The reviewer caught the fabricated citation, a separate validator session confirmed it against the source, and the validated finding landed in the verdict:

The same flow streams into the browser viewer if you’d rather watch from your phone with Mjolnir Web — here the reviewer flags a stray .pyc file the implementer accidentally committed during a verification run, then the validation pass spins up to independently challenge the finding before it’s allowed to reach the implementer. In this case, it survived, downgraded in severity:

Once it’s done, you can confidently post that PR or do your QA without worrying about obvious misses. Best of all, you can spend your attention elsewhere while this is going on — no need to hand-hold the process with low-value copy-paste behavior.

Give adversarial review a chance with Mjolnir. I think you’ll find you have higher-quality PRs and more free time, as you waste less of it dealing with obviously silly implementations that got fixed by adversarial reviews.