Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files

مقاله‌ی Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files (15 Oct 2026، دانشگاه ایلینوی اربانا-شمپین؛ Xiaocong Yang، Rishit Chatterjee و همکاران)

مسئله: یک ریپوی واقعی خیلی بزرگ‌تر از پنجره‌ی کانتکست ایجنت است، پس باید تصمیم گرفت کدام بخش کد جلوی مدل گذاشته شود. دو راه رایج وجود دارد: «بازیابی»، یعنی آوردن تکه‌هایی از کد که به متن ایشو شبیه‌اند، و «فشرده‌سازی»، یعنی حذف کلمه‌ها و خط‌هایی که یک مدل کوچک کم‌اهمیت می‌داند. اما برای نوشتن پچ دو چیز هم‌زمان لازم است: فایل‌هایی که باید عوض شوند، و متن دقیق همان فایل‌ها، چون مدل باید خطی را که ویرایش می‌کند عیناً نقل کند.

روش:

• نویسنده‌ها یک انتخاب‌گر ساده به اسم CQ2-CARE ساختند. این روش دو بار جداگانه از خود مدل می‌پرسد «کدام فایل‌ها باید تغییر کنند؟» و فقط فایل‌هایی را نگه می‌دارد که در هر دو جواب آمده‌اند.
• همین چند فایل کامل و بدون هیچ دست‌کاری به مدل نشان داده می‌شوند. اگر مدل تعریف یا محل فراخوانی تابعی را بخواهد، چند خط کوتاه هم با grep از جاهای دیگر ریپو اضافه می‌شود.
• برای این‌که مقایسه منصفانه باشد، همه‌ی روش‌ها برای هر ایشو دقیقاً همان سهم توکن را گرفتند. آزمون روی ۳۰۰ ایشوی تازه از بنچمارک SWE-rebench بود، با دو مدل GPT-5.6 و Claude Opus 5، و هر پچ با تست‌های خود بنچمارک نمره گرفت.

یافته‌ها:

• با هر دو مدل، نشان دادن چند فایل کامل از هر ۱۰۰ ایشو حدود ۶ ایشوی بیشتر از بهترین روش فشرده‌سازی حل کرد، و حدود ۹ تا ۱۳ ایشوی بیشتر از بهترین روش بازیابی.
• این روش ساده حتی از دو روشی که مخصوص همین کار آموزش دیده‌اند (SweRank و SWE-Pruner) هم کمی جلوتر بود، هرچند این فاصله‌ها کوچک است.
• علت شکست دو روش دیگر را با یک مثال نشان می‌دهند. در ایشویی درباره‌ی پیام‌های خطایی که حرف f اولِ f-string را جا انداخته بودند، روش بازیابی جا را با قالب‌های ایشوی خود ریپو پر کرد، چون کلماتشان شبیه گزارش بود، و فایلی که باید درست می‌شد اصلاً به مدل نرسید. فشرده‌ساز فایل درست را نگه داشت، اما همان حرف‌های f را حذف کرد، و مدل پچی نوشت برای خطی که در فایل اصلاً وجود نداشت.
• فشرده‌سازهای سنگین برای هر ایشو حدود نیم دقیقه وقت پردازنده‌ی گرافیکی می‌گرفتند، در حالی که انتخاب فایل فقط یک پرسش اضافه از خود مدل است.

محدودیت: هر آزمایش فقط یک بار پچ‌نویسی بود، روی ایشوهای پایتونی و از یک بنچمارک، نه یک ایجنت چندمرحله‌ای که بتواند خودش فایل‌های بیشتری باز کند یا تست اجرا کند. یک فشرده‌ساز مخصوص کد (LongCodeZip) هم وقتی از همان فایل‌های انتخاب‌شده شروع کرد، به همان نتیجه رسید؛ پس برتری اصلی در انتخاب درست فایل‌هاست، نه در نفس فشرده نکردن.