589 Ingenieure bei Meta haben Ergebnisse eines Testsystems geprüft, das Fehler findet, bevor Code ausgerollt wird. Das sind 64 Prozent aller Entwickler, die das System angeschrieben hat. Die Zahl steht in einem Bericht über den Produktivbetrieb der Catching JiTTests. Eine Plattform mit Hunderten Millionen Zeilen Code lässt sich nicht von Hand absichern. Das Meta-Team beschreibt sein Verfahren in dem Paper „Just-in-Time Catching Test Generation at Meta“.
Ein Vergleich aus dem Bauwesen hilft. Wer ein Haus umbaut, kann die Pläne noch einmal gegenlesen lassen oder prüfen, ob die Tür am Ende noch schließt. Klassisches LLM Code Review macht das erste: Ein Modell liest die Änderung und urteilt aus Erfahrung, ob sie verdächtig aussieht. Just-in-Time-Tests machen das zweite: Sie erzeugen ausführbaren Code, der einen Verhaltensunterschied sichtbar macht, und lassen ihn laufen. Der Unterschied ist praktisch: Das eine Verfahren bewertet Code, das andere führt ihn aus.
Was Just-in-Time-Tests von klassischem LLM Code Review unterscheidet
Die meisten KI-gestützten Verfahren zur Fehlererkennung arbeiten wie ein zusätzlicher Reviewer. Ein Modell oder Agent geht den Diff durch und markiert Stellen, die nach bekanntem Muster schiefgehen könnten. Das ist schnell und billig, hat aber eine Grenze: Das Modell urteilt über Code, statt ihn zu testen. Es übersieht, was es nicht kennt, und es kann nichts beweisen. Laut dem Meta-Team bleibt damit eine ganze Klasse von Fehlern unentdeckt.
Just-in-Time-Tests setzen eine Ebene tiefer an. Das System generiert einen Test, der genau dann scheitert, wenn die Änderung unbeabsichtigtes Verhalten einführt. Ein solcher Test ist ein konkreter Beleg für einen Verhaltensunterschied, keine bloße Meinung. Der Preis ist Rechenzeit: Kandidatentests müssen erzeugt, ausgeführt und ausgewertet werden. Dafür fallen Fehler auf, die ein reines Review nie sieht, weil sie erst im Zusammenspiel mit bestehendem Code sichtbar werden.
Zwei Workflows: Dodgy Diff und Intent-Awareness
Zwei Verfahren arbeiten parallel an derselben Frage. Der eine Weg heißt intern „dodgy diff“ und behandelt jede Codeänderung so, als wäre sie selbst der Bug. Er baut aus dem Diff einen Mutanten und sucht per mutation-gesteuerter Testgenerierung nach Tests, die das Verhalten des Mutanten von dem des Elternstands unterscheiden. Man setzt also voraus, dass etwas kaputt ist, und sucht den Beweis. Das erzeugt viele schwache Treffer. In einem großen Pool steigt damit die Chance auf einen echten Fund.
Der zweite Weg arbeitet intent-aware. Ein Sprachmodell liest Titel, Zusammenfassung und Diff und leitet daraus ab, was die Änderung erreichen soll. Aus dieser Absicht formuliert es Risiken – Wege, auf denen ein Umsetzungsversuch danebenliegen könnte – und baut daraus gezielte Mutanten. Tests, die einen solchen Mutanten töten, werden anschließend gegen den echten Diff gefahren. Scheitern sie dort, gelten sie als schwacher Treffer. Beide Workflows laufen zusammen, weil sie unterschiedliche Fehlerbilder abdecken: Der eine findet das Unerwartete, der andere das plausibel Danebengegangene.
Fünf Stufen vom nächtlichen Lauf bis zur Anfrage beim Ingenieur
Der Betrieb läuft in fünf Stufen. Zuerst wird ausgewählt: Das System arbeitet nachts auf freien Kapazitäten und nimmt sich die Diffs des Vortags vor, die über einen Risikowert als verdächtig eingestuft wurden. Niemand will für jede Zeile Code das volle Programm fahren. Danach folgt die Testgenerierung über die beiden beschriebenen Workflows. Aus den Läufen entsteht ein Pool schwacher Kandidaten.
In der dritten Stufe urteilt eine Gruppe aus mehreren Sprachmodellen, intern LLM-as-Judge genannt. Sie bekommt Testcode, Ausführungsergebnis mit Fehlercode und Trace, Diff und abgeleitete Absicht vorgelegt und schätzt ein, ob ein schwacher Treffer ein echter Fehler oder ein Fehlalarm ist. Weil solche Urteile nicht deterministisch sind, ergänzt eine vierte Stufe sie um einen regelbasierten Prüfer namens RubFake, der reproduzierbare, nachvollziehbare Entscheidungen liefert. Aus beiden Bewertungen entsteht eine Rangfolge. Erst in der fünften Stufe entscheidet das System, ob ein Mensch eingeschaltet wird.
False Positives reduzieren: LLM-as-Judge trifft RubFake
Der aufwendigste Teil ist nicht das Finden von Tests, sondern das Aussortieren der falschen. Wer bei jedem zweiten Fehlalarm einen Entwickler behelligt, hat nach zwei Wochen niemanden mehr, der noch hinsieht. Deshalb kombiniert Meta zwei Bewertungslogiken mit unterschiedlichen Schwächen. Das Sprachmodell versteht Semantik und Kontext, urteilt im Detail aber unzuverlässig. Der regelbasierte Prüfer ist deterministisch und verifizierbar, erfasst aber nur, was sich in Regeln fassen lässt.
Zusammen ergeben sie eine Rangfolge, in der aussichtsreiche Kandidaten oben stehen. Man muss nicht jeder KI-Entscheidung glauben, sondern wissen, welchen man trauen darf. Für Teams, die automatisierte Fehlererkennung einführen wollen, zählt vor allem eins: Wie viele Fehlalarme landen am Ende beim Menschen? Nicht das größte Modell entscheidet über die Akzeptanz.
Human-on-the-loop: prüfen am Aggregat statt an jedem Einzelfall
Der Bericht unterscheidet Human-in-the-loop und Human-on-the-loop. Beim ersten Verfahren sitzt ein Mensch an jedem Output und nickt ihn ab. Beim zweiten setzt er die Kriterien, beobachtet die Ergebnisse in der Summe und greift auf Ebene der Regeln ein, nicht pro Fall. Die Logik ähnelt einer Sicherheitskontrolle am Flughafen: Man stellt den Scanner ein und schaut sich die Ausreißer an, statt jedes Gepäckstück von Hand zu öffnen.
Für die Ingenieure heißt das: Sie lesen selten Testcode. Meist bestätigen sie nur, ob eine beobachtete Verhaltensänderung beabsichtigt war. Das verlagert den Aufwand vom Einzelfall auf die Policy, und das System bremst die Geschwindigkeit nicht aus. Wer KI-generierte Tests für Codeänderungen einführt, sollte diese Rollenverteilung von Anfang an mitdenken. Sonst wird aus der Entlastung eine neue Warteschlange.
Was 60 Prozent Trefferquote konkret bedeuten
Die Zahlen aus dem Produktivbetrieb zählen. Von den Ergebnissen, die das System gemeldet hat, waren 60 Prozent echte Treffer, also Fehler, die Entwickler als relevant bestätigt haben. In der ersten Hälfte des Jahres 2026 hat der Ansatz 74 schwerwiegende Privacy-Bugs auf Diff-Ebene abgefangen, bevor sie in Produktion landeten. Im gleichen Zeitraum sank das Aufkommen solcher Vorfälle um 20 Prozent. Das sind keine Laborwerte, sondern Messungen aus einer Plattform mit Hunderten Millionen Zeilen Code.
Der Bericht nennt auch Grenzen. Der Ansatz braucht freie Rechenkapazität, belastbares Risiko-Scoring und eine Kultur, in der Fehlalarme nicht als Störung gelten. Ein kleines Team wird die Infrastruktur nicht nachbauen. Das Muster lässt sich aber übertragen: Erfolgskriterien früh definieren, die Prüfung von der KI ausführen lassen, Ergebnisse aggregiert beobachten und auf Ebene der Kriterien nachjustieren statt in jedem Einzelfall. Wer Bugs vor dem Deployment erkennen will, braucht keinen Konzern, sondern eine klare Antwort auf die Frage, wer am Ende urteilt.
Das Paper wurde auf der FSE 2026 vorgestellt und war dort Teil des Programms zu Product@Scale. Wer die Details nachlesen will, findet dort die vollständige Beschreibung des Deployments. Der Nutzen entsteht nicht dadurch, dass ein Modell klüger urteilt als ein Mensch. Er entsteht dadurch, dass Maschinen die Tests bauen und der Mensch nur entscheidet, ob das beobachtete Verhalten gewollt war.
Quelle: engineering.fb.com
