Deterministische AI Code Review
Unslop ist das deterministische Review-Gate für KI-generierten Code. Es fängt, was LLM-Reviewer übersehen — an jedem Pull Request, im Terminal und im Editor.
Dieselben Dateien, zwei Reviewer: Ein Cloud-LLM fand 44× weniger Probleme als ein deterministischer Scan. Wir haben das Gate auf die Seite gebaut, die gewinnt.[1]
Das einzige AI-Code-Gate, das keine KI fragt, ob die KI sich geirrt hat.
Gestützt auf unabhängige, publizierte Forschungsdaten. Alle Quellen im Footer.
01
Der Judge ist kompromittiert
Die Forschung ist deutlich: Auf identischen Aufgaben erreichen deterministische Checks Precision 1,00; LLM-Judges schaffen 0,50–0,67 — einen Münzwurf. Ändere die Sampling-Temperatur, und das Urteil ändert sich mit. Das ist kein Gate. Das ist ein Spielautomat.
Schlimmer: Die Fehler sind lautlos. LLM-Judges unterzählen die gefährlichsten Bugs — Scheitern, das wie Erfolg aussieht — im Verhältnis 44 zu 1.
02
Es akkumuliert
Über Refinement-Runden gemessen steigt die Schwachstellendichte auf 2,1 → 4,7 → 6,2 pro Sample. Jede Runde. Selbst mit Security-Prompts.
Und KI schreibt nicht nur Bugs — sie erfindet Dependencies. 205.474 halluzinierte Paketnamen, 43 % davon wiederkehrend. Eine fertige Supply-Chain-Angriffsfläche.
03
Die Engine
Unsere proprietäre Engine erledigt mechanische Prüfungen maschinell — mit perfekter Precision, wo LLM-Judges bei 0,67 enden. Dahinter: 119 Regeln, destilliert aus publizierter Forschung dazu, wie KI-Code wirklich scheitert.
Sie passt sich deiner Codebase an und setzt Kontext nur dort ein, wo er messbar hilft — und hebt die Fix-Quote von 34,4 % auf 87,1 %. Wir veröffentlichen die Ergebnisse, nicht das Rezept.
Der Vergleich
| Prüfung | LLM-Judge | Unslop |
|---|---|---|
| Halluzinierte APIs und Imports[2] | Precision 0,50–0,67 | Precision 1,00 |
| Lautlose Fehler[1] | Um 44 zu 1 unterzählt | Deterministisch gefangen |
| Stabilität des Urteils[9] | Schwankt mit der Sampling-Temperatur | Gleicher Input, gleiches Urteil |
| Fix-Anleitung[3][13] | „Verbessere diesen Code“ — Schwachstellen steigen auf 2,1 → 6,2 | Nennt die verletzte Regel — Fix-Quote 34,4 % → 87,1 % |
Einwandbehandlung
Bis zu 77 % der KI-geschriebenen Testmethoden prüfen nichts. Hohe Coverage, schwache Erkennung. Grünes CI ist kein Urteil.[5][6]
Security-Prompting änderte in Java nichts — und in C zeigten sich +41–42 % mehr Schwachstellen. Ein Prompt ist kein Control.[12]
100 % der generierten OAuth-Beispiele hatten das Client-Secret hartkodiert. KI-Code ist ein Happy-Path-Generator.[10][11]
Bis zu 98,6 % der realen Agent-Denylists waren umgehbar. Agents brauchen härtere Gates, nicht weichere.[15][16]
Plattform
Vom Pull Request übers Terminal bis in den Editor.
FAQ
Nein, beides nicht. Die Repository-Indizierung extrahiert nur die API-Oberfläche — exportierte Signaturen, Interfaces, Typdefinitionen — niemals Implementierungscode. Reviews arbeiten auf dem Diff der Änderung, geladen zum Review-Zeitpunkt. Die Inferenz läuft auf Google Vertex AI, dessen Bedingungen Training auf Kunden-Prompts ausschließen, gepinnt auf die EU-Region (europe-west3) — mit einer dokumentierten Ausnahme: Das Pro-Eskalationsmodell läuft derzeit auf Vertex’ globalem Endpoint, bis Google es in der EU bereitstellt. GitHub-Tokens werden at rest mit AES-256-GCM verschlüsselt.
Nein. Der Webhook wird sofort bestätigt, das Review läuft asynchron als nativer GitHub Check Run — parallel zu deiner CI, nie in deinem Build. Der Worst Case (volle Drei-Modell-Eskalation) ist hart auf 300 Sekunden begrenzt; die meisten Reviews sind in einem Durchlauf fertig. Nur CRITICAL-Findings lassen den Check fehlschlagen; Hinweise enden als neutral und können keinen Merge blockieren. Ob der Check überhaupt required ist, bleibt deine Branch-Protection-Entscheidung.
Nein. Findings landen dort, wo dein Team ohnehin arbeitet: als Check Runs und Review-Kommentare am Pull Request, im Terminal über die unslop CLI — sie difft deine getrackten Änderungen gegen die Merge-Base, ganz ohne Konfiguration — und in VS Code, wo Fixes geprüft und übernommen werden, ohne den Editor zu verlassen. Das Dashboard ist für Konfiguration und Billing da, nicht für die tägliche Arbeit.
Nein. Urteile kommen aus 119 deterministischen Regeln — das LLM erklärt Findings, es entscheidet sie nie. Jeder Modell-Call läuft mit Temperature 0: Derselbe Diff ergibt immer dasselbe Urteil. Und jedes Draft-Finding muss einen blinden Verifikations-Pass überstehen, bevor es deinen PR erreicht.
Deine PRs hängen nicht. Jeder Fehlerpfad schließt den Check Run explizit: Ein abgestürztes Review endet als Failure mit dem Grund im Check-Output, ein übersprungenes Review (Quota, deaktiviertes Repository) postet einen abgeschlossenen Check, der sagt warum — niemals ein ewiges „Expected — waiting for status“. Ist der Check als required markiert, greifen weiterhin die normalen Branch-Protection-Overrides von GitHub.
Unslop deinen nächsten Pull Request. Fakten statt Vibes.