Jev hat meinen Test-Pull-Request richtig beurteilt und falsch priorisiert. Die Anfrage mit 14 Prüffragen kostete rechnerisch rund 0,00008 US-Dollar zum Herstellerpreis. Jev ist ein Entscheidungsmodell von TypeSafe AI und laut Launch-Beitrag seit dem 15. September 2026 im Early Access. Bei diesem Preis wird die Frage nach dem Betrieb dringlich: Wo darf man ein solches Modell in den Ablauf von Coding Agents einbauen, was darf es nie freigeben, und was muss vorher gemessen sein? Dieser Beitrag nimmt Jev zum Anlass, die Prüfschritte aus dem Leitfaden zu Review- und Prüfabläufen mit Coding Agents neu zu bewerten.
Mein Test mit Jev: richtiges Urteil, falsche Priorität
Getestet habe ich eine Kotlin-Datei mit 14 Zeilen und fünf Team-Richtlinien. Das Gesamturteil „Änderungen anfordern“ stimmte, mit einer Konfidenz von 0,99. Als dringendste Stelle wählte Jev aber suspended (0,46), ein falsch eingesetztes Sprachmittel, knapp vor name_and_greeting (0,40), wo zur Laufzeit ein Absturz droht. Zugleich nannte Jev Laufzeitsicherheit als Hauptproblem. Für diese Wahl meldete Jev eine Konfidenz unter 0,4. Laut Formel in TypeSafes offenem Adapter misst sie den Abstand der höchsten Wahrscheinlichkeit zum Zufallsniveau, nicht die Wahrscheinlichkeit der gewählten Antwort.
Die Gegenprobe lief in vier parallelen Anfragen: dieselben acht Ja/Nein-Fragen auf dem Original, auf vollständig und auf halb bereinigtem Code, dazu sieben umgepolte Fragen, bei denen die richtige Antwort ins Gegenteil kippt. Alle 31 Antworten lagen auf der richtigen Seite von 0,5. Eine Ja-Tendenz zeigte dieser Lauf nicht. Im Kleinen ist das der Schritt „Prüfen Sie den Prüfer“ aus dem Verifier-Harness.
Drei der fünf sichersten Antworten hätten Compiler, IDE oder der Linter detekt ohnehin gemeldet. Und Jev fand nichts, was meine Fragen nicht schon benannt hatten.
Die Grenzen sind eng: je Variante ein Lauf, eine synthetische Datei, und Code, Fragen und Soll-Werte stammen von mir. Ob eine 0,9 auch in neun von zehn Fällen zutrifft, sagt dieser Test nicht.
Mich interessiert deshalb weniger, wie gut Jev ist, als die Zahl unter 0,4. Jemand muss festlegen, ab wann eine Antwort als unsicher gilt und was dann passiert: Geht der Pull Request an einen Menschen, oder läuft alles weiter? Das ist eine Führungsentscheidung, und sie stützt sich auf eine Zahl, zu der das Modell keinen Satz Begründung liefert.
Entscheidungsmodell oder LLM as a Judge?
Ein Entscheidungsmodell beantwortet vorab formulierte Prüffragen mit Wahrscheinlichkeiten und schreibt keinen Text. Es sagt, welche Antwort vorne liegt, aber nicht, warum.
Jev kennt drei Fragetypen (Ja/Nein, Auswahl und Skala) und beantwortet laut Doku alle Fragen parallel und isoliert. Structured Outputs geben einem LLM dagegen nur das Format vor, eine verlässliche Wahrscheinlichkeit garantieren sie nicht.
TypeSafe nennt 70 bis 500 Millisekunden pro Anfrage, bei 0,042 USD pro Million Input-Tokens und kostenlosem Output (Stand: September 2026).
Laut Datenschutzerklärung ist Jev „hosted in the United States“. TypeSafe veröffentlicht weder AVV noch Standardvertragsklauseln, und ob es beides auf Nachfrage gibt, ist offen. Über das Vercel AI Gateway gibt es AVV samt Standardvertragsklauseln und Zero Data Retention, aber keine EU-Region. Solange Vertrag und Übermittlungsgrundlage nicht geklärt sind, würde ich Jev mit proprietärem Code nicht produktiv einsetzen (eine Einordnung, keine Rechtsberatung).
Bei LLM as a Judge bewertet ein Sprachmodell Inhalte nach vorgegebenen Kriterien, frei im Text oder in einem festen Format. Populär gemacht haben den Ansatz Zheng et al. 2023. Die Reviewer, die beim KI-Code-Review als Vorfilter vor dem menschlichen Review laufen, schreiben ihre Befunde als Text. Das kostet: Claude Code Review braucht laut Anthropic im Schnitt rund 20 Minuten und 15 bis 25 USD pro Review (Stand: März 2026), allerdings für einen ganzen Bericht statt einzelner Entscheidungen.
Ebenso gut wie ein LLM zu urteilen, verspricht nicht einmal TypeSafe. Auf der Homepage steht: „Jev guarantees the shape of its answers, not that every decision is correct.“ Die Evals messen Übereinstimmung mit zwei LLMs statt Richtigkeit, und Jev liegt in allen vier Testabläufen unter dem besten LLM. Keiner davon ist Code Review.
Jevs Argument ist also der Preis pro Entscheidung und keine belegte Prüfqualität im Code Review. Er ermöglicht Prüfungen dort, wo ein Text-Reviewer zu teuer und zu langsam wäre: vor jedem Tool-Call eines Coding Agents.
Claude Code Hooks: eine Prüfung pro Tool-Call, aber nur als Filter
Die billige Vorprüfung läuft schon produktiv. Im Engineering-Post zum Auto Mode vom 25. März 2026 schreibt Anthropic: „Claude Code users approve 93% of permission prompts.“ Schutz bieten solche Abfragen nur, wenn Nutzer die riskanten Aktionen darunter erkennen.
Auto Mode prüft zweistufig: Ein „fast single-token filter“ sortiert vor, nur markierte Aktionen bekommen die teure Prüfung mit Chain-of-Thought. Die erste Stufe allein lag bei 8,5 % Fehlalarmen, beide zusammen im Echtbetrieb bei 0,4 %.
Die Kehrseite steht im selben Post: Von 52 tatsächlich übergriffigen Aktionen ließ der Filter 17 % durch, ungefähr jede sechste. Die Stichprobe ist klein, als alleinige Sperre taugt ein Filter mit dieser Quote trotzdem nicht.
Mit Hooks lässt sich das Muster vor eigene Tool-Calls setzen. Die Hook-Doku kennt dafür schon Prompt-Hooks, standardmäßig mit Haiku. Ein eigens dafür gebautes Entscheidungsmodell ändert vor allem Preis und Latenz pro Prüfung. Bei 50 geprüften Tool-Calls summiert sich Jevs Latenz rechnerisch auf bis zu 25 Sekunden.
Hooks können einen Tool-Call zwar sperren, scheitern aber offen: Timeout oder Verbindungsfehler eines HTTP-Hooks lassen ihn laut Doku durch (Stand: September 2026). Ein Modell im Hook bleibt deshalb ein Filter. Authentifizierung, Zahlungen und Secrets bleiben bei einer deterministischen Regel oder in einer Sandbox.
Schreibende Aktionen mit Freigabepflicht bleiben beim Menschen. Vorsortieren lässt sich aber weit mehr als Tool-Calls.
Triage, Stopp, LLM Router: Abläufe steuern, keine Rechte vergeben
Am nächsten liegt die Review-Triage, die festlegt, in welcher Reihenfolge Menschen prüfen. Laut Faros AI Engineering Report 2026 legten Pull Requests, die ohne jedes Review durch Mensch oder Agent gemergt wurden, in Phasen hoher KI-Nutzung gegenüber Phasen niedriger Nutzung um 31,3 % zu. Die Zahl zeigt einen Anstieg, keine Ursache.
Ein Entscheidungsmodell kann innerhalb einer Review-Spur, also einer vorab festgelegten Risikoklasse, ordnen, welchen Pull Request sich ein Mensch zuerst ansieht. Die Spur selbst legt das Architekturteam fest, weder Agent noch Review. Auf kritischen Pfaden mergt kein Agent, auch nicht bei einer Wahrscheinlichkeit von 0,99.
Wie vorsichtig ein erster Einbau aussieht, zeigt der Entwurf Roomote PR #2849 von Roo Code vom 17. September 2026. Er leitet unter anderem PR-Review-Benachrichtigungen durch Jev, handelt nur bei hoher Konfidenz und bleibt sonst beim bisherigen Verhalten. Die Schwellen sind Startwerte aus synthetischen Checks, und der projekteigene Review-Bot moniert, dass die Wahrscheinlichkeiten vor dem Routing nicht validiert sind.
Denkbar ist auch eine billige Frage nach jedem Agent-Schritt: Stopp oder weiter? Ein falsches Stopp bricht eine Aufgabe halb fertig ab, ein falsches Weiter verbrennt Tokens. Mir ist dafür bis heute kein gemessener Einsatz bekannt.
Model Routing, also die Wahl von Modell oder Pfad pro Anfrage, ist der dritte Kandidat. Welche Datenklasse welches Modell erreichen darf, bleibt trotzdem eine deterministische Regel, nie eine Wahrscheinlichkeit.
Ich ziehe die Linie bei den Berechtigungen: Innerhalb vorab erlaubter Abläufe darf das Modell ordnen, anhalten oder einen Pfad wählen. Zusätzliche Rechte vergeben oder eine vorgeschriebene menschliche Freigabe ersetzen darf es nicht, weil eine Wahrscheinlichkeit ohne Begründung keine erklärbare Prüfentscheidung ist. Und jede neue Andockstelle erzeugt weitere Prüfungen und Alarme, die ein Mensch lesen muss.
Auch billige Prüfungen kosten Aufmerksamkeit
TypeSafe hat Jev laut Launch-Blog nach William Stanley Jevons benannt, der 1865 argumentierte, sparsamer Umgang mit Kohle erhöhe den Verbrauch. Für KI-Prüfungen im Code ist dieses Jevons-Paradox bislang nur eine Erwartung: eher mehr Prüfungen und Fehlalarme als eine kleinere Rechnung. Rationiert wird trotzdem: Google hat Mutationstests erst tragfähig gemacht, indem es sie auf geänderten Code und eine begrenzte Zahl Mutanten pro Zeile und Review beschränkte.
Wo die Grenze liegt, zeigen Sadowski et al. in „Lessons from Building Static Analysis Tools at Google“ (CACM, 2018): Ein Analyzer im Code Review wird abgeschaltet, wenn mehr als 10 % seiner Hinweise als „Not useful“ markiert werden. Die Schwelle ist nach eigener Angabe „somewhat arbitrarily“ gewählt, also eine Faustregel.
Werkzeuge mit zu vielen Fehlalarmen verlieren laut Paper das Vertrauen der Entwickler. Wer den Ergebnissen vertraute, forderte dagegen weitere Analysen an. Die Grenze setzte die Quote der Hinweise, denen niemand nachgeht, nicht der Preis.
Was einen Hinweis nützlich macht, entscheidet sich also, bevor das Modell rechnet: bei der Prüffrage.
Von der Code-Review-Checkliste zur Prüffrage
Der nützlichste Befund aus TypeSafes Benchmark betrifft gar nicht Jev. Jedem Modell hilft es laut TypeSafe, eine Richtlinie in einzelne typisierte Fragen zu zerlegen: „every model is more accurate, cheaper and faster in the workflow than it is with the same policy as a prompt“ (evals.typesafe.ai). Gemessen hat das bisher nur der Hersteller selbst.
Mein Test zeigt die Kehrseite: Wer die Prüffragen schreibt, legt fest, was das Modell finden kann.
Eine Code-Review-Checkliste in Prüffragen braucht deshalb wie jede Regel im Repository jemanden, der sie verantwortet. Eine Person schreibt die Frage, eine zweite prüft sie, Änderungen laufen versioniert durch einen Pull Request.
Jede Frage ist neutral formuliert, weil Sprachmodelle einer Behauptung im Material eher zustimmen (Sharma et al.). Getestet wird sie mit einer umgepolten Gegenfrage, weil offen ist, ob Modelle eher zu Ja oder zu Nein neigen (Braun 2025), und an einer bereinigten Codevariante, bei der die Antwort kippen muss.
Was Compiler und Linter ohnehin melden, gehört nicht ins Modell. Widersprechen sich zwei der isoliert beantworteten Fragen wie in meinem Lauf, entscheidet eine feste Regel im eigenen Code, nicht das Modell.
Prüffragen decken festgelegte Kriterien für die geänderten Zeilen ab. Ob es die Änderung überhaupt braucht, entscheidet weiter ein Mensch.
Auch die sauberste Frage liefert nur eine Wahrscheinlichkeit, und deren Schwelle bedeutet erst auf dem eigenen Code etwas.
Kalibrierung: was vor dem Einsatz gemessen sein muss
Kalibriert heißt nach Guo et al.: Von 100 Vorhersagen mit 0,8 stimmen rund 80. Wer eine 0,9 als Trefferquote liest, setzt genau das voraus, und für den eigenen Code belegt es kein Anbieter.
Seit dem 16. September liefert das Vercel AI SDK ein solches Wahrscheinlichkeitsfeld auch für Modelle von OpenAI, Anthropic und Google. Vercels eigener PR nennt die Werte „prompted estimates without a calibration guarantee“, also Schätzungen ohne Kalibrierungszusage. Das Modell hinter dem Feld lässt sich tauschen, die gemessene Schwelle wandert nicht mit. Schwellen im Betrieb sind damit eine Architektur- und Messentscheidung.
TypeSafe veröffentlicht keine Kalibrierungsdaten, und mir ist zum 17. September kein unabhängiger Test an echtem Code Review bekannt. Am ehesten vergleichbar ist Gaurav Gosains jev-sec-bench. Er misst auf synthetischem Code einen gut dreimal so hohen Kalibrierungsfehler wie bei Prompt Injection. Als Einzelmessung mit eingeräumtem Labelrauschen ist das nur ein Warnsignal.
Eine Antwort „weiß nicht“ kennt Jev nicht, jede Frage bekommt eine Zahl. Die Enthaltung übernimmt also die Schwelle, und eine ungemessene Schwelle ist eine geratene Enthaltung.
Bevor eine Schwelle in Hooks oder Triage wandert, sollte die Führung deshalb eine Messung anordnen: Eigene Reviewer bewerten eigene Pull Requests, gezählt werden übersehene Probleme, Fehlalarme und zusätzliche Prüfzeit. Als Faustregel braucht es rund 100 Fälle pro Wahrscheinlichkeitsbereich, um 0,9 von 0,8 zu trennen. Selbst dann reicht das 95-%-Intervall nach Wilson bei 90 % Treffern noch von 82,6 bis 94,5 %. Die Triage-Urteile gehören dafür von Anfang an ins Protokoll.
Der nächste Schritt ist ein begrenzter Versuch ohne Eingriff in bestehende Freigaben, mit Code, der in die USA übermittelt werden darf. Eine benannte Person verantwortet ihn und legt vorab fest, wann ein Mensch übernimmt und wann der Versuch endet. Erst dann bekommt das „unter 0,4“ aus meinem Test eine Bedeutung.
