Meta : tester chaque diff comme s'il était un bug

Ce qui se passe

Meta dresse le bilan de Catching JiTTests, son système de tests « juste à temps », passé du prototype de recherche à son infrastructure. L'idée s'écarte de la revue de code par LLM : plutôt qu'un avis sur le code, on obtient un test exécutable qui montre une différence de comportement introduite par le changement.

L'entreprise avance ces résultats pour le premier semestre 2026 :

• 74 bugs graves (SEV) de confidentialité interceptés au stade du diff
• 20 % d'incidents de confidentialité en moins sur la période
• 589 ingénieurs ayant réagi, soit 64 % des personnes sollicitées
• 60 % de vrais positifs, selon ces ingénieurs

Le mécanisme

Le traitement tourne la nuit, sur de la capacité inutilisée. Deux voies alimentent la réserve de candidats :

• Dodgy diff présume que le changement est fautif et cherche un test séparant son comportement de celui du commit parent, sans se demander ce qu'il voulait faire.
• Intent-aware déduit l'intention à partir du code, du titre et du résumé, énumère ce qui pourrait mal tourner, en tire des mutants, puis écrit les tests qui les détectent. Ces tests sont rejoués sur le vrai diff.

La difficulté est le tri entre vrais problèmes et bruit. Meta combine un ensemble de LLM qui lisent le test, sa trace d'exécution, le diff et l'intention déduite, et un moteur à règles déterministe, RubFake, dont les verdicts se vérifient. L'humain n'est plus dans chaque boucle : il fixe les critères et juge l'ensemble, et n'est appelé que pour confirmer si un changement observé était voulu.

Ce qui limite la portée

Ces chiffres sont déclarés par Meta. Le système s'appuie sur un score de risque entraîné sur son historique et sur sa puissance de calcul. Le billet ne fournit aucun code : le détail se trouve dans un article présenté à FSE 2026. Et 60 % de vrais positifs laissent quatre alertes sur dix à écarter : sans tri, l'attention s'use vite.

Comment s'y prendre

Le principe se teste sans l'usine, sur un changement sensible :

1. Demandez à votre agent d'écrire un test qui échoue sur le diff et passe sur le parent, plutôt qu'une revue.
2. Demandez-lui d'abord de formuler l'intention et trois façons de la rater, puis un test par risque.
3. Vérifiez vous-même chaque échec : un test ne vaut que si le comportement mis en évidence n'était pas voulu.
4. Ne gardez pas ces tests par défaut : ils servent à interroger un changement précis.

Cette recette est notre transposition, pas un protocole de Meta.

Source : Meta Engineering, 29 octobre 2026. Source en anglais.