۱۳ مدل از ۱۴ مدل برتر هوش مصنوعی کدی کثیف‌تر از انسان‌ها می‌نویسند

اگر تصور می‌کنید سپردن کدنویسی به هوش مصنوعی هزینه‌های نگهداری نرم‌افزار را کاهش می‌دهد، باید در این باور تجدیدنظر کنید. داده‌ها نشان می‌دهند که مدل‌های زبانی، برخلاف ادعاهای بازاریابی، در حال تزریق «بدهی فنی» به مخازن کد هستند.

طبق تحلیل فنی منتشر شده در ۶ سپتامبر ۲۰۲۶، ۱۳ مدل از ۱۴ مدل پیشرو در حوزه کدنویسی، کدی بسیار نامنظم‌تر از انسان‌هایی تولید کردند که همان باگ‌ها را رفع کرده بودند. این مطالعه نشان داد که تقریباً هر مدل آزمایش‌شده، یا پیچیدگی سیکلوماتیک (Cyclomatic Complexity) یک تابع را افزایش داده و یا با تواتر بیشتری نسبت به انسان‌ها، کد مرده (Dead Code) ایجاد کرده است. در این رقابت، تنها یک مدل توانست با سطح استاندارد انسانی برابری کند و هیچ مدلی نتوانست از انسان‌ها پیشی بگیرد.

این یافته‌ها در حالی منتشر می‌شود که صنعت به سمت عامل‌های هوش مصنوعی (AI Agents) حرکت می‌کند که قادر به مدیریت کل مخازن کد هستند. در حالی که بنچمارک‌های فعلی اغلب بر این تمرکز دارند که آیا یک وصله (Patch) تست‌ها را پاس می‌کند یا خیر، آن‌ها به‌ندرت هزینه نگهداری بلندمدت کد حاصل را اندازه‌گیری می‌کنند. این امر باعث ایجاد یک شکاف پنهان میان کدی که «کار می‌کند» و کدی که «قابل نگهداری است» شده است. این چالش با بحث‌های اخیر پیرامون بیش‌برازش در مدل‌های تولید کد همسو است که نشان می‌دهد مدل‌ها گاهی به جای یادگیری منطق، صرفاً الگوهای پاسخ را بازتولید می‌کنند.

متدولوژی اندازه‌گیری

پژوهشگران برای این بررسی از pyscn، یک تحلیل‌گر تخصصی پایتون، استفاده کردند تا تغییرات کیفیت کد را قبل و بعد از اعمال یک وصله (Patch) بسنجند. آن‌ها ۵۰۰ مورد از مسائل بسته شده در پروژه‌های متن‌باز پایتون را از طریق مجموعه داده SWE-bench استخراج کردند. این مجموعه داده، وضعیت مخزن قبل از اصلاح و کامیت دقیقی که مشکل را حل کرده بود، در اختیار آن‌ها قرار داد. وصله‌های تولید شده توسط مدل‌ها نیز از ثبت‌های عمومی در جدول‌های رده‌بندی (Leaderboards) گرفته شده بود. در همین راستا، تحلیل‌های فارنزیک روی داده‌های SWE-bench نشان داده است که بخش بزرگی از این داده‌ها پیش‌تر در فضای عمومی در دسترس بوده‌اند که می‌تواند بر نتایج بنچمارک‌ها اثر بگذارد.

برای تضمین دقت، مطالعه بر دو معیار متمرکز شد: پیچیدگی سیکلوماتیک و کد مرده. این معیارها به این دلیل انتخاب شدند که از گراف جریان کنترل (Control-flow graph) یک تابع استخراج می‌شوند؛ به این معنا که حتی زمانی که تنها بخشی از یک مخزن تحلیل می‌شود، این معیارها دقیق باقی می‌مانند. معیارهای دیگر موجود در pyscn — مانند جفت‌شدگی کلاس‌ها (Class coupling)، انسجام (Cohesion)، کدهای تکراری و وابستگی‌های ماژول — از تحلیل حذف شدند. دلیل این تصمیم آن بود که این معیارها مشارکت‌های مربوط به فایل‌های مفقود را کمتر از حد واقعی می‌شمارند و در نتیجه، امتیاز نهایی به این بستگی می‌یافت که وصله اتفاقاً کدام فایل‌ها را لمس کرده است.

