Steering the Vibe: Adversarial Review

I’ve personally experienced the cognitive toll and demand on time that noisy, low-value automated PR reviews can have on teams. They are slop grenades, bogging down developers with questionable comments and feedback that slow productivity and damage morale. I’ve found, however, that the slop can be optimized out and the result can be a process that further uplifts your AI code-assist capability.

Towards the end of 2025 GitHub’s Copilot PR Review function improved in quality from something that was mostly noise to something that was often finding real issues. Other products like Greptile and CodeRabbit popped up to compete in the space but share a similar problem with Copilot: the availability and quality of the product is limited by your organisation’s subscription to it. As we draw towards the end of 2026, AI code review is now so good that maintaining a codebase without it is questionable practice, and depending on (and paying) third parties to prompt a model on our behalf is not necessary.

The Nightmare Slop Approach

So someone raises a Pull Request (PR) and you ask Claude to “review this code”. Armed with tools like GitHub CLI, it can check out the PR, smash a bunch of line-level comments into it and submit the review. This doesn’t require much of your time, so you do it on every PR. Claude adds ten comments to each PR (regardless of size or complexity), and now ten PR authors have 100 comments to read and respond to.

But the authors have Claude and gh too, so they use the same automated approach to read, generate code fixes and resolve the comments. And then it loops - you instruct your harness to review the code again and it puts another ten comments on the PR, and the token spend increases along with the slop creep in the codebase. At some stage a collaborator declares that using AI to review/write code is demonstrably worse than not using it at all, and the team either yeets itself back to 2021 or implements the automation correctly.

The nightmare approach is similar to vibe coding without proper context engineering and guardrails - the model produces slop. The solution is similar too - provide the model with guidance on what we expect from high quality review output and, where we can, make it hard to do the wrong thing.

Stating our expectations

PR review is a very loaded term because, depending on the team, project and codebase, we have a bunch of expectations that we need to share with the model. Some of them might include:

We don’t want ten comments against every PR by default. Smaller (correct) PRs might have none, and over time we want to trend towards a shared understanding of quality that results in fewer comments.
Some comments are more important than others - for example defects that could cause data loss or crashes versus stale documentation or style issues.
Each comment should be small and easily understood - we don’t want minutes of reading time per comment.
Subsequent reviews should not repeat the same comments - if a comment has been raised and resolved, it should not be raised again.
Comments should be specific to the code in the PR.

Adversarial review

Adversarial review is a technique where more than one model or agent is used to review the same code. The basic review process becomes:

Agent 1 reviews the code and produces a set of findings.
Agent 2 reviews the code and produces a set of findings.
Agent 3 reconciles the above findings and promotes (none or) some to the PR as comments.

The agents can be different models and can be passed different prompts. There might be additional agents producing the initial findings, for example an agent prompted specifically on finding security issues.

In my harness, assist, I’ve implemented assist review which by default runs a Claude Code + Opus agent and a Codex + GPT agent in parallel. A third agent then synthesizes their findings. There are two main prompts in this approach, the one given to the review agents and the one given to the synthesizer agent. Notice that the review prompt describes:

What types of comments to raise
Undesirability of suggestions to add code comments
Calling out tautological tests
How to raise a comment, including format and severity

The synthesis prompt guides the final agent towards producing a set of low-noise, high-value comments. Over time, as models have improved and as I’ve extended and tweaked the prompts, the outcome of this approach has trended towards automated reviews with actionable comments - so much so that most PR reviews done without it are now lower quality by comparison.

Building adversarial review

I didn’t land on the approach immediately, and I too have suffered from the noise and cognitive load of poorly implemented AI automation (including my own). The quality of the existing codebase, including its architecture and AI tooling configuration, will determine whether you can single-shot automated review. Options in assist review --help reveal multi-step approaches including:

--refine - where I step through the comments with an agent before submitting, removing or refining comments.
--apply - where I step through comments with an agent before submitting and remove one or more of them by fixing the code locally.
--address-comments - where I step through already-submitted comments with an agent and determine whether to fix or won’t-fix them, automatically resolving comment threads on the PR.

Before becoming comfortable that the automation was producing high-value comments, I would often use --refine and --apply, inspecting and adjusting the results and guarding others from the noise. Now, with the latest models and the state of the output, I will more often than not have the review execute and post to GitHub immediately without first inspecting the result - only then will I address the comments.

Automating the workflow

For my own PRs, which I raise with assist’s /pr, assist review is automatically invoked after the PR has been raised and, once it finishes, an --address-comments session starts automatically. Addressing comments is sequential and requires human decisions, though there’s future opportunity here to increase automation further by auto-applying recommendations and/or batching the decisions up front.

When I review a colleague’s PR, I’ll trigger the review from assist’s web view, or directly in-browser on GitHub via the assist Firefox /extension. I’ve already taken that manual step further with /review-ci, a command that has assist eject the review approach directly into a repo and add a GitHub Actions workflow to call it. This GitHub Actions approach can use Azure AI Foundry or LiteLLM as model providers and doesn’t require my intervention (or a dependency on assist).

Conclusion

Adversarial review is one step towards improved AI code-assist output, and is most effective when used in combination with the other approaches discussed in my Steering the Vibe series. It’s also a step towards improving code review, though it doesn’t replace human review. I’m currently exploring avenues to improve code review further, including risk-based review and an improved UI for reviewing PRs. You can see progress so far in assist’s /high-level-review and I’ll blog about it at a later date.