تصور کنید یک برنامهنویس هستید که برای سرعت بخشیدن به تحویل پروژه، هر بار از هوش مصنوعی میخواهد بخشهای تکراری کد را بنویسد. باید بدانید این راحتیِ کوتاهمدت، در واقع در حال آموزش مدل برای تولید نرمافزارهای بیکیفیتتر است.
جایگزین کردن منطقهای بهینه با کدهای تکراری — مثل کپی کردن چندینبارهی بررسیهای امنیتی — به مدل این پیام را میدهد که این میانبرها، استایل مورد نظر پروژه هستند. در این وضعیت، مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — دست از بهکارگیری اصول بنیادین برنامهنویسی میکشد و صرفاً عادتهای بد موجود در کد را تقلید میکند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، کیفیت خروجی مدلها بهشدت به بستری که در آن عمل میکنند وابسته است. این تغییر رفتار توسعهدهندگان دقیقاً زمانی رخ میدهد که دستیارهای کدنویسی AI در محیطهای شغلی رایج شدهاند. برای مثال، وقتی یک بررسی امنیتی ساده بهجای تعریف در یک تابع مشترک، در چهار فایل مختلف کپی میشود، کد در کوتاهمدت تستها را پاس میکند، اما «بودوی کد» (Code Smell) ایجاد میکند که LLM آن را از فایلهای باز و تغییرات اخیر مخزن (Repository) جذب میکند.
طبق گزارش unstack.io که در ۱۰ ژوئیه ۲۰۲۶ منتشر شد، مشکل اصلی این است که LLMها مانند اسفنج عمل میکنند. بر اساس مستندات این گزارش، در یک سناریوی واقعی مشاهده شد که:
- چندین نقطه اتصال (Endpoint) به یک بررسی شرطی چهارمرحلهای یکسان نیاز داشتند.
- مدل برای هر درخواست جدید، دقیقاً همان منطق کپی-پیستشده را تولید کرد.
- در نهایت، LLM از بازنویسی (Refactor) کد امتناع کرد، مگر اینکه بهصورت دستی مجبور شود؛ زیرا تکرار را به عنوان معماری استاندارد پروژه شناسایی کرده بود.
این بدان معناست که هر میانبری که در کد ادغام شود، یک سیگنال آموزشی است. اگر برنامهنویسی اصل DRY (تکرار نکنید) را نادیده بگیرد چون فکر میکند AI «بعداً درستش میکند»، در واقع در حال برونسپاریِ تخریب استانداردهای خود است. مدل در خلأ عمل نمیکند، بلکه وضعیت فعلی کد را میخواند تا خط بعدی را بنویسد. این پدیده شباهت زیادی به لغزشهای رفتاری در سیستمهای خودکار دارد که در بررسی مکانیزمهای مهار لغزش عاملهای هوشمند با استفاده از درگاههای اعتبارسنجی به آن پرداختیم.
برای یک توسعهدهنده حرفهای، این موضوع یک هزینه پنهان را برملا میکند: «بدهی فنیِ AI». سرعت تحویل اولیه بالا میرود، اما هزینه نگهداری بلندمدت افزایش مییابد. شما نگهداری کد را به AI نمیسپارید، بلکه با ارائه نمونههای پراکنده و تکراری، به آن میآموزید که نگهدارنده بدتری باشد.
برای جلوگیری از این وضعیت، باید طوری کد بزنید که انگار یک انسان — و نه یک مدل — مسئول اصلی نگهداری آن است. این یعنی سختگیری در تعریف توابع مشترک و انتزاعات تمیز، حتی وقتی LLM مسیر سریعتر و کثیفتری را پیشنهاد میدهد. امروز آستین بالا زدن برای اصلاح دستی یک الگو، مانع از شکست کامل پرامپتها در آینده میشود.
گام بعدی شما
- هرگاه AI کدی تکراری پیشنهاد داد، آن را به یک تابع مشترک تبدیل کنید و سپس نسخه اصلاحشده را به مدل نشان دهید.
- از ابزارهای تحلیل استاتیک کد (Linter) برای شناسایی تکرارها پیش از ادغام در مخزن استفاده کنید.
- در پرامپتهای خود صراحتاً ذکر کنید که «رعایت اصل DRY اولویت دارد و تکرار کد غیرقابل قبول است».
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو