Review-Gate für KI-generierten Code
Unslop prüft jeden Pull Request auf die Art, wie KI-geschriebener Code scheitert: verschluckte Fehler, Pakete, die es nicht gibt, SQL aus zusammengesetzten Strings, Tests ohne Assertion.
Zuerst läuft ein deterministischer Pre-Scan. Dann prüft ein Modell den Diff, und ein zweites Modell prüft dessen Findings gegen, ohne die Begründung des ersten zu sehen. Jedes Finding nennt seine Regel und zitiert den Code.
Private Beta. Die Registrierung ist geschlossen, und CLI, Editor-Extension und MCP-Server sind noch nicht veröffentlicht.
Das Finding zeigen. Das Urteil erklären. Sagen, was übersprungen wurde.
src/lib/user-lookup.ts
SEC-004 (SQL built by string interpolation) (CRITICAL)
The SQL statement is assembled from interpolated/concatenated values — SQL injection. Use parameterized queries exclusively.
Zeigen statt behaupten
Beide stammen aus Scans unseres eigenen Test-Repositorys. Regel, zitierter Code, Erklärung und Fix sind Produktausgabe, unbearbeitet. Das Produkt schreibt seine Findings auf Englisch.
Modell-Finding, von der blinden Gegenprüfung bestätigt
Condition 1 (Silent Error Swallowing)
Zitierter Code
} catch (e) {
console.error(e);Vorgeschlagener Fix
} catch (e) {
throw new Error(`Failed to parse configuration: ${e instanceof Error ? e.message : String(e)}`);
}The catch block performs passive logging and returns null instead of propagating the error or triggering a compensating mechanism, silently swallowing parsing failures.
Modell-Finding, herabgestuft, weil eine Stufe übersprungen wurde
MAINT-007
Zitierter Code
if (listError instanceof GitHubApiError && listError.status === 404) return null;Vorgeschlagener Fix
if (readError instanceof GitHubApiError && readError.status === 404) return null;The catch block catches 'readError', but the condition references 'listError', which is out of scope. This causes a TypeScript compile error (TS2304: Cannot find name 'listError') and a runtime ReferenceError whenever fetchFileContent throws an error.
⚠️ Downgraded to WARNING — this finding was flagged for Pro escalation, but the escalation was skipped (budget, API or time-limit degradation), so it could not be conclusively verified.
01
Erst deterministisch
Der Pre-Scan läuft vor jedem Modell-Aufruf. Er nutzt Pattern-Matcher, Syntaxbaum-Abfragen, Config-Checks, Lint-Regeln und Abfragen der Paket-Registry und hat einen Detektor für 65 Regel-IDs.
Ein deterministisches Finding wird nie von einem Modell neu beurteilt. Meldet das Modell dieselbe Regel an derselben Stelle, gewinnt das deterministische Finding. Im Ergebnis ist es als deterministic markiert.
02
Modell-Review, blind gegengeprüft
Der Regelkatalog hat 127 Einträge. Regeln ohne Detektor brauchen Urteilsvermögen, also prüft ein Modell den Diff gegen die Regeln, die zu deinem Stack passen. Manche Regeln beschreiben Prozesse und lassen sich an einem Diff gar nicht prüfen. Was das Modell meldet, ist eine Behauptung, noch kein Finding.
Ein zweites Modell bekommt nur die Regel, die Fundstelle, den zitierten Code und den Diff. Erklärung, Schweregrad und Fix des ersten Modells sieht es nicht. Es antwortet confirmed, refuted oder uncertain. Widerlegte Behauptungen fallen weg. Unsichere sowie kritische, die widerlegt oder nur schwach bestätigt wurden, bekommen einen dritten Durchgang. Was unsicher bleibt, wird zur Warnung und sagt das auch.
Zwei Dinge solltest du wissen. Alle Modelle sind Gemini-Modelle eines Anbieters: Die Unabhängigkeit kommt daher, was das zweite Modell nicht zu sehen bekommt, nicht aus einer anderen Modellfamilie. Und nicht jedes Finding bekommt die blinde Gegenprüfung: Große Diffs können in einem einzelnen Durchgang ohne sie geprüft werden, und das Review sagt das dann.
03
Wenn eine Stufe ausfällt
Jedes Review hat ein Zeitbudget von 300 Sekunden. Wenn die Gegenprüfung oder der dritte Durchgang wegen Zeit, eines Modellfehlers oder eines aufgebrauchten Budgets nicht laufen kann, gelten die Findings nicht stillschweigend als verifiziert. Ein Finding, das auf den dritten Durchgang gewartet hat, wird mit einem Hinweis zur Warnung herabgestuft. Lief die Gegenprüfung nicht, steht beim Konfidenz-Score „n/a“ statt einer Zahl.
Pull Request, Check Run und CLI tragen dann dieselbe Zeile, zum Beispiel: „Reduced confidence: time budget exhausted — skipped: blind verification (some or all findings).“ Scheitert das Modell-Review an einzelnen Dateien, werden diese Dateien namentlich genannt.
Wer entscheidet
| Frage | Deterministischer Pre-Scan | Modell-Review |
|---|---|---|
| Regeln | 65 Regel-IDs mit Detektor | Regeln, die Urteilsvermögen brauchen, aus einem Katalog von 127 |
| So entsteht ein Finding | Code: Patterns, Syntaxbaum, Config-Checks, Lint-Regeln, Registry-Abfragen | Ein Modell entwirft es, ein zweites prüft es blind gegen |
| Dateien | TypeScript, JavaScript, Python, Java, Go, Rust, C und C++, dazu Config-Dateien wie YAML, JSON, Terraform und TOML | Nur TypeScript, JavaScript und Python |
| Kann es den Check scheitern lassen? | Ja. Ein CRITICAL-Finding lässt den Check scheitern. | Ja. Ein CRITICAL-Finding lässt den Check scheitern, ein Urteil kann also auf einem Modell-Finding beruhen. |
| Im Ergebnis markiert als | deterministic | confirmed, uncertain oder unverified |
Das Problem
Weil der Fehler gefangen und verworfen wurde. Ein catch-Block, der loggt und null zurückgibt, sieht im Diff ordentlich aus und versteckt den Ausfall in Produktion. Das bestätigte Finding oben ist genau das.
Der Paketname war erfunden. Unslop schlägt die in package.json, requirements.txt, pyproject.toml und Cargo.toml deklarierten Abhängigkeiten in ihrer Registry nach (Regel SEC-035).
Ein Test ohne Assertion ist immer grün. Tests ohne Assertion sind eine der deterministischen Regeln (TEST-001).
Der Agent hat mehr geändert, als irgendjemand gelesen hat. Unslop prüft jeden Push auf den Pull Request erneut und kommentiert an der betroffenen Zeile.
Plattform
Pull Request, Terminal, Editor, Coding-Agent.
FAQ
Wir trainieren nicht damit, und Google auch nicht: Die Service-Bedingungen von Vertex AI schließen aus, dass Google Prompts und Antworten von Kunden zum Training eigener Modelle nutzt. Die Review-Modelle laufen auf dem EU-Multiregion-Endpunkt von Vertex AI, für den Google zusagt, dass die ML-Verarbeitung innerhalb der EU-Mitgliedstaaten bleibt. Für einen Pull Request lesen wir den Diff, die geänderten Dateien und eine kleine, regelbasierte Auswahl weiterer Dateien des Repositorys (Manifeste, Datenbankschema, die Startdatei eines Dienstes) von GitHub für das Review und speichern die Findings mit den zitierten Zeilen, nicht den Diff und nicht diese Dateien. Ein Scan aus der CLI oder dem MCP-Server lädt einen Diff und dieselbe Auswahl von Dateien hoch; der Diff wird mit dem Scan gespeichert, die Auswahl nur, bis das Review sie geladen hat; vor dem Upload verweigert der Client jeden Diff, in dem er ein Secret erkennt. Der Repository-Index entsteht aus Signaturen, Interfaces und Typdefinitionen, nicht aus Implementierungslogik. GitHub-OAuth-Tokens liegen mit AES-256-GCM verschlüsselt in der Datenbank.
Es läuft neben deiner CI, nicht in ihr. Der Webhook antwortet, sobald das Review registriert ist; das Review läuft dann als GitHub Check Run mit einer harten Grenze von 300 Sekunden. Nur CRITICAL-Findings lassen den Check scheitern; Warnungen enden als neutral und blockieren keinen Merge. Ob der Check verpflichtend ist, legst du in deiner Branch Protection fest.
Nein. Findings erscheinen als Check Run und als Review-Kommentare am Pull Request. Die CLI vergleicht deine getrackten Änderungen mit der Merge-Base, und die VS-Code-Extension zeigt Findings und wendet vorgeschlagene Fixes im Editor an; beide sind gebaut und noch nicht veröffentlicht. Das Dashboard ist für Repositorys, Scan-Historie, API-Keys und Abrechnung da.
Zum Teil, und wir sagen, welcher Teil. 65 Regeln prüfen deterministische Detektoren, und diese Findings laufen nie durch ein Modell. Der Rest ist ein Modell-Review, und ein Finding daraus kann den Check scheitern lassen. Deshalb prüft ein zweites Modell die Findings gegen, ohne die Begründung des ersten zu sehen, und deshalb sagt das Review, wenn diese Gegenprüfung nicht stattgefunden hat. Modell-Aufrufe laufen mit Temperature 0; Ergebnisse schwanken trotzdem etwas zwischen Läufen.
Das Modell-Review liest TypeScript-, JavaScript- und Python-Dateien. Der deterministische Pre-Scan deckt zusätzlich Java, Go, Rust, C und C++ sowie gängige Config-Dateien ab. Ein Pull Request ohne TypeScript-, JavaScript- oder Python-Datei bekommt nur deterministische Prüfungen, wenn er Java-, Go-, C-, C++-, PowerShell-, Terraform-, YAML- oder JSON-Dateien ändert. Dann liest kein Modell mit: Der Check heißt „Deterministic checks only“ und bleibt neutral, solange kein kritisches Finding ihn scheitern lässt. Mischt ein Pull Request beides, nennt die Zusammenfassung die Dateitypen, die kein Modell gelesen hat. Alles andere, etwa ein reiner Doku-Pull-Request, endet weiter als neutral mit „Nothing to review“.
Der Check wird geschlossen und bleibt nicht hängen. Ein gescheitertes Review endet als Failure mit dem Grund im Check, zum Beispiel „Review timed out“. Ein Review, das gar nicht startet (kein Abo, Kontingent aufgebraucht, Repository deaktiviert), postet einen abgeschlossenen Check mit dem Ergebnis „action required“, der den Grund nennt. Ist der Check bei dir verpflichtend, gelten weiter die Branch-Protection-Overrides von GitHub.
Unslop ist in der Private Beta. Die Registrierung ist vorerst geschlossen.