فرآیند تحلیل داده‌ها

پژوهشگران برای هر باگ و وصله، ابتدا فایل‌های تغییر یافته را اندازه‌گیری کردند، سپس وصله را اعمال کرده و دوباره اندازه‌گیری را تکرار نمودند تا تفاضل (Delta) به دست آید. این فرآیند برای هر جفت (مسئله، وصله) با توالی سخت‌گیرانه‌ای از دستورات اجرا شد:

• git checkout base_commit
• تحلیل فایل‌هایی که وصله آن‌ها را تغییر می‌دهد (وضعیت قبل)
• git apply the patch
• تحلیل همان فایل‌ها (وضعیت بعد)
• تفاضل = وضعیت بعد - وضعیت قبل

دو قانون سخت‌گیرانه برای جلوگیری از دست‌کاری داده‌ها اعمال شد: نخست، تنها فایل‌هایی که در هر دو طرف وصله حضور داشتند اندازه‌گیری شدند تا فایل‌های موقتی (Scratch files) عامل‌ها باعث تورم داده‌ها نشوند. دوم، تنها وصله‌هایی که تست‌های خود را پاس کرده بودند شمارش شدند. محققان اشاره کردند که گنجاندن کدهای خراب، در واقع استدلال علیه مدل‌ها را قوی‌تر می‌کرد، زیرا اندازه نمونه دو برابر می‌شد و مدل‌های بیشتری از تصحیح بونفرونی (Bonferroni correction) عبور می‌کردند. با این حال، کدهای خراب اغلب «تمیزتر» از کدهای سالم اندازه‌گیری می‌شوند و همین موضوع باعث می‌شود اعداد بدون فیلتر، غیرقابل اعتماد باشند.

شکاف عملکردی: انسان در برابر ماشین

یک وصله زمانی به عنوان «پس‌رفت» (Regression) علامت‌گذاری می‌شد که پیچیدگی تابع را بالا می‌برد، تابعی که pyscn آن را پرریسک می‌داند اضافه می‌کرد یا کد مرده ایجاد می‌نمود. حتی یک شاخه (Branch) اضافی در یک تابع برای فعال شدن این پرچم کافی بود. وصله‌های انسانی در ۲۴٪ موارد منجر به پس‌رفت شدند، اما مدل‌های هوش مصنوعی نرخ بسیار بالاتری داشتند:

• devstral-small: بیشترین شکاف با ۱۶.۶ درصد تفاوت منفی نسبت به انسان (مدل بدتر: ۲۱۱ مورد، انسان بدتر: ۷۹ مورد).
• gpt-5: ۱۲.۹ درصد بدتر از انسان (مدل بدتر: ۳۰۳ مورد، انسان بدتر: ۱۱۵ مورد).
• glm-4.6: ۱۱.۸ درصد بدتر از انسان (مدل بدتر: ۳۳۱ مورد، انسان بدتر: ۱۱۸ مورد).
• deepseek-v3: ۱۱.۰ درصد بدتر از انسان (مدل بدتر: ۲۰۹ مورد، انسان بدتر: ۶۹ مورد).
• Nemotron-CORTEXA: ۱۰.۰ درصد بدتر از انسان (مدل بدتر: ۳۳۹ مورد، انسان بدتر: ۱۱۳ مورد).
• kimi-k2: ۱۰.۰ درصد بدتر از انسان (مدل بدتر: ۳۰۱ مورد، انسان بدتر: ۱۰۶ مورد).
• o4-mini: ۷.۷ درصد بدتر از انسان (مدل بدتر: ۲۲۰ مورد، انسان بدتر: ۶۸ مورد).
• o3: ۷.۳ درصد بدتر از انسان (مدل بدتر: ۲۸۸ مورد، انسان بدتر: ۸۷ مورد).
• claude-4-opus: ۶.۵ درصد بدتر از انسان (مدل بدتر: ۳۲۵ مورد، انسان بدتر: ۹۸ مورد).
• qwen3-coder-480b: ۶.۴ درصد بدتر از انسان (مدل بدتر: ۲۶۴ مورد، انسان بدتر: ۷۹ مورد).
• claude-sonnet-4: ۵.۸ درصد بدتر از انسان (مدل بدتر: ۳۱۱ مورد، انسان بدتر: ۹۳ مورد).
• claude-opus-4.5: ۵.۱ درصد بدتر از انسان (مدل بدتر: ۳۳۴ مورد، انسان بدتر: ۱۰۶ مورد).
• gemini-2.5-pro: ۳.۱ درصد بدتر از انسان (مدل بدتر: ۲۶۰ مورد، انسان بدتر: ۶۷ مورد).
• qwen2.5-coder-32b: برابر با خط پایه انسانی (۰.۰ درصد تفاوت؛ مدل بدتر: ۴۲ مورد، انسان بدتر: ۴ مورد).

از ۷۴۱ موردی که در آن مدل و انسان بر سر ایجاد پس‌رفت اختلاف داشتند، در ۵۳۰ مورد هوش مصنوعی مقصر بود. از نظر آماری، ۱۲ مدل از ۱۴ مدل به طور مجزا سطح p < 0.05 را رد کردند و ۶ مدل از تصحیح بونفرونی جان سالم به در بردند. همچنین بررسی مجزا روی پروژه django نشان داد که نتایج با نسبت ۳ به ۲ تقسیم شده‌اند، که نشان می‌دهد این یافته‌ها در مخازن مختلف ثابت است.

بحران «فایل‌های پیش‌نویس»

علاوه بر پیچیدگی کد، این مطالعه به یک مشکل سیستماتیک اشاره کرد: رها کردن فایل‌های موقت (Scratch files) توسط عامل‌های هوش مصنوعی در مخازن. این‌ها اسکریپت‌های یک‌بارمصرفی مانند reproduce_bug.py ، check_url_parts.py یا final_verification.py هستند که برای بازتولید باگ یا تأیید اصلاحات استفاده می‌شوند. چون وصله نهایی به صورت یک git diff ارسال می‌شود، هر فایلی که در درخت کاری باقی مانده باشد، همراه با اصلاحیه به مخزن منتقل می‌شود. این ناتوانی در مدیریت چرخه حیات فایل‌ها، یادآور ضعف مدل‌های زبانی در تولید اسکریپت‌های بازگشتی است که در آن مدل‌ها در رعایت قراردادهای عملیاتی کدنویسی شکست می‌خورند.

در حالی که میانگین فایل‌های اضافی انسان‌ها ۰.۰۰ بود، مدل‌های هوش مصنوعی مقادیر قابل توجهی را رها کردند. برای بررسی اینکه آیا این نقص مربوط به مدل است یا فریم‌ورک، هفت مدل با یک ساختار، پرامپت و سیاست تلاش مجدد (Retry policy) یکسان تست شدند:

• claude-sonnet-4: ۳.۵۳ فایل اضافی به ازای هر باگ
• claude-4-opus: ۳.۵۰ فایل اضافی
• qwen3-coder-480b: ۳.۲۸ فایل اضافی
• qwen2.5-coder-32b: ۰.۶۷ فایل اضافی
• gemini-2.5-pro: ۰.۶۵ فایل اضافی
• o3: ۰.۲۳ فایل اضافی
• o4-mini: ۰.۱۹ فایل اضافی

