A push gate that quizzes you on your AI's code ships its own unresolved false negatives

npm install -g sphinx-understand, dann git push. Git stoppt an den geschützten Branches. Ein Modell, das deine Chat-Sitzung nie gesehen hat, liest den Diff und stellt dir eine Frage dazu, was die Änderung tatsächlich bewirkt. Beantwortest du sie falsch, erklärt es dir warum und stellt eine andere Frage zu einem Szenario, das auf demselben Konzept aufbaut. Beantwortest du sie richtig, läuft der Push weiter. sphinx yolo lässt den Push durch und protokolliert das Überspringen.

Das ist Sphinx, MIT-lizenziert, 117 Sterne, ein Git-Hook für agentenunterstützte Entwicklung. Der Claim auf der Website ist ein Zitat von Sun Tzu: Dein Denken kannst du auslagern, dein Verständnis nicht. Der Show-HN-Thread erreichte 242 Punkte und 85 Kommentare und spaltete sich fast gleichmäßig zwischen der Frage, für wen das gedacht ist, und Leuten, die dasselbe gebaut haben. In diesem Thread gibt es ein zweites Projekt, das eine Version auf Pull-Request-Ebene umsetzt.

Zu dieser Debatte habe ich nicht viel hinzuzufügen. Was mich interessiert, ist, dass das Repository ein eval/-Verzeichnis mitliefert, und dieses eval-Verzeichnis ist ein besseres Artefakt als das Produkt selbst.

Ein Verständnis-Gate ist eine Testsuite, bei der das getestete Objekt eine menschliche Erklärung in Freitext ist. Der Bewerter ist ein Modell. Man hat also LLM-as-judge gebaut, auf Prosa gerichtet und das Ergebnis mit einem harten Stopp beim Push verbunden. Das ist ein Design mit einem sehr spezifischen Fehlermodus, und die meisten Projekte, die so etwas ausliefern, schreiben nie auf, welcher das ist.

Sphinx hat es aufgeschrieben. eval/RESULTS.md beendet einen Live-Lauf mit diesem Satz: "The result is not an all-green semantic evaluation, despite all 560 guarded unit/integration tests passing."

560 grüne Tests, und der Autor sagt einem, dass die semantische Evaluierung nicht grün ist. Diese Unterscheidung ist der Kern des Ganzen. Unit-Tests verifizieren, dass die Pipeline Bytes korrekt bewegt. Sie sagen nichts darüber aus, ob der Bewerter deine Antwort akzeptiert hätte.

Das Repository führt eine Datei namens eval/fixtures/known-false-negatives.json. Ihr scope-Feld lautet: "Synthetic fixture questions and authored answers only. These are known failures, not passing model assertions." Die eval-README nennt sie "unresolved regressions, not passing tests".

Beide Einträge enthalten eine menschliche Antwort, das Urteil, das das Modell gefällt hat, das Feedback des Modells und einen unabhängigen Befund, dass das Urteil falsch war.

Fall eins ist eine CSS-Frage. Der Diff fügt eine Regel a.card.button hinzu, die nur padding-block setzt, auf einer Basisregel base.button aufbauend. Die Frage verlangt, vorherzusagen, welche Achse sich bei einem Card-Button und bei einem Toolbar-Button ändert, und warum. Die verfasste Antwort sagt, der Toolbar-Button sei nicht betroffen, weil der neue Selektor einen Card-Vorfahren benötigt, und dass das horizontale Padding unverändert bleibe, weil die Basisregel es weiterhin liefert.

Der Bewerter markierte sie als mehrdeutig, mit diesem Feedback: "It never states that the vertical (block-direction) padding is what changes for Complete task, so the required per-axis prediction is missing."

Lies das noch einmal gegen die Antwort. Die Antwort beschrieb das neue Card-Padding plus das unveränderte horizontale Padding, womit genau eine Achse übrig bleibt. Sie nannte den Vorfahren-Scope. Sie nannte die unveränderte Toolbar-Grenze. Die Bestehensbedingung des Bewerters war zu einer Vokabelprüfung auf das Wort "vertical" zerfallen.

