اگر تصور می‌کنید مدل‌های زبانی به‌زودی جایگزین مهندسان ارشد نرم‌افزار می‌شوند، نتایج جدید SlopCodeBench تمام این توهمات را می‌شکند. واقعیت این است که فاصله بین «حل یک مسئلهٔ کدنویسی» و «مهندسی یک سامانه»، شکافی است که حتی قدرتمندترین مدل‌های فعلی هم از آن عبور نکرده‌اند.
در دنیای واقعی، مهندسی نرم‌افزار یک فرآیند تکاملی است؛ برنامه‌نویس امروز کدی می‌نویسد و هفتهٔ آینده باید آن را بر اساس نیازهای جدید تغییر دهد بدون اینکه کل ساختار فرو بپاشد. اما اکثر محک‌ها (Benchmarks) فعلی، یک نقص بنیادی دارند و آن «نشت» (Leakage) صورت‌مسئله است. این بنچمارک‌های سنتی کل چالش را از ابتدا ارائه می‌دهند و به مدل اجازه می‌کنند تا با داشتن نقشه کامل از هدف نهایی، معماری راهکار خود را طراحی کند. این رویکرد اصلاً بازتاب‌دهنده مهندسی نرم‌افزار در دنیای واقعی نیست، جایی که نیازمندی‌ها به‌صورت تدریجی تکامل می‌یابند و توسعه‌دهندگان باید کدبیس را در طول زمان نگهداری کنند، بدون اینکه دقیقاً بدانند تکرار نهایی پروژه چه شکلی خواهد داشت.
به همین دلیل، پژوهشگران دانشگاه UW Madison ابزاری پیشرفته و بلندمدت به نام SlopCodeBench ساختند تا مدل‌ها را در محیطی واقعی‌تر به چالش بکشند. برخلاف پیشین‌های خود، SlopCodeBench از یک سیستم «نقاط بازرسی» (Checkpoints) استفاده می‌کند. در این سیستم، صورت‌مسئله به‌طور کامل در ابتدا به مدل داده نمی‌شود؛ بلکه مدل باید کدبیس را هم‌زمان با آشکار شدن متوالی نیازمندی‌های جدید، تکامل دهد. این ساختار، آزمونی سخت‌گیرانه برای توانایی مدل در حفظ کیفیت کدبیس و اجتناب از انباشت «بدهی فنی» (Technical Debt) در طول یک تعامل طولانی‌مدت ایجاد می‌کند.
طبق گزارش منتشرشده، مدل‌های جدید آنتروپیک (Anthropic) از جمله Opus 4.8، Sonnet 5 و نسخه پیشرو و لبه تکنولوژی Opus 5 مورد آزمایش قرار گرفتند. نتایج تکان‌دهنده است و نگاهی واقع‌بینانه به وضعیت فعلی توسعه نرم‌افزار مبتنی بر هوش مصنوعی می‌اندازد: Opus 5 اگرچه به‌طور فنی در زیرمجموعه‌ای از این تست‌ها به عنوان برنده ظاهر شد، اما تنها به نرخ پذیرش ۲۴ درصد دست یافت. این عدد در مقایسه با نرخ پذیرش سخت‌گیرانه ۱۷ درصدی Opus 4.6 که در مقاله اصلی SlopCodeBench ثبت شده بود، تنها یک بهبود جزئی است. این رکود نشان می‌دهد که صرفاً افزایش مقیاس مدل یا پالایش داده‌های آموزشی، مشکل بنیادین انسجام معماری در بلندمدت را حل نمی‌کند. این چالش‌های ساختاری مشابه مواردی است که در بررسی شکست مدل Ornith-1.0-35b در سناریوهای دشوار مهندسی مشاهده شد، جایی که مدل‌ها در مواجهه با پیچیدگی‌های عملیاتی دچار لغزش می‌شوند.
یکی از بحرانی‌ترین و هشداردهنده‌ترین یافته‌های این آزمایش، همبستگی مستقیم بین پیشرفت پروژه و ظهور «بوی کد» (Code Smell) است. بر اساس مستندات پژوهشی، هر چه مدل‌ها در مراحل مختلف و نقاط بازرسی متوالی SlopCodeBench پیش می‌رفتند، افزایش چشمگیری در حشو (Verbosity) و پیچیدگی‌های غیرضروری مشاهده می‌شد. Opus 5 با وجود نرخ پذیرش بالاتر، میل شدیدی به «تورم کد» یا Bloat داشت؛ به‌طوری که در مجموعه‌ای از چالش‌های یکسان، پنج برابر بیشتر از Opus 4.8 تابع و متد (Callables) تعریف کرد.
این رفتار نشان‌دهنده یک رویکرد «زور خالص» (Brute Force) در حل مسئله است: مدل به‌جای بازنویسی (Refactoring) کدهای موجود برای سازگاری با نیازمندی‌های جدید، صرفاً منطق‌های جدید را به انتهای کد می‌چسباند. نتیجه این است که کدبیس به‌شدت پراکنده و غیرقابل نگهداری می‌شود. این پدیده دقیقاً همان «سلاپ» (Slop) یا کدِ بی‌کیفیتی است که بنچمارک به دلیل آن نام‌گذاری شده است؛ کدهایی که شاید از نظر فنی اجرا شوند و تست‌ها را پاس کنند، اما از نظر معماری ورشکسته هستند.
این روند یک شکاف حیاتی در قابلیت‌های فعلی مدل‌های زبانی بزرگ (LLM) را برجسته می‌کند: تفاوت بین «حل یک پازل» و «مهندسی یک سامانه». حل پازل یک فعالیت «بدون وضعیت» (Stateless) است که در آن هدف، رسیدن به یک خروجی واحد و درست است. اما مهندسی یک سامانه، فعالیتی «وضعیتی» (Stateful) است که در آن هدف، مدیریت پایدار پیچیدگی در طول زمان است. نتایج SlopCodeBench شواهدی تجربی برای چیزی فراهم می‌کند که بسیاری از توسعه‌دهندگان به‌صورت شهودی حس کرده بودند؛ اینکه مدل‌های امروزی را نمی‌توان برای کارهای مهندسی نرم‌افزار با ابعاد واقعی که شامل چندین مسئله تکراری و تکاملی است، به کار گرفت. آن‌ها فاقد دید «سراسری» (Global Perspective) مورد نیاز برای پاک نگه داشتن کدبیس در حین رشد آن هستند.
نکته حیاتی این است که SlopCodeBench هنوز «اشباع نشده» (Unsaturated) است. به این معنا که حتی برترین مدل‌ها، از جمله GPT-5.4، نمرات ضعیفی در این محک می‌گیرند. وقتی بنچمارک‌ها اشباع می‌شوند (یعنی مدل‌ها به نمره نزدیک ۱۰۰ درصد می‌رسند)، دیگر سیگنال مفیدی برای بهبود ارائه نمی‌دهند. اما نرخ پایین پذیرش در SlopCodeBench ثابت می‌کند که هنوز فضای رشد عظیمی در نحوه مدیریت بستر (Context) و برنامه‌ریزی بلندمدت مدل‌ها وجود دارد. چالش اصلی تنها نوشتن تابعی نیست که کار کند، بلکه نوشتن تابعی است که در یک اکوسیستم بزرگتر و در حال تکامل جای بگیرد، بدون اینکه الگوهای موجود را بشکند یا منطق‌های تکراری ایجاد کند.
برای عبور از این بن‌بست، صنعت باید تمرکز خود را از «صحت کوتاه‌مدت» (Short-term Accuracy) به «قابلیت نگهداری بلندمدت» (Long-term Maintainability) تغییر دهد. این امر مستلزم توسعه متدهای آموزشی جدیدی است که مدل‌ها را به‌جای صرفاً پاس کردن تست‌ها، برای ایجاز (Conciseness) و بازنویسی کد (Refactoring) پاداش دهد. در حال حاضر، اگر مدلی بتواند یک تست را با اضافه کردن ۵۰۰ خط کد تکراری پاس کند، توابع پاداش فعلی اغلب آن را یک موفقیت می‌شناسند. اما در یک محیط حرفه‌ای، این یک شکست مطلق است. «انفجار حشو» مشاهده شده در Opus 5، symptom یا نشانه‌ای از این عدم همراستایی بین موفقیت در بنچمارک و تعالی مهندسی است.
با نگاه به نسخه‌های آتی مانند Fable و 5.6 Sol، امید می‌رود شاهد گذار به «مهندسی بستر» (Context Engineering) باشیم؛ یعنی قابلیتی که مدل بتواند به‌طور استراتژیک حافظه کاری خود و ساختار کد را مدیریت کند. تا زمانی که مدل‌ها مقاومت در برابر «سلاپ» و توانایی بازنویسی معنا‌دار را نشان ندهند، صرفاً دستیارهای قدرتمندی خواهند بود، نه مهندسان خودگردان. نتایج SlopCodeBench به عنوان یک «واقع‌بین‌ساز» (Reality Check) لازم عمل می‌کند: مسیر رسیدن به عامل‌های کدنویسی واقعاً خودگردان، نیازی بیش از افزایش پارامترها دارد؛ این مسیر مستلزم تغییری بنیادین در نحوه درک و دست‌کاری چرخه حیات توسعه نرم‌افزار توسط مدل‌هاست. این هدف دقیقا همان چیزی است که در بررسی ۸ عامل کدنویسی پیشرو در سال ۲۰۲۶ دنبال می‌شود تا بتوانند کدی قابل عرضه در محیط عملیاتی تولید کنند. شکاف بین نرخ پذیرش ۲۴ درصد و یک عامل آماده برای تولید (Production-ready)، بسیار وسیع است و این شکاف دقیقاً با همان بدهی فنی پر شده است که SlopCodeBench برای افشای آن طراحی شده است.
گام بعدی شما
- اگر از عامل‌های کدنویسی استفاده می‌کنید، هرگز اجازه ندهید مدل بدون بازبینی انسانی، تغییرات گسترده‌ای در پروژه‌های بزرگ ایجاد کند؛ احتمال تورم کد و ایجاد «سلاپ» بسیار زیاد است.
- برای ارزیابی مدل‌های جدید، به جای تکیه بر معیاری مثل Pass@1، بر روی معیارهای مربوط به پیچیدگی سیکلوماتیک، حجم کد و تعداد توابع تولید شده متمرکز شوید.
- بررسی کنید که آیا مدل شما قادر است کدهای قدیمی را حذف کرده و ساختار را ساده‌تر کند یا فقط تکه‌های جدیدی را به انتهای پروژه اضافه می‌کند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو