‏مدل‌ها باگ کد خودشون رو کمتر می‌بینن

Rodrigo، از تیم تحقیق Greptile (ایجنت بازبینی کد)، از یه مشاهدهٔ ساده شروع می‌کنه: بیشتر کدی که Greptile ری‌ویو می‌کنه رو مدل‌های OpenAI و Anthropic نوشتن و خودِ ایجنت ری‌ویو هم معمولاً یکی از همون مدل‌های frontier ـه. سؤالش اینه که آیا مدل‌ها تو پیدا کردن باگِ کد خودشون خوبن؟

روش کارش اینه: دو دیتاست ۵۰۰ تایی از PRها، یکی نوشتهٔ Claude Code و یکی نوشتهٔ Codex، که از روی رد کامیت‌ها (مثل Co-authored-by)، پیشوند عنوان PR و پیشوند برنچ شناسایی شدن. بعد با تحلیل احساسات، نسبت رأی مثبت به منفی و کند‌وکاو تو تاریخچهٔ گیت، حدود ۱۵۰۰ کامنت به‌عنوان باگ تأییدشده به‌عنوان مبنا (ground truth) درآورده و قابلیت /review هر دو مدل رو سه بار روی هر PR اجرا کرده. کامنت‌های سلیقه‌ای و تعریف و پیشنهاد مستندات کنار گذاشته شدن.

نتیجهٔ اول: هر مدل تو کد مدل دیگه بهتر عمل می‌کنه. روی PRهای نوشتهٔ Claude، بازیابی باگ‌های پرشدت برای GPT حدود ۶۲ درصد و برای Opus حدود ۶۰ درصد بوده؛ روی PRهای نوشتهٔ Codex ورق برمی‌گرده و Opus با حدود ۵۳.۷ درصد جلوی ۵۰.۵ درصد GPT قرار می‌گیره.

نویسنده برای فهمیدن دلیلش باگ‌ها رو دسته‌بندی کرده و به الگوی جالبی رسیده: هر مدل دقیقاً همون نوع باگ‌هایی رو بیشتر تولید می‌کنه که موقع ری‌ویو بیشتر از دستش در می‌ره. تو PRهای Claude سهم «رفتار جاافتاده یا دادهٔ اشتباه» بالاتره (۳۵.۱ در برابر ۲۴.۲ درصد) — همون دسته‌ای که GPT توش ری‌ویوِر بهتریه؛ و PRهای Codex بیشتر به سمت مسائل معنایی و مدیریت خطا می‌رن که نقطهٔ قوت Claude ـه. به تعبیر نویسنده، هر مدل چک‌لیست ذهنی و غریزهٔ طراحی خودش رو داره و باگ‌هاش بازتاب همون چیزهاییه که ذاتاً نگرانش نیست.

تفاوت سبک هم چشمگیره: به گفتهٔ نویسنده Claude پهن‌کار می‌ره و GPT عمیق‌کار. میانگین کامنت هر ری‌ویوی Codex یکی دوتاست و Opus حدود هفت هشت‌تا. با شکستن traceها به سه فاز Scope و Investigate و Summarize معلوم شده Opus حدود ۵۹ درصد کانتکستش رو تو فاز خوندن دیف می‌سازه، ولی GPT فقط ۶ درصد اونجاست و ۸۲ درصد رو تو فاز جست‌وجو و جمع‌آوری شواهد.

این تمرکز روی راستی‌آزمایی هزینه داره: GPT اول بازیابی خیلی پایینی داشت و وقتی نویسنده صراحتاً گفت حدود ۷ تا ۱۰ کامنت بذار، عملکردش برگشت. تو traceها دیده می‌شه مدل باگ رو تو استدلالش پیدا می‌کنه و بعد پستش نمی‌کنه — مثلاً یه deadlock که ۲۰ درصد توکن‌های استدلال رو گرفته، در نهایت تو ری‌ویو نیومده. ریشه‌ای که نویسنده حدس می‌زنه، دستورهای متضاد سیستم و رفتار تقویت‌شده در post-training ـه؛ به قول خودش، دور زدن این رفتار بیشتر شبیه jailbreak بود تا پرامپت‌نویسی.

Opus مشکل معکوس داره: به گفتهٔ نویسنده سعی می‌کنه مثل آدم ری‌ویو کنه — دربارهٔ نیت توسعه‌دهنده تردید می‌کنه، ریسک‌های آینده رو پیش‌بینی می‌کنه، پیشنهاد سبکی می‌ده و حتی کد خوب رو تحسین می‌کنه. نویسنده می‌گه مفید بودن یا آزاردهنده بودن این سبک سلیقه‌ایه، ولی نگاه کل‌نگر بدون راستی‌آزمایی کافی، مثبت کاذب می‌سازه و هر مثبت کاذب یا وقت یه مهندس رو می‌گیره یا تو جریان ایجنتیک، محاسبات رو.

خروجی عملی این تحقیق قابلیتیه به اسم Model Inversion: Greptile از روی رد کامیت و پیشوند برنچ و عنوان PR تشخیص می‌ده کدوم ایجنت کد رو نوشته و ری‌ویو رو به مدل دیگه می‌سپره. تیم تأکید می‌کنه این قابلیت آزمایشیه. جمع‌بندی نویسنده هم اینه که فعلاً خبری از هم‌گرایی مدل‌ها نیست؛ وضعیت بیشتر شبیه یونان باستانه، با خدایانی که هر کدوم قلمرو خودشون رو دارن.

نکات کلیدی:

• هر مدل تو کد مدل رقیب باگ‌های پرشدت بیشتری پیدا می‌کنه تا تو کد خودش
• نوع باگ‌هایی که یه مدل تولید می‌کنه، همون‌هاییه که موقع ری‌ویو هم بیشتر می‌بازه
• Opus پهن و پیشگیرانه ری‌ویو می‌کنه (۷ تا ۸ کامنت)، GPT عمیق و محتاط (۱ تا ۲ کامنت)
• GPT گاهی باگ رو تو استدلالش پیدا می‌کنه ولی گزارش نمی‌ده؛ راهنمایی صریح دربارهٔ تعداد کامنت جبرانش می‌کنه
• قابلیت آزمایشی Model Inversion ری‌ویو هر PR رو به مدلی می‌ده که نویسنده‌اش نبوده