‏متا با JiTTests باگ‌ها رو قبل از merge شکار می‌کنه

تیم مهندسی متا تو این پست می‌گه روش Catching JiTTests (مخفف Just-in-Time Tests) دیگه یه پروتوتایپ تحقیقاتی نیست و حالا بخشی از زیرساخت متاست. ایدهٔ اصلی اینه که برای هر diff (یعنی تغییر کدی که قراره merge بشه) با LLM تستی ساخته بشه که روی کد جدید fail بشه و یه تفاوت رفتاری واقعی رو نشون بده. فرقش با ابزارهای AI مرسوم اینه که اونا فقط کد رو مثل یه بازبین آدم می‌خونن، ولی این روش تست اجرایی می‌سازه. محاسبهٔ بیشتری می‌خواد، اما به گفتهٔ متا باگ‌هایی رو می‌گیره که code review با LLM از دستش می‌ره.

سیستم شب‌ها روی ظرفیت اضافهٔ سرورها اجرا می‌شه و فقط diffهای «پرریسک» روز قبل رو هدف می‌گیره. این انتخاب با مکانیزمی شبیه Diff Risk Score انجام می‌شه که روی تغییرات قبلی آموزش دیده. بعد دو جریان موازی تست تولید می‌کنن. جریان dodgy diff فرض می‌کنه خود diff یه باگه و تست‌هایی می‌سازه که رفتارش رو از نسخهٔ قبلی جدا کنه. جریان intent-aware اول با LLM هدف diff رو از کد، عنوان و توضیحش حدس می‌زنه و ریسک‌هاش رو می‌نویسه.

بعد از روی اون ریسک‌ها mutant می‌سازه (یعنی نسخه‌ای از کد با یه باگ عمدی) و تست‌هایی تولید می‌کنه که این mutantها رو لو بدن. این تست‌ها روی diff واقعی اجرا می‌شن و هر کدوم fail بشه به‌عنوان «weak catch» جمع می‌شه. weak catch یعنی تستی که ممکنه باگ واقعی پیدا کرده باشه یا فقط یه false positive باشه.

برای جدا کردن این دو، دو لایه کار می‌کنن. LLM-as-Judge مجموعه‌ای از چند LLM پیشرفته‌ست که کد تست، خروجی اجرا، خود diff و هدف حدس‌زده‌شده رو بررسی می‌کنن. ولی قضاوتشون قطعی و قابل‌تأیید نیست، برای همین یه سیستم قانون‌محور به اسم RubFake کنارشون هست که نتیجهٔ قطعی و تأییدشده می‌ده. این دو با هم موارد رو رتبه‌بندی می‌کنن و فقط موارد بالای جدول به مهندس‌ها می‌رسه.

متا به‌جای human-in-the-loop (که آدم همهٔ خروجی‌ها رو چک کنه) از human-on-the-loop استفاده می‌کنه. یعنی مهندس‌ها معیارها رو تعیین می‌کنن و نتیجه‌ها رو در سطح کلی می‌بینن، نه تک‌به‌تک. نویسنده‌ها می‌گن این‌طوری مهندس تقریباً هیچ‌وقت لازم نیست کد تست رو بخونه و فقط باید بگه این تغییر رفتار عمدی بوده یا نه.

تا الان ۵۸۹ مهندس (۶۴ درصد کسایی که سیستم بهشون پیام داده) باهاش تعامل داشتن و ۶۰ درصد یافته‌ها true positive بودن. تو نیمهٔ اول ۲۰۲۶ این روش ۷۴ باگ جدی (SEV) حریم خصوصی رو قبل از production گرفته و تعداد کل SEVهای حریم خصوصی تو این مدت ۲۰ درصد کم شده. جزئیات کامل تو مقالهٔ «Just-in-Time Catching Test Generation at Meta» اومده که تو FSE 2026 ارائه شد.

نکات کلیدی:

• JiTTests برای هر diff پرریسک تست اجرایی می‌سازه، نه فقط review متنی.
• دو جریان تولید تست داره: dodgy diff و intent-aware (مبتنی بر mutant).
• فیلتر false positive با ترکیب LLM-as-Judge (چند LLM) و سیستم قانون‌محور RubFake انجام می‌شه.
• ۵۸۹ مهندس درگیرش شدن و نرخ true positive حدود ۶۰ درصده.
• تو نیمهٔ اول ۲۰۲۶، ۷۴ باگ SEV حریم خصوصی گرفته شد و SEVهای حریم خصوصی ۲۰ درصد کم شدن.