Das ist auch kein Ausrutscher einer einzigen billigen Route. Ein späterer Lauf spielte dieselbe Frage und Antwort gegen ein stärkeres Modell und reproduzierte das falsche Negative in einer Anfrage, in 4,6 Sekunden. Der Bericht weist darauf hin, dass die Abbruchbedingung den Vergleich an dieser Stelle beendete, sodass es keine Behauptung gibt, das stärkere Modell falle in der breiteren Matrix durch.

Fall zwei ist Autorisierung. Der Patch verschmilzt eine Missing-Document-Prüfung und eine Cross-Tenant-Prüfung zu einer Bedingung, die dasselbe { status: 404 } zurückgibt. Die verfasste Antwort sagt, ein anderer Tenant erhalte einen 404 ohne Body, "genau wie bei einer fehlenden id". Der Bewerter wollte ein explizites "nein" und den wörtlichen Mechanismus der zusammengeführten Bedingung.

Der Teil, der stören sollte: Der Bericht sagt, dass die quellengeprüften Akzeptanzkriterien selbst unnötigerweise eine einzige kombinierte Bedingung nannten. Die Prüfung, die das Bewerten fairer machen sollte, hatte die Vokabelanforderung in den Schlüssel eingebrannt. Der Autor stellt ausdrücklich klar, dass sowohl die Frage-Schlüssel als auch die akzeptierten Ersetzungen quellkorrekt waren und dass Quellkorrektheit die ausreichende Antwort nicht fair bewertet hat.

Hier ist der Teil, der mehr wert ist als das Tool. Die eval-README dokumentiert, wie man ein bekanntes falsches Negative erneut abspielt:

Um eines wiederzuspielen, wähle seine source.caseId aus CASES, lege die gespeicherte source.definition darüber und rufe createFixture(fixture, config) auf. Lies die unveränderlichen Beweise mit createReviewWorkspace(snapshot, config, { env }) und canonicalEvidence(snapshot, record.source.requiredPaths, workspace), erstelle dann ein Review, das an diese neue snapshot.id gebunden ist, und rufe evaluator.gradeAnswer auf. Nutze den vorhandenen metered evaluator transport und ein explizites Live-Budget.

Dann die Einschränkung, die daraus einen echten Test statt einer Demo macht: "do not reuse an old temporary snapshot ID, re-audit to an easier question, or replace the saved human answer."

Das ist der Unterschied zwischen einem Benchmark und einer Marketingseite. Die gespeicherte Antwort ist eingefroren. Man kann den Bewerter, die Kriterien, den Prompt, die Modellroute ändern und gegen die identische Eingabe erneut laufen lassen. Wenn man die Frage so lange umschreibt, bis sie besteht, hat man den Test verändert, und die Datei sagt genau das laut aus.

Auf der anderen Seite gibt es eine passende Absicherung. npm test und npm run check laden einen Netzwerk-Guard in Node und seine Kindprozesse, der ausgehende fetch-, HTTP- und Socket-Aufrufe ablehnt und Loopback erlaubt. Der angegebene Grund: Ein partielles Modell-Mock soll nicht in der Lage sein, stillschweigend einen echten Anbieter zu erreichen. Für ein Projekt, dessen ganze Aufgabe darin besteht, deterministische Aussagen über einen nichtdeterministischen Bewerter zu machen, ist das der richtige Instinkt.

Der Konfigurationsfall ist die andere Lektion. Das Fixture fragte nach einer BATCH_SIZE-Präzedenzregel mit der Formulierung "BATCH_SIZE is set to 5". Der unabhängig verfasste Probe-Adapter erkannte nur BATCH_SIZE=number und beantwortete deshalb ein anderes Szenario mit einem anderen Wert.

Die Schlussfolgerung des Berichts ist der nützliche Teil: "That is an uncovered scenario, so this result does not establish how the model would grade a sufficient answer to the stated input."

