وقتی مدرن‌سازی با LLM کد کارکرده را خراب می‌کند: بررسی عملکرد هوش مصنوعی روی PHP قدیمی — When Modernization Breaks Working Code: A Study of LLMs on Legacy PHP
خلاصه
این مقاله پژوهشی بررسی می‌کند که ارسال کدهای قدیمی WordPress ۴.۰ به مدل‌های زبانی بزرگ برای ارتقا به PHP ۸.۳ چه پیامدهایی دارد. نتایج نشان می‌دهد که LLMها اغلب کدهای سالم را با خطا مواجه می‌کنند و ابزارهای قانون‌محور سنتی در حفظ پایداری عملکرد بهتری دارند.
مقدمه
بسیاری از توسعه‌دهندگان وقتی با کدهای لگسی (Legacy) و قدیمی مواجه می‌شوند، وسوسه می‌شوند که فایل کد را کپی کرده و در یک مدل زبانی بزرگ (LLM) قرار دهند و از آن بخواهند کد را «مدرن» کند. اما آیا این کد مدرن‌شده واقعاً از کد قدیمی بهتر و پایدارتر است؟ پژوهشی جدید روی این سناریو تمرکز کرده و نتایج تأمل‌برانگیزی را درباره عملکرد LLMها در ارتقای کدهای PHP قدیمی منتشر کرده است.
جزئیات و روش پژوهش
در این مطالعه، پنج مدل مختلف LLM وظیفه داشتند ۱۰۰ فایل PHP مربوط به WordPress 4.0 را به نسخه PHP 8.3 ارتقا دهند. شرایط این آزمایش به این صورت طراحی شده بود:
- بدون زمینه پروژه (Context): مدل‌ها فقط یک فایل مستقل را بدون آگاهی از وابستگی‌ها، فایل‌های دیگر یا کدهای فراخواننده مشاهده می‌کردند.
- بدون بازخورد اجرایی: ارزیابی روی اولین پاسخ مدل انجام شد و به آن‌ها اجازه داده نشد که خطاهای کامپایل را ببینند و اصلاح کنند.
- معیارهای ارزیابی: خروجی‌ها با ۶۳۰ چک رفتارسنجی و ۵۱۱ مورد مدرن‌سازی شناسایی‌شده توسط ابزار Rector سنجیده شدند.
پژوهشگران خروجی مدل‌ها را با دو مبنا مقایسه کردند: کدهای دست‌نخورده‌ی اصلی و ابزار قانون‌محور Rector (که برای ریفکتورینگ خودکار کدهای PHP طراحی شده است).
یافته‌های کلیدی فنی
نتایج این تحقیق نشان داد که ایده «مدرن‌سازی با یک کلیک» توسط هوش مصنوعی می‌تواند خطرناک باشد:
- از ۱۰۰ فایل دست‌نخورده‌ی اصلی، ۸۳ فایل از همان ابتدا تمامی چک‌های رفتاری را با موفقیت پاس می‌کردند؛ اما قوی‌ترین LLM تنها توانست ۵۹ فایل سالم را تحویل دهد.
- هر کدام از مدل‌ها بین ۳۲ تا ۵۱ فایل سالم و کارکرده را خراب کردند، در حالی که در بهترین حالت تنها ۱۰ فایل را بهبود دادند.
- در مقابل، ابزار قانون‌محور Rector تنها ۷ فایل را خراب و ۶ فایل را تعمیر کرد.
- جالب اینجاست که اکثر تغییرات ایجاد شده توسط LLMها اصلاً نیازی به تغییر نداشتند. از ۵۱۱ مورد شناسایی‌شده، تنها ۳۷ مورد (۷ درصد) برای سازگاری با PHP 8.3 الزامی بود؛ با این حال، مدل‌های زبانی در فایل‌های کاملاً سازگار بین ۳۶ تا ۶۰ درصد خطا ایجاد کردند (در حالی که این رقم برای Rector تنها ۸ درصد بود).
- اکثر این رگرسیون‌ها مربوط به فایل‌هایی بود که دیگر اصلاً لود نمی‌شدند، به‌ویژه به دلیل اعلان‌های نوع (Type Declarations) نادرستی که خود مفسر PHP آن‌ها را رد می‌کرد.
دیدگاه جامعه توسعه‌دهندگان (Hacker News)
بحث‌های شکل‌گرفته پیرامون این مقاله در Hacker News نکات جالبی را روشن کرد:
- بسیاری از کاربران اشاره کردند که این پژوهش یک حالت «میانجی» و ساده‌شده (ارسال یک فایل منفرد به چت‌بات بدون چرخه بازخوردی) را بررسی کرده است. در دنیای واقعی، ابزارهای مبتنی بر ایجنت (Agentic Coding) که اجازه تکرار، اجرای تست و اصلاح خطا را دارند، عملکرد بسیار بهتری ارائه می‌دهند.
- برخی تکنولوژیست‌ها به سرعتِ پیشرفت مدل‌ها اشاره کردند و معتقدند نتایج مدل‌های بررسی‌شده ممکن است به سرعت کهنه شود، کما اینکه مهندسان امروز با ابزارهای پیشرفته‌تر نتایج بسیار بهتری می‌گیرند.
- عده‌ای نیز بر این باورند که با ارزان شدن تولید کد، حجم کدهای تولیدی افزایش یافته و مفهوم «لگسی» شدن بسیار سریع‌تر از گذشته اتفاق می‌افتد.
چرا این موضوع برای مهندسان اهمیت دارد؟
این مقاله به ما یادآوری می‌کند که ارزیابی ابزارهای مبتنی بر هوش مصنوعی نباید صرفاً بر اساس «میزان تغییرات کدهای مدرن» انجام شود. معیارهای رفتارسنجی و مقایسه با یک مبنای «بدون تغییر» (No-change Baseline) برای سنجش پایداری سیستم‌های نرم‌افزاری حیاتی هستند. اگر از LLMها برای ارتقای کدهای حیاتی استفاده می‌کنید، اتکا به یک پاسخ تک‌مرحسه‌ای بدون تست‌های خودکار و بدون در نظر گرفتنContext کامل پروژه می‌تواند کدهای سالم شما را از کار بیندازد.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل