اگر امروز یک بررسی‌کننده کد با هوش مصنوعی را در تیم خود مستقر کنید، احتمالاً تا هفته دوم، برنامه‌نویسان شما خواندن بازخوردهای آن را متوقف می‌کنند، اگر تنها به خروجی‌های خام مدل‌های زبانی بزرگ (LLM) تکیه کنید. طبق گزارشی که در ۸ ژوئن ۲۰۲۶ در وب‌سایت dev.to منتشر شد، یک توسعه‌دهنده در یک شرکت SaaS متوسط چهار ماه زمان صرف ساخت یک بات با استفاده از GPT-4.5 کرد و در نهایت کشف کرد که ارسال ساده‌ی تغییرات کد (Diff) به مدل، منجر به نرخ ۳۴ درصدی «مثبت کاذب» (False-Positive) در پیشنهادات حیاتی می‌شود.
اتوماسیون بررسی کد در ابتدا یک کار ساده به نظر می‌رسد: تغییرات یک Pull Request (PR) را به مدل می‌دهید و بازخوردهای هوشمند دریافت می‌کنید. اما این رویکرد واقعیت کدهای عملیاتی را نادیده می‌گیرد؛ جایی که یک قطعه کد ممکن است در ظاهر «ناامن» به نظر برسد، اما در واقع یک ابزار کمکی (Helper) ضروری برای تست‌ها باشد. بدون دسترسی به کل فایل و استانداردهای کدنویسی پروژه، هوش مصنوعی بافت یا کانتکست لازم برای تشخیص تفاوت بین یک باگ واقعی و یک انتخاب طراحی آگاهانه را ندارد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی محدودیت‌های پنجره متنی مدل‌ها اشاره کردیم، فقدان بافت یا همان کانتکست (Context) — که شبیه به این است که کسی بخواهد قضاوتی درباره یک جمله کند بدون اینکه بداند بقیه کتاب چه می‌گوید — عامل اصلی شکست است.
مشکل بافت و جزئیات مخزن
در اولین نمونه اولیه، بات یک تابع را به دلیل استفاده از eval() «ناامن» تشخیص داد. در واقعیت، آن کد یک ابزار کمکی برای تست بود که عمداً نیاز به ارزیابی پویا (Dynamic Evaluation) داشت. بات چون فقط متن تغییر یافته (Diff) را به صورت متن ساده می‌دید، هیچ راهی برای درک این موضوع نداشت.
برای جلوگیری از این اتفاق، توسعه‌دهنده متوجه شد که یک Diff بدون بافت محیطی عملاً بی‌فایده است. مدل باید پیش از هر قضاوتی، کل فایل را ببیند، وابستگی‌های وارد شده (Import Dependencies) را بررسی کند و استانداردهای خاص کدنویسی آن پروژه را مطالعه نماید.
برای رفع این شکاف کانتکست، توسعه‌دهنده چندین چرخش فنی را اجرا کرد. او اسکریپتی نوشت تا ۵۰۰ مورد از آخرین PRهای ادغام شده در مخزن را تحلیل کند. این اسکریپت با استفاده از Regular Expressions و کلاس Counter از کتابخانه collections در پایتون، الگوهای خاصی را استخراج کرد:
- قراردادهای نام‌گذاری: شناسایی اینکه آیا توابع از
snake_caseاستفاده می‌کنند یاcamelCase. - مدیریت خطا: تشخیص اینکه آیا تیم ترجیح می‌دهد از بلوک‌های
try/exceptاستفاده کند یا از نوعResult. - پوشش تست: تعیین انتظارات و استانداردهای لازم بر اساس تاریخچه PRهای قبلی.
این الگوهای استخراج شده سپس به عنوان «پرامپت‌های سیستمی» (System Prompts) به مدل تزریق شدند. این تغییر، عملکرد بات را به‌طور چشم‌گیر تغییر داد:
- نرخ مثبت کاذب: از ۳۴٪ به ۱۱٪ کاهش یافت.
- زمان بررسی PR: از ۴۵ ثانیه به ۱۲ ثانیه رسید.
- پیشنهادات پذیرفته شده: از ۱۲٪ به ۴۷٪ افزایش یافت.
- رضایت تیم: از ۳ از ۱۰ به ۸ از ۱۰ رسید.
بهینه‌سازی هزینه و زمان اجرا
مدیریت هزینه چالش بعدی بود. در ابتدا بات هر Push را بررسی می‌کرد. در عرض یک هفته، بات ۸۴۷ کامیت را تحلیل کرده بود. هر بررسی بین ۳۰ تا ۶۰ ثانیه زمان می‌برد و هزینه‌های API در ماه اول به ۱۸۰ دلار رسید.
از آنجایی که ۹۰٪ این بررسی‌ها روی کامیت‌هایی انجام می‌شد که طی دو ساعت بازنویسی یا در یک Squash ادغام می‌شدند، تیم در واقع داشت برای بررسی کدهایی که دور ریخته می‌شدند هزینه پرداخت می‌کرد. توسعه‌دهنده دو راهکار برای حل این مشکل اجرا کرد:
۱. محرک وضعیت (Status Trigger): بررسی‌ها دیگر برای هر Push اجرا نمی‌شوند، بلکه تنها زمانی شروع می‌شوند که یک PR به وضعیت «آماده برای بررسی» (Ready for Review) تغییر کند و دیگر در حالت پیش‌نویس (Draft) نباشد.
۲. پنجره تأخیر (Debounce Window): یک وقفه ۱۵ دقیقه‌ای اضافه شد. اگر نویسنده در این بازه زمانی دوباره کد Push کند، بررسی قبلی لغو می‌شود تا از تکرار پردازش‌ها جلوگیری شود.
این تغییرات هزینه ماهانه را به ۴۲ دلار کاهش داد و احتمال اینکه تیم واقعاً بازخوردها را بخواند، افزایش یافت.
توهم امتیاز اطمینان
یک کشف تکان‌دهنده دیگر این بود که امتیازات اطمینان (Confidence Scores) مدل‌های زبانی برای صحت کد عملاً بی‌فایده‌اند. مدل امتیازاتی می‌داد که در آن ۰.۹۵ به معنای «بسیار مطمئن» و ۰.۵۵ به معنای «شاید» بود. توسعه‌دهنده در ابتدا آستانگی (Threshold) تعریف کرد تا فقط پیشنهاداتی با اطمینان بالای ۰.۸۰ نمایش داده شوند.
با این حال، مدل در مورد پاسخ‌های غلط نیز به همان اندازه مطمئن بود. در یک مورد، بات پیشنهادی برای تبدیل یک حلقه به List Comprehension داد و امتیاز اطمینان ۰.۹۲ را برای آن ثبت کرد. اما این بازسازی (Refactor) نادرست بود زیرا حلقه حاوی یک دستور break بود. یک بررسی‌کننده انسانی این تغییر را پذیرفت و نتیجه آن یک Build شکسته بود که ۳۰ دقیقه زمان برای عیب‌یابی (Debug) گرفت.
پس از تحلیل ۲۰۰ پیشنهاد، توسعه‌دهنده دریافت که ضریب همبستگی (Correlation Coefficient) بین امتیاز اطمینان و صحت واقعی تنها ۰.۱۲ است؛ یعنی این امتیازها اساساً تصادفی هستند. راهکار نهایی، حذف کامل امتیازات و دسته‌بندی پیشنهادات بر اساس نوع آن‌ها، مانند «مشکل استایل»، «باگ احتمالی» یا «دغدغه عملکرد» بود.
مواجهه با واقعیت کدهای قدیمی
بات در مواجهه با کدهای قدیمی (Legacy) نیز با مشکل روبرو شد. تست‌های اولیه روی ۵۰ مورد PR بسیار تمیز و ایده‌آل انجام شده بود. اما وقتی بات در محیط واقعی مستقر شد — جایی که شامل Hotfixهایی بود که ساعت ۲ صبح نوشته شده بودند یا بازسازی‌های نیمه‌کاره بودند — بات ۶۰٪ تغییرات یک ماژول قدیمی را به عنوان «ضد الگو» یا «بدترین روش‌ها» (Bad Practices) علامت‌گذاری کرد. بات نمی‌دانست که آن ماژول قرار است در فصل آینده بازنشسته و حذف شود.
برای حل این مشکل، توسعه‌دهنده ۳۰۰ مورد PR واقعی از تاریخچه شرکت را به‌صورت دستی برچسب‌گذاری کرد تا تفاوت بین «پیشنهاد مفید» و «نویز» مشخص شود. سپس یک مدل Mistral 7B — که نوعی مدل با وزن‌های باز (Open Weights) است و شبیه به داشتن دستور پخت غذاست تا فقط غذای آماده — را روی این داده‌ها تنظیم دقیق (Fine-tuning) کرد؛ یعنی مثل وقتی که به یک پزشک عمومی تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود. این مدل تخصصی توانست ۲۳٪ باگ‌های واقعی بیشتری را نسبت به مدل پایه پیدا کند و همزمان نویزهای بی‌مورد را حذف نماید.
برای توسعه‌دهندگان، این یعنی تجربه «آماده مصرف» LLMها برای کدهای سازمانی کافی نیست. موفقیت نیازمند خط لوله‌ای است که استخراج الگوی مخزن، محرک‌های استراتژیک و تنظیم دقیق روی داده‌های تاریخی واقعی (به جای مثال‌های تمیز) را ترکیب کند.
اگر در حال ساخت ابزاری مشابه هستید، ابتدا آخرین ۱۰۰ مورد PR ادغام شده خود را بررسی کنید تا ببینید یک LLM خام چه الگوهای کلیدی را نادیده می‌گیرد. همچنین پیش از افزایش بودجه API، نرخ پذیرش واقعی پیشنهادات بات خود را ردیابی کنید.
گام بعدی شما
- آخرین ۱۰۰ مورد PR ادغام شده در پروژه خود را بررسی کنید تا ببینید مدل‌های خام چه الگوهای کلیدی را نادیده می‌گیرند.
- پیش از افزایش بودجه API، نرخ پذیرش واقعی پیشنهادات بات خود را ردیابی کنید.
- به جای تکیه بر امتیاز اطمینان مدل، سیستم دسته‌بندی بر اساس نوع خطا را پیاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو