Deterministic AI code review
Unslop is the deterministic review gate for AI-generated code. It catches what LLM reviewers miss — on every pull request, in your terminal, and in your editor.
Same files, two reviewers: a cloud LLM found 44× fewer issues than a deterministic scan. We built the gate on the side that wins.[1]
The only AI code gate that doesn’t ask an AI whether the AI was wrong.
Backed by independent, published academic research. All sources in the footer.
01
The judge is compromised
The research is blunt. On identical tasks, deterministic checks reach precision 1.00; LLM judges manage 0.50–0.67 — a coin flip. Change the sampling temperature, and the verdict changes with it. That’s not a gate. That’s a slot machine.
Worse: the misses are silent. LLM judges under-count the most dangerous bugs — failures dressed up as success — by 44 to 1.
02
It compounds
Measured across refinement rounds, vulnerability density climbs 2.1 → 4.7 → 6.2 per sample. Every round. Even with security-focused prompts.
And AI doesn’t just write bugs — it invents dependencies. 205,474 hallucinated package names, 43% recurring. A ready-made supply-chain attack surface.
03
The engine
Our proprietary engine runs mechanical checks by machine — perfect precision on tasks where LLM judges top out at 0.67. Behind it: 119 rules, distilled from published research on how AI code actually fails.
It adapts to your codebase and applies context only where it measurably helps — lifting fix success from 34.4% to 87.1%. We publish the results, not the recipe.
The comparison
| Check | LLM judge | Unslop |
|---|---|---|
| Hallucinated APIs and imports[2] | Precision 0.50–0.67 | Precision 1.00 |
| Silent failures[1] | Under-counted 44 to 1 | Caught deterministically |
| Verdict stability[9] | Shifts with sampling temperature | Same input, same verdict |
| Fix guidance[3][13] | “Improve this code” — flaws rise 2.1 → 6.2 | Names the violated rule — fix rate 34.4% → 87.1% |
Objection handling
Up to 77% of AI-written test methods assert nothing. High coverage, poor detection. Green CI is not a verdict.[5][6]
Security prompting changed nothing in Java — and C showed +41–42% more flaws. A prompt is not a control.[12]
100% of generated OAuth samples hard-coded the client secret. AI code is a happy-path generator.[10][11]
Up to 98.6% of real-world agent denylists were bypassable. Agents need harder gates, not softer ones.[15][16]
Platform
From pull request to terminal to editor.
FAQ
No, on both counts. Repository indexing extracts only the API surface — exported signatures, interfaces, type definitions — never implementation bodies. Reviews operate on the diff of the change under review, fetched at review time. Inference runs on Google Vertex AI, whose terms exclude training on customer prompts, pinned to the EU region (europe-west3) — with one documented exception: the Pro escalation model currently runs on Vertex’s global endpoint until Google ships it in the EU. GitHub tokens are encrypted at rest with AES-256-GCM.
No. The webhook is acknowledged instantly and the review runs asynchronously as a native GitHub check run — parallel to your CI, never inside your build. The worst case (full three-model escalation) is hard-capped at 300 seconds; most reviews finish in a single pass. Only CRITICAL findings fail the check; advisory findings conclude as neutral and cannot block a merge. Whether the check is required at all remains your branch-protection decision.
No. Findings land where your team already works: as check runs and review comments on the pull request, in the terminal via the unslop CLI — it diffs your tracked changes against the merge-base, zero configuration — and in VS Code, where fixes are reviewed and applied without leaving the editor. The dashboard handles configuration and billing, not your daily loop.
No. Verdicts come from 119 deterministic rules — the LLM explains findings, it never decides them. Every model call runs at temperature 0, so the same diff always produces the same verdict, and every draft finding must survive a blind verification pass before it reaches your PR.
Your PRs don’t hang. Every failure path closes the check run explicitly: a crashed review concludes as a failure with the reason in the check output, and a skipped review (quota, deactivated repository) posts a completed check that says why — never an eternal “Expected — waiting for status”. If you mark the check as required, standard GitHub branch-protection overrides still apply.
Unslop your next pull request. Evidence, not vibes.