Ein rotes Ergebnis von einem Fixture, das die angegebene Eingabe nie vorgelegt hat, sagt nichts über den Bewerter aus. Es sagt etwas über das Fixture aus. Wenn dein Evaluierungsbericht diese beiden Fälle nicht unterscheidet, ist jede rote Zahl Rauschen, dem man eine Woche hinterherjagt.

Derselbe Lauf erzeugte auch eine Rohantwort, die die Vorhersage als mehrdeutig bezeichnete, kein wesentliches Missverständnis einräumte und dann incorrect ohne required transfer auswarf. Die Validierung wies die fehlerhafte Bewertung zurück. Das ist wieder eine andere Fehlerklasse: ein Bug im Antwortformat in den Kleidern eines semantischen Fehlers.

Nach der Wiederholung des falschen Negativen sagt der Bericht, das mehrdeutige Ergebnis "leaves the checkpoint pending and grants no approval; safe noncompletion is separate from fair grading."

Das sind zwei unterschiedliche Eigenschaften, und sie werden ständig vermischt. Ein Gate, das beim Versagen des Bewerters nach dem Fail-closed-Prinzip blockiert, ist sicher. Es ist nicht korrekt, und es ist nicht fair gegenüber der Person, die eine gute Antwort geschrieben hat. Teams, die ein Verständnis-Gate oder ein KI-Review-Gate einführen, prüfen meist nur die erste Eigenschaft.

Dieselbe Frage stellt man generell an KI-Code-Review-Tools. Wenn man Optionen vergleicht, sollte man fragen, was das Tool über die Läufe veröffentlicht, die es falsch gemacht hat. Ein Changelog mit Fixes ist nicht dasselbe Artefakt wie eine eingefrorene Liste von Antworten, die weiterhin falsch bewertet werden. Manche Projekte veröffentlichen das Zweite, manche nicht, und diejenigen, die es tun, kann man eher mit einem blockierenden Check in der Pipeline vertrauen. Das ist die erste Frage, die ich an Kodus oder jeden anderen Reviewer stellen würde, den man in CI einbinden will.

Das Repository hat außerdem seine Assessment-Policy auf Contract-Version 3 angehoben, sodass Fragen und Belege, die unter dem früheren Contract erstellt wurden, nicht stillschweigend wiederverwendet werden. Wenn man Prompts versioniert, sollte man auch die von ihnen erzeugten Artefakte versionieren, sonst autorisiert ein veralteter Beleg einen Push unter Regeln, die nicht mehr existieren.

Vier Dinge, und sie entsprechen den Fehlerklassen oben.

Ob das Projekt eine Datei mit den Dingen führt, die es derzeit falsch macht. Eine Liste der Erfolge ist leicht. Eine eingefrorene Liste ungelöster Fehler ist das Artefakt, das zeigt, dass die Autoren messen.

Ob man eine gespeicherte Eingabe durch einen veränderten Bewerter mit explizitem Kostenbudget erneut laufen lassen kann. Wenn die Wiederholung einer festgelegten Antwort das Neuschreiben der Frage erfordert, kann man keinen Fix messen.

Ob eine nicht abgedeckte Eingabeformulierung als nicht abgedeckt statt als fehlgeschlagen gemeldet wird. Sonst füllt sich das Dashboard mit Fehlern, die nie stattgefunden haben.

Ob "der Push wurde blockiert" als Erfolgsmetrik für sich gemeldet wird. Blockieren lässt sich leicht erreichen, indem man schlecht bewertet. Die entscheidende Metrik ist, wie viele ausreichende Antworten akzeptiert wurden.

Nichts davon spricht gegen das Tool. Es spricht dafür, dass das eval-Verzeichnis der Grund ist, sich das Repository anzusehen, und dass ein Gate, das dein Verständnis bewertet, zuerst sein eigenes Verständnis geprüft bekommen muss. Die Autoren haben die beiden Fälle veröffentlicht, in denen es theirs nicht war.