But one model giving one opinion is not enough.

That was the core idea behind Acrity: if code review is supposed to protect quality, architecture, behavior, and delivery intent, then the review process itself should not be a black box.

It should be challenged.

It should produce evidence.

And it should be cheap enough to run continuously on real pull requests.

The bottleneck in modern code review

Code review has become a strange bottleneck.

Engineering teams are expected to ship faster, but every pull request still needs careful review:

• Is the architecture still coherent?

• Did the implementation actually satisfy the task?

• Were the acceptance criteria respected?

• Are there regressions hidden in the diff?

• What edge cases could break in production?

• Is the review worth the time and cost it consumes?

Manual review is valuable. It is also hard to scale.

The bigger the team gets, the harder it becomes to review every PR deeply without slowing delivery down.

AI can help here, but only if we stop treating AI review as “one model reads a diff and posts some comments.”

That approach can be useful, but it has a major weakness:

one model has one style, one set of strengths, and one set of blind spots.

Why adversarial review?

Good human code review is rarely one-dimensional.

One engineer may notice an architectural violation. Another may catch a missed requirement. Someone else may ask, “What happens in this edge case?” A QA-minded reviewer may think about behavior that the implementation technically allows, but the product should not.

Acrity tries to bring that same dynamic into AI code review.

Instead of relying on a single AI reviewer, Acrity reviews each pull request through multiple specialized lenses and then reconciles the result into one final decision.

The goal is not to generate more noise.

The goal is to create a review process that can explain itself.

How Acrity works

Each pull request is reviewed by specialized AI roles:

• Architect reviews architecture, layering, coupling, boundaries, and project rules.

• Spec Validator compares the diff against the task, acceptance criteria, and expected delivery.

• QA / Behavior Reviewer looks for regressions, risky behavior, edge cases, and unexpected product impact.

Then a Chairman consolidates the findings.

The Chairman resolves conflicts, removes weak findings, preserves evidence, and produces one final verdict that the team can trace.

This is important because the final output should not be just:

approved

or:

changes requested

The useful question is:

why?

Why was this PR approved? Why were changes requested? Which finding had enough evidence? Which requirement was missed? Which risk is real? Which comment is just noise?

Acrity is designed to make that decision auditable.

Reducing blind spots with different models and providers

Another important design choice: Acrity does not need to depend on a single model or a single vendor across every review stage.

Different rounds can combine different models and providers, so the reviewers do not all “think” the same way.

That matters because each model has its own tendencies.

Some models are stronger at structured reasoning. Some are better at code-level analysis. Some are better at summarizing. Some are more conservative. Some are more aggressive in flagging risk.

If every step uses the same model, the process may inherit the same blind spots everywhere.

A truly adversarial review process needs reviewers that can disagree.

From diff to decision

Acrity treats code review as a process, not a black box.

The pipeline starts with the real diff and the delivery context. Then it applies different review lenses, cross-checks findings, scales the depth of analysis based on risk, and publishes a concrete action back into the team’s workflow.

The output should help the team understand:

• what was analyzed;

• what was considered risky;

• what evidence supports the finding;

• what should be changed;

• what can safely move forward;

• and how much the review cost.

That last part matters more than people usually admit.

Built for the stack teams already use

Acrity is not trying to create another place where engineers need to work.

The review should meet the team where the work already happens.

That means connecting to version control and project management tools teams already use:

• GitHub

• GitLab

• Bitbucket

• Azure DevOps

• Jira

• Linear

• ClickUp

• native issue trackers

The objective is simple:

improve the review flow without forcing the team to adopt a completely new workflow.

AI review should not be a black box

One of the things I care about most in Acrity is operational visibility.

Every run tracks:

• duration;

• tokens;

• model calls;

• cost;

• review stages;

• final verdict.

This gives engineering teams and leadership a clearer view of what is happening per PR.

Not a fixed estimate.

Not a vague promise.

Observed telemetry.

If AI is going to become part of the engineering workflow, teams should know what it decided, why it decided that, how long it took, and how much it cost.

Trial available

Acrity now has a trial available.

I would be very grateful for feedback from engineers, tech leads, founders, and teams reviewing real pull requests every day.

Bugs, criticism, missing integrations, confusing output, real-world edge cases, and uncomfortable feedback are all useful at this stage.

Try Acrity here:

https://acrity.io

Let’s make code review faster, cheaper, and more trustworthy.