A code review platform that has to prove its own findings
Most review tools produce more to read than to fix. We built one where several analysis agents work the same change in parallel, a second pass argues against everything they found, and what survives arrives with replacement code and the evidence behind it. One engine sits behind the terminal, the editor, the API and an unattended service, so a review means the same thing wherever it starts.
- IndustryDeveloper tooling
- EngagementIn-house product build
- StatusIn active use, still being extended
One engine behind every way of asking for a review
The platform reads a proposed change, works out what it touches, and puts it in front of several analysis agents at once. Their findings are merged, deduplicated, ranked by severity and capped, so what comes back is a queue to work down from the top. It is not a linter, and it is not one model's opinion written up as a verdict.
The same engine runs whether the request comes from a terminal command, from an editor, from the API, or from a background service watching a repository on its own schedule. They share one history, so a review started at the keyboard is the review the dashboard shows later, and a pull request keeps a single comment that gets updated in place.
Why another review tool
Automated review had a credibility problem before it had a coverage problem. These are the three failures we designed against.
Noise costs more than it catches
A tool that flags formatting churn, reordered imports and confident guesses teaches a team to skim. Once review output is skimmed, the one finding that mattered gets skimmed with it.
A finding without a fix is another ticket
Review comments that describe a problem and then stop hand the work back to someone who was already busy. The reader still has to work out what the corrected code looks like, and often decides it can wait.
Every surface behaved differently
Review in the terminal, review in the editor, review on a pull request and review on a schedule were separate tools with separate behaviour and separate history. The same change could pass one and fail another.
What we built
One pipeline, four ways to reach it, and several layers of doubt between a model's guess and something a person is asked to read.
One review engine behind every surface
A single pipeline parses the change, filters it, enriches it, dispatches it to agents and merges the result. Formatting and storage belong to whoever called it, which is why the surfaces can differ without the review differing.
- A terminal command, an editor integration, an API with live updates and a background service all run the same review
- One shared history, so a review started at the keyboard is the review the dashboard shows later
- Model providers sit behind a single interface, so adding or swapping one is a configuration change
Findings that arrive with the fix attached
Five severity levels collapse to three actions, fix now, fix soon and review later, so a report can be worked from the top. Each finding is enriched from a map of the code, so it points at a real path in the repository.
- Every finding carries replacement code, and the schema rejects one that does not
- Reviews are enriched from a symbol index: which functions changed, who calls them, which tests cover them, and what imports what
- Findings carry an identity derived from their content, so reformatting a file does not resurrect an issue already handled
Five layers between a guess and a report
Each layer is cheaper than the one after it, so most of what would have been noise is gone before anything expensive happens. The last layer is the strict one: the platform tries to prove the finding against the source.
- Whitespace, comment and import-only changes are dropped before a single model is contacted, and a static pattern pass marks the risky code first
- Low-confidence findings are removed straight after review, then a second pass argues against every survivor and keeps only what it cannot talk down
- Where it can, the platform writes a small program that checks the claim against the real source inside an isolated sandbox, and a check that cannot be run leaves the finding in place
An adversarial mode that proposes and never applies
A three-wave exercise against a codebase: one set of agents hunts for something exploitable, a second writes the patch, and a third checks the patch against the hole it claims to close. It reports back verified, partly fixed, still open, or a false alarm.
- Attackers work under distinct briefs, a business-logic auditor, a hostile customer, a chaos engineer, an observability specialist and a compliance reviewer, so one sweep covers five different instincts
- Patches are produced as diffs and validated, never written to the repository, so a person decides what lands
- The agents work inside a command allowlist with destructive operations blocked, and their output is screened for injected instructions
What changed in practice
We describe what the platform does. No accuracy figure appears here, because any such claim would need a measurement we have not published.
One queue
What a review produces
Findings merged across agents, deduplicated, ranked by severity and capped. What arrives is one ordered list, worked from the top.
Checked, not guessed
What reaches a person
Trivial changes never reach a model, weak findings are dropped, survivors are argued against, and where it can the platform proves the finding against the source first.
A person decides
How changes land
Fixes and patches arrive as proposals, with a preview and a backup of the original file. Nothing is written to a repository without someone accepting it.
Does your review process produce more reading than fixing?
Tell us how code gets reviewed at your company today and where it stalls. We will tell you what is worth automating and what is not.
Discuss your project