این تفاوت ۱۸ برابری نشان می‌دهد که رها کردن فایل‌های زباله مستقیماً به مدل وابسته است. نتایج مشابهی در فریم‌ورک‌های دیگر نیز مشاهده شد: kimi-k2 تعداد ۳.۸۴ فایل، gpt-5 تعداد ۰.۰۷ فایل و claude-opus-4.5 تعداد ۰.۰۰ فایل رها کردند. از آنجا که SWE-bench فقط پاس شدن تست‌ها را می‌سنجد، این فایل‌های مزاحم تأثیری بر رتبه مدل‌ها در جدول‌ها ندارند، اما مخزن کد را آلوده می‌کنند.

محدودیت‌های داده‌ای

پژوهشگران اشاره کردند که این مطالعه محدود به زبان پایتون است، زیرا تمام موارد SWE-bench Verified و ابزار pyscn فقط برای این زبان طراحی شده‌اند. هنوز مشخص نیست که آیا این نتایج در زبان‌هایی با ساختارهای کنترلی متفاوت نیز تکرار می‌شود یا خیر، به همین دلیل SWE-bench Multilingual هدف منطقی بعدی برای بررسی است.

همچنین، داده‌های تحلیل شده مربوط به ثبت‌های بین مه تا نوامبر ۲۰۲۵ است. برای مثال، claude-opus-4.5 مربوط به نوامبر ۲۰۲۵ و gpt-5 و deepseek-v3 مربوط به اوت ۲۰۲۵ هستند. هیچ مدلی که در سال ۲۰۲۶ منتشر شده باشد در این لیست نیست.

نکته حیاتی این است که خط پایه انسانی، کد نهایی ادغام شده است که از بررسی همتایان (Peer Review)، بازبینی و تست‌های CI گذشته است. در مقابل، وصله‌های هوش مصنوعی، ثبت‌های تک‌مرحله‌ای بودند. این بدان معناست که مطالعه، آنچه را که در نهایت در مخزن قرار می‌گیرد می‌سنجد، نه پیش‌نویس اول یک انسان را.

پیامدهای فنی

این نتایج ثابت می‌کند که «توانایی» (حل باگ) با «نظم» (پاکیزگی کد) همبستگی ندارد. جالب است که دو مدل با بیشترین شکاف کیفی، در دو سر جدول توانمندی بودند: devstral-small (پایین‌ترین) و gpt-5 (بالاترین). در میان هفت مدل گروه کنترل، هیچ روند مشخصی وجود نداشت: o3 و o4-mini در جایگاه بالاتری نسبت به claude-sonnet-4 و qwen3-coder-480b قرار داشتند.

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

برای تأیید این یافته‌ها، بنچمارک در مخزن گیت‌هاب polyscan در مسیر polyscan/benchmarks/patch-quality در دسترس است. این ابزار نیازی به فراخوانی API ندارد و می‌تواند تنها با کتابخانه استاندارد پایتون از طریق دستور python3 report.py results/*.jsonl.gz --resolved-only اجرا شود. محققان همچنین به یک مشکل شناخته شده (pyscn#696) اشاره کردند که در آن مقدار پیش‌فرض --min-complexity برابر با ۵ می‌تواند برخی توابع را فیلتر کند و احتمالاً ساده‌سازی‌ها را به اشتباه به عنوان حذف (Deletion) نمایش دهد.

گام بعدی شما

• اگر از عامل‌های کدنویسی استفاده می‌کنید، حتماً یک مرحله بررسی دستی برای حذف فایل‌های موقت و تحلیل پیچیدگی توابع اضافه کنید.
• ابزارهای تحلیل استاتیک (Static Analysis) را به خط لوله CI/CD خود اضافه کنید تا از ورود کدهای با پیچیدگی بالا توسط AI جلوگیری شود.
• برای بررسی جزئیات بیشتر، می‌توانید بنچمارک این مطالعه را در مخزن گیت‌هاب polyscan اجرا کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.