Viktor.comAn AI coworker that actually does the work
Acrity
AI code review with adversarial consensus
11 followers
AI code review with adversarial consensus
11 followers
Acrity reviews pull requests through multiple AI specialists—architecture, spec validation, QA/behavior, and security—then challenges findings and synthesizes one traceable verdict with cost, token, and timing visibility.
Free Options
Launch Team / Built With
How does the challenge step actually work in practice. Do the specialists push back on each other until they agree, or does a separate model arbitrate when they disagree on something like whether a finding is critical or just a nit.
@azadmrtsom It’s not an open-ended debate loop. In practice, Acrity runs the first specialist reviews independently, then runs a cross-review round where each specialist challenges the others’ findings.
For each finding, the cross-reviewer can mark it as VALID, DISPUTED, or NEEDS_CONTEXT. Importantly, they can also say: “the issue exists, but the severity is too high” and recommend a lower severity. So existence and severity are treated separately.
After that, a separate Chairman model consolidates the findings, removes duplicates/noise, and writes the final review. Then a deterministic guardrail enforces the consensus rules: actionable CRITICAL / WARNING findings need at least 2/3 validation consensus. Low-consensus findings are downgraded to INFO, fully disputed ones are excluded, and the final verdict is recalculated from the surviving evidence.
So the goal is not to force agreement. It’s to make disagreement explicit, traceable, and unable to silently block a PR without enough support.
How does it handle merge conflicts or diffs that span multiple files when the specialists disagree on severity?
@havagqhy Great question. Acrity doesn’t try to resolve merge conflicts itself; that still belongs to Git / the VCS. It reviews the PR snapshot and diff that the provider exposes, and if conflict markers or broken final-state code are visible, they are treated as review evidence.
For multi-file diffs, findings stay anchored to concrete file/line evidence. Large diffs can be split into per-file/sharded review packs, then merged back before the final decision.
When specialists disagree on severity, they don’t just average opinions. Each finding goes through cross-review: other specialists can validate it, dispute it, or say "valid, but lower severity." A Chairman model synthesizes that, and then a deterministic guardrail enforces the rules: a CRITICAL/WARNING needs at least 2/3 validation consensus to remain actionable. Low-consensus findings are downgraded to INFO, fully disputed ones are excluded, and the final verdict is recalculated from the surviving findings.
ran it on a messy legacy pr i had lying around and the security specialist actually caught a token leak i had missed in two manual reviews, nice.
@sevimfgsb That's exactly the kind of case we designed the security lens for. It looks for concrete evidence in the diff, not generic "this might be risky" comments, and then the finding still goes through the adversarial review flow before it becomes actionable.
Legacy PRs are especially interesting because they usually combine drift, old patterns, and accidental exposure risks. If you're open to it, I'd love to hear what kind of token pattern it caught, without sharing anything sensitive, of course.