‏FrontierCode: بنچمارکی که کیفیت کد رو می‌سنجه نه فقط درستیش

به گفتهٔ تیم Cognition، بنچمارک‌های امروزی کدنویسی ثابت کردن که مدل‌ها می‌تونن کد درست بنویسن، ولی حالا که کد تولیدشده با AI داره مسیر اصلی رسیدن به production می‌شه، درست بودن دیگه حداقل کاره. سؤال واقعی اینه که آیا مدل‌ها می‌تونن کد خوب بنویسن؟ برای همین FrontierCode رو ساختن، بنچمارکی که می‌سنجه مدل‌ها چقدر می‌تونن استاندارد یه codebase باکیفیتِ production رو رعایت کنن.

نکتهٔ اصلی که این بنچمارک رو متمایز می‌کنه اینه: آیا maintainer واقعاً این PR رو merge می‌کنه؟ نویسنده می‌گه این اولین بنچمارکیه که mergeability رو می‌سنجه و معیارهاش کل کیفیت کد رو از درستی و کیفیت تست گرفته تا رعایت scope و استایل و قراردادهای codebase بررسی می‌کنن. تسک‌ها رو هم بیشتر از ۲۰ توسعه‌دهندهٔ اوپن‌سورس از روی همون مخزن‌هایی که خودشون نگه می‌دارن ساختن و هر کدوم بیشتر از ۴۰ ساعت روش کار کردن.

نتایج جالبن: تو سخت‌ترین زیرمجموعه (Diamond با ۵۰ تسک سخت)، بهترین مدل یعنی Claude Opus 4.8 فقط ۱۳.۴٪ گرفته، GPT-5.5 شده ۶.۳٪ و Gemini 3.1 Pro هم ۴.۷٪. تو زیرمجموعه‌های Main و Extended هم Opus 4.8 با ۳۴.۳٪ و ۵۱.۸٪ جلوتره. نویسنده اشاره می‌کنه که GPT-5.5 با مصرف تا ۴ برابر کمتر توکن، نسبت هزینه به هوش بهتری داره.

یکی از مشکلات بنچمارک‌های قبلی misclassification بوده. نویسنده توضیح می‌ده که false positive یعنی وقتی پوشش تست ناقصه و یه راه‌حل غلط قبول می‌شه، و false negative یعنی وقتی تست‌ها زیادی سخت‌گیرن (مثلاً دنبال یه اسم تابع یا متن خطای دقیق می‌گردن) و یه راه‌حل درست رو رد می‌کنن. به ادعای مقاله، FrontierCode هشتاد و یک درصد کمتر از بنچمارک‌های پیشروی دیگه دچار این خطاها می‌شه.

برای رسیدن به این دقت، چند روش grading تازه ساختن. یکیش reverse-classical هست: تست‌هایی که خود agent نوشته رو روی نسخهٔ خرابِ اولیهٔ کد اجرا می‌کنن و این تست‌ها باید fail بشن تا معلوم بشه agent واقعاً مسئله رو فهمیده. یکی دیگه scope هست که چک می‌کنه PR فقط همون چیزی رو که لازمه دست بزنه و سراغ فایل‌های نامربوط یا refactor اضافی نره. سومی هم adaptive classical grading با ابزاری به اسم mutagent که با کمک یه LLM محیط تست رو با جزئیات پیاده‌سازی agent هماهنگ می‌کنه تا راه‌حل‌های درستِ متفاوت رو اشتباهی رد نکنه.

نویسنده یه مثال جالب هم می‌زنه. تو یه تسک روی مخزن jsonschema که با C++ نوشته شده، مدل باید یه تابع LOG_WARNING() پیاده می‌کرد و همه‌جا به‌جای چاپ مستقیم پیام warning ازش استفاده می‌کرد. تسک ساده به‌نظر می‌رسه ولی مدل‌ها به شکل عجیبی شکست می‌خورن: Claude Opus 4.8 تو پیام‌های چندخطی فرض می‌کنه که LOG_WARNING() و std::cerr همون stream هستن، در حالی که اگه در آینده پیاده‌سازی LOG_WARNING() عوض بشه این فرض می‌تونه دردسر بشه. یعنی کد از نظر رفتاری درسته ولی از نظر کیفیت طراحی ضعفه.

نکات کلیدی:

• FrontierCode به‌جای اینکه فقط درستی کد رو بسنجه، می‌سنجه که آیا یه maintainer واقعی PR رو merge می‌کنه یا نه
• تسک‌ها رو بیش از ۲۰ نگه‌دارندهٔ پروژه‌های بزرگ اوپن‌سورس ساختن، هر تسک بیشتر از ۴۰ ساعت کار
• تو سخت‌ترین بخش (Diamond)، بهترین مدل یعنی Claude Opus 4.8 فقط ۱۳.۴٪ گرفته
• سه روش جدید grading شامل reverse-classical، scope و adaptive classical grading برای کم‌کردن خطای دسته‌بندی به کار رفته
• به ادعای مقاله، این بنچمارک ۸۱٪ کمتر از رقباش دچار خطای misclassification می‌شه