Meta erklärt Catching JiTTests: Für jede Änderung gebaute Tests, die fehlschlagen sollen, Schlüsselrolle beim Abfangen von 74 schweren Datenschutzfehlern im ersten Halbjahr, so Meta

Am 29. Oktober 2026 hat das Engineering-Team von Meta beschrieben, wie „Catching JiTTests“ (Just-in-Time-Fangtests) in der Produktion läuft: Ein großes Sprachmodell erzeugt für jede vorgeschlagene Codeänderung ausführbare Tests, die so gebaut sind, dass sie fehlschlagen, und das Fehlschlagen deckt einen von der Änderung eingeführten Fehler auf. Laut Meta hatten sich zum Zeitpunkt des Schreibens 589 Ingenieure damit befasst, und die Ingenieure meldeten eine Quote echter Treffer von 60 Prozent. Im ersten Halbjahr 2026 habe das System eine Schlüsselrolle dabei gespielt, 74 schwere (SEV) Datenschutzfehler schon in der Diff-Phase abzufangen.

Meta grenzt den Ansatz von üblichem KI-Code-Review ab. Die meisten LLM-basierten Verfahren lesen Code wie ein menschlicher Prüfer und schätzen aus Erfahrung, wo ein Fehler stecken könnte. Catching JiTTests erzeugt stattdessen Tests, die einen konkreten Verhaltensunterschied der Änderung belegen. Meta räumt ein, dass dies mehr Rechenschritte braucht, sagt aber, es fange Fehlerklassen, die LLM- oder Agenten-Reviews übersehen könnten. Die Schwierigkeit ist der Maßstab: Bei Hunderten Millionen sich ständig ändernder Codezeilen enthalten die Tests „starke Treffer“, die echte Fehler zeigen, und „schwache Treffer“, die Fehlalarme sein können, und das System muss beide automatisch trennen, ohne die Ingenieure zu bremsen.

Das System arbeitet in fünf Stufen. Stufe 1 ist Auswahl und Auslösung: Es läuft nachts auf freier Kapazität und bearbeitet nur Diffs vom Vortag, die als riskant eingestuft werden, mit einem Mechanismus ähnlich dem Diff Risk Score, trainiert auf früheren Codeänderungen. Stufe 2 besteht aus zwei parallelen Testerzeugungs-Abläufen. Der „Dodgy-Diff“-Ablauf behandelt jedes Diff als Mutante, also als Version mit einem Fehler, und nutzt mutationsgeleitete LLM-Testerzeugung, um Tests zu bauen, die das Verhalten des Diffs von dem seines Vorgängers trennen, ohne eine Absicht abzuleiten; ziel ist ein größerer Vorrat schwacher Treffer. Der „Intent-aware“-Ablauf lässt zunächst ein LLM die Absicht des Diffs aus Änderungen, Titel und Zusammenfassung ableiten und die Risiken beschreiben, also Wege, auf denen die Umsetzung dieser Absicht schiefgehen könnte. Daraus baut er Mutanten und erzeugt Tests, die jede Mutante „töten“. Diese Tests laufen dann auf dem echten Diff, und die fehlschlagenden werden als schwache Treffer gesammelt.

Stufe 3 ist das LLM-as-Judge-Ensemble: mehrere moderne Modelle prüfen den Testcode des schwachen Treffers, das Ausführungsergebnis (Fehlercode, Meldung, Trace), die Differenz zwischen Vorgänger und Nachfolger und die abgeleitete Absicht und urteilen, ob es eher ein Fehlalarm oder ein echter Fehler ist. Stufe 4 ist RubFake, ein regelbasierter Bewerter, der überprüfte, deterministische Urteile liefert und so die Nichtdeterminismus- und Verifizierbarkeitsschwäche von LLM-Urteilen ausgleicht; gemeinsam ordnen sie die schwachen Treffer. Stufe 5 ist Human-on-the-Loop: Das System entscheidet anhand der Rangfolge, ob es einen Ingenieur anspricht, und Ingenieure legen Kriterien fest und prüfen Ergebnisse aggregiert, statt jede Ausgabe zu überwachen.

Mehrere der genannten Zahlen müssen mit ihren Grenzen gelesen werden. Die 589 Ingenieure sind 64 Prozent von Metas Ansprachen, doch der Beitrag nennt die Gesamtzahl der Ansprachen nicht. Die Quote von 60 Prozent echter Treffer ist das, was Ingenieure gemeldet haben. Catching JiTTests habe eine Schlüsselrolle beim Abfangen der 74 schweren Datenschutzfehler gespielt, und der Beitrag nennt das im selben Satz wie einen Rückgang der Datenschutz-SEVs insgesamt um 20 Prozent im selben Zeitraum, liefert aber keine Vergleichsbasis und sagt nicht, dass das System der einzige Grund war. Vergleichstabellen und Wirkungsdiagramm sind im Original Bilder, und keiner ihrer Werte wird hier verwendet.

Übernehmen können andere Teams die Form der Pipeline: wenige riskante Diffs per Risikoscore auswählen, Tests erzeugen, die einen Verhaltensunterschied belegen, Fehlalarme mit Modellen und Regeln filtern und einen Menschen nur dann stören, wenn ein Fall weit oben steht. Die Grenzen sind ebenso klar: Die Zahlen stammen aus Metas eigenem Einsatz, der Preis ist zusätzliche Rechenleistung, und die Ergebnisse betreffen Datenschutzfehler, lassen sich also nicht auf jede Fehlerart übertragen.