تست‌های کدنویسی هوش مصنوعی باید پیش از پاسخ مدل شکست بخورند

اگر امروز به مدل‌های زبانی برای نگهداری کدها تکیه می‌کنید، احتمالاً در معرض توهمی از امنیت هستید. یک نتیجه‌ی سبز (Pass) در تست‌های کدنویسی زمانی بی‌معنی است که نتوانید ابتدا ثابت کنید همان تست روی باگی که قصد اصلاحش را دارید، شکست می‌خورد. این تز مرکزی یک پیشنهاد فنی است که در ۱۳ اکتبر ۲۰۲۶ منتشر شد. طبق این گزارش، اکثر ارزیابی‌های فعلی هوش مصنوعی بیشتر شبیه «جلسات چت» هستند تا اندازه‌گیری‌های دقیق مهندسی. در دنیای واقعی، یک وصله‌ی کد (Patch) خوش‌ساخت یا سروری که اتفاقی بوت می‌شود، به معنای موفقیت نیست.

برای توسعه‌دهندگانی که از مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — استفاده می‌کنند، خطر اصلی یک وصله‌ی شکست‌خورده نیست، بلکه یک وصله‌ی «روان» (Fluent) است. مدل ممکن است تغییری تمیز ارائه دهد که برای یک بازبین خسته درست به نظر برسد، در حالی که منطق زیربنایی همچنان خراب است. این وضعیت باعث می‌شود برنامه‌نویس مدل را برای اصلاحی تحسین کند که هرگز رخ نداده است. این پدیده در واقع همان تولید تیک‌های سبز کاذب است که عامل‌های هوش مصنوعی محلی را در کدنویسی به شکست می‌کشاند. سرزنش کردن دیگران شاید حس خوبی بدهد، اما باعث شکست خوردن یک بیلد (Build) نمی‌شود. هدف این است که ابتدا مطمئن شویم بررسی (Check) عمداً شکست می‌خورد تا هر زمان که توسعه‌دهنده مشکوک شد، بتواند آن را دوباره اجرا کند.

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

کالبدشکافی یک «کاشت»

این چارچوب بر «کاشت‌ها» (Plants) تکیه دارد؛ یعنی باگ‌های عمدی و خسته‌کننده. نویسنده با باگ‌های «هوشمندانه» مخالف است، چون آن‌ها بیشتر برای تملق سازنده هستند تا بازرسی دقیق سیستم. باگ‌های ساده تنها راه واقعی برای تست کردن دروازه‌ی ورود کد هستند. کاشت باید کوچک بماند تا شکست مربوط به سیستم تست باشد، نه مهارت در پنهان کردن نقص در یک هزارتوی پیچیده.

در مثالی ارائه شده، تابعی به نام take با یک باگ کاشته شده است: return xs[: n + 1]. تست متناظر با آن، test_take_does_not_overshoot نیز به همان اندازه ساده طراحی شده تا روی یک مرز مشخص سخت‌گیرانه عمل کند و هیچ مذاکره‌ای را نپذیرد. این ساختار تضمین می‌کند که شکست مربوط به دروازه‌ی تست است، نه پیچیدگی نقص. پیاده‌سازی این بخش از یک کلاس داده‌ای (dataclass) منجمد برای شیء Plant استفاده می‌کند که نام، رشته‌ی دارای باگ و رشته‌ی اصلاح‌شده را ذخیره می‌کند.

جزئیات پیاده‌سازی کاشت

• تعریف کاشت: کلاس داده‌ای Plant در فایل harness/plants.py تعریف شده و از frozen=True استفاده می‌کند تا تعاریف باگ در طول اجرا تغییر نکنند و غیرقابل تغییر (Immutable) بمانند.
• نسخه‌ی دارای باگ: در کاشت TAKE کد به صورت def take(xs, n): return xs[: n + 1] تعریف شده که یک خطای کلاسیک «یکی بیشتر» (off-by-one) است.
• نسخه‌ی اصلاح‌شده: پیاده‌سازی درست به صورت def take(xs, n): return xs[:n] ذخیره شده است.
• مورد تست: در فایل tests/test_take.py تستی وجود دارد که تایید می‌کند take(['a', 'b', 'c'], 2) == ['a', 'b']. این یک بررسی باینری است: یا پاس می‌شود یا نمی‌شود.

خودکارسازی حلقه‌ی شکست

برای جلوگیری از اینکه انسان‌ها تصادفاً باگ را پیش از دیدن مدل اصلاح کنند، یک اسکریپت نویسنده معرفی شده است. دست‌های انسان‌ها همان عاملی هستند که باعث می‌شوند کاشت‌ها پیش از آنکه مدل آن‌ها را ببیند، بی‌صدا اصلاح شوند. اسکریپت write_plant.py به صورت برنامه‌ریزی‌شده فایل منبع را با نسخه‌ی «دارای باگ» یا «اصلاح‌شده» از یک جدول پیش‌فرض بازنویسی می‌کند و از argparse برای انتخاب نسخه استفاده می‌کند.

جریان کاری از یک توالی مکانیکی سخت‌گیرانه پیروی می‌کند:
۱. نوشتن نسخه‌ی دارای باگ روی دیسک با دستور: python harness/write_plant.py --name take-off-by-one --variant buggy.
۲. اجرای pytest برای تایید کد خروجی غیرصفر (وضعیت قرمز) از طریق: python -m pytest -q tests/test_take.py.
۳. ثبت کد خروجی (echo oracle_exit=$?). اگر خروجی ۰ باشد، یعنی کاشت نامرئی است و فرآیند باید متوقف شود.
۴. تنها پس از تایید شکست، کد به مدل هوش مصنوعی ارسال می‌شود.

طبقه‌بندی سخت‌گیرانه‌ی پاسخ‌های مدل

این پیشنهاد عادت «تکرار» (Iteration) با مدل تا زمان اعمال وصله را رد می‌کند. پرامپت باید «گرسنه تر» از فایل تست باشد؛ نویسنده لیست مورد انتظار را در پرامپت قرار نمی‌دهد و نمی‌پرسد که آیا تابع «خوب» است یا خیر، زیرا صفت «خوب» همان راهی است که یک پاسخ «بله» را به عنوان مهندس استخدام می‌کند. دستورالعمل ساده است: یک تابع ضمیمه می‌شود، یک تست مشخص شکست می‌خورد و مدل باید یا پاسخی با شروع REJECT و یک جمله بدهد، یا یک diff یکپارچه (unified diff) که فقط تابع take را تغییر دهد.

به جای بررسی کیفی، از یک طبقه‌بندی‌کننده سخت‌گیرانه (classify.py) برای دسته‌بندی پاسخ‌ها به سه دسته استفاده می‌شود:

• 'reject': پاسخ با REJECT: شروع می‌شود. اگر اوراکل از قبل تابع را رد کرده بود، این یک موفقیت (Hit) محسوب می‌شود.
• 'diff': پاسخ با --- یا diff شروع می‌شود و کاندیدای تعمیر است.
• 'malformed': هر پاسخ دیگر که به عنوان شکست (Miss) ثبت می‌شود و دلیلی برای تلاش مجدد نیست.

هر پاسخی که با این فرمت‌ها مطابقت نداشته باشد، «Miss» علامت می‌خورد. نویسنده صراحتاً نسبت به حلقه‌های «تلاش کن تا اعمال شود» هشدار می‌دهد و می‌گوید این رفتار فقط توکن‌ها را مصرف می‌کند در حالی که تظاهر به یک مطالعه علمی دارد. بخش مکانیکی فرآیند سپس از harness/extract_diff.py استفاده می‌کند تا پاسخ را به candidate.diff تبدیل کرده و آن را از طریق patch -p0 < candidate.diff اعمال کند و سپس دوباره pytest را برای بررسی کد after_model_exit اجرا نماید.

نقش دفتر کل و شاهد

برای مدیریت هزینه‌ها، یک کلاس Ledger در harness/ledger.py پیاده شده است. توکن‌های رایگان اغلب در بازنویسی‌ها ناپدید می‌شوند؛ چسباندن یک Traceback و پرسیدن دوباره، از نظر کاربر «تکرار» است اما از نظر شمارنده هزینه، «ناهار» است. دفتر کل، مصرف توکن را در برابر یک سقف سخت‌گیرانه ردیابی می‌کند و در صورت عبور از حد مجاز، یک SystemExit ایجاد می‌کند.

نویسنده پیشنهاد می‌کند این سقف روی مقدار کمی از کل اعتبار — مثلاً ۴۰۰۰ توکن — تنظیم شود تا حلقه محدود بماند. این مقدار جدا از کل اعتبار است که MonkeyCode ادعا می‌کند در حدود ۱۰ میلیون توکن است. نویسنده هشدار می‌دهد که سهمیه‌ها تغییر می‌کنند و کاربران باید پیش از برنامه‌ریزی هفته خود، ارقام صفحه پروژه را تایید کنند. دستور python harness/run_eval.py --plants harness/plants --ceiling 4000 --dry-run اجازه می‌دهد یک تمرین بدون هزینه انجام شود.

علاوه بر این، یک «شاهد» (Witness) معرفی شده است؛ سروری رایگان که توسط MonkeyCode ارائه شده است. شاهد تنها پس از قرمز شدن اوراکل محلی برای تایید قابلیت انتقال (Portability) استفاده می‌شود. فرآیند شامل SSH کردن به رانر (مثلاً ssh [email protected] -- python -m pytest -q tests/test_take.py) برای اجرای همان دستور pytest و ثبت کد witness_exit است.

• قرمز در لپ‌تاپ / سبز در سرور: نشان‌دهنده‌ی قابلیت انتقال است، نه نبوغ.
• هر دو قرمز: وصله شکست خورده یا کاشت هنوز در درخت است.
• هر دو سبز (پیش از صحبت مدل): روز باطل است؛ کاربر باید برگردد و «دود ایجاد کند».

خواندن نتایج مانند آمپرهای فشار

ارزیابی نهایی یک «نرخ برد» ساده یا یک جدول رده‌بندی نیست، بلکه مجموعه‌ای از چهار معیار مجزا است که نباید با هم ترکیب شوند. نویسنده نتایج را مانند یک مکانیک که آمپرهای فشار را می‌خواند بررسی می‌کند، نه مانند طرفداری که نتیجه بازی را می‌بیند:

• نرخ شکست اوراکل: درصد کاشت‌هایی که اوراکل محلی شناسایی کرد. این باید ۱۰۰٪ باشد و در غیر این صورت روز باطل است.
• نرخ تعمیر: دفعاتی که مدل یک diff مینیمال تولید کرد که روی کاشت‌هایی که اوراکل واقعاً شناسایی کرده بود، سبز شد.
• نرخ چاپلوسی کاذب: دفعاتی که مدل یک تابع دارای باگ را «سالم» خواند. این معیار مهم‌تر از یک تعمیر زیباست.
• عدم تطابق شاهد: تفاوت بین کدهای خروجی محلی و سرور.

چاپلوسی کاذب به عنوان خطرناک‌ترین نوع شکست برجسته شده است. ابزاری که یک قطعه کد خراب را تایید کند، قطعاً زمانی که توسعه‌دهنده در ساعت ۱ صبح خسته است، یک باگ واقعی را هم تایید خواهد کرد. برای جلوگیری از چنین خطاهایی، ثبت خروجی‌های مدل در قالب Snapshot به عنوان راهکاری برای مقابله با خطاهای نامشخص ارزیابی پیشنهاد شده است. نویسنده عمداً این سلول‌ها را خالی می‌گذارد و از ارائه زمان‌بندی یا نرخ برد خودداری می‌کند و اصرار دارد که خروجی‌های خام در کنار کامیت‌ها نگه داشته شوند.

محدودیت‌های این رویکرد

نویسنده هشدار می‌دهد که این روش یک «مانور آتش‌نشانی» است، نه نقشه‌ای جامع از کل مخزن کد. این روش برای حوزه‌های حساس مثل رمزنگاری، احراز هویت یا هر خطری که تست‌های واحد (Unit Test) نمی‌توانند نام ببرند، مناسب نیست. یک تابع take() سبز، لزوماً بررسی توکن‌ها را امن نمی‌کند.

دو محدودیت اصلی در طراحی وجود دارد:

• نشت داده (Leakage): اگر لیست مورد انتظار در پرامپت باشد، مدل ممکن است به جای تابع، مثال را وصله کند. پرامپت باید «گرسنه تر» از فایل تست باقی بماند.
• مقیاس (Scale): یک کاشت لزوماً نقشه‌ای از کل مخزن نیست. نویسنده پیشنهاد می‌کند باگ‌هایی که قبلاً اصلاح شده‌اند را دوباره بازسازی کنند و نام‌ها را حذف کنند تا مدل بر اساس حافظه‌اش از یک پیام کامیت خاص پاسخ ندهد. باگی که نتوان آن را بازسازی کرد، به عنوان یک حکایت با نورپردازی بهتر تلقی می‌شود، نه یک نقطه داده.

در نهایت، نویسنده توصیه می‌کند از فلگ --dry-run برای چاپ پرامپت بدون هزینه استفاده کنید و آن را به کمربند ایمنی در یک پارکینگ تشبیه می‌کند. اگر از مدل و سرور رایگان MonkeyCode استفاده می‌کنید، توصیه می‌شود مستندات فعلی را برای تایید اعتبار توکن‌ها و محدودیت‌های سرور بخوانید، زیرا نویسنده ترجیح می‌دهد کاربر به اعتبار شک کند تا به متن مقاله اعتماد کند.

گام بعدی شما

• در پروژه‌های خود، پیش از درخواست اصلاح کد از AI، تستی بنویسید که عمداً روی باگ فعلی شکست بخورد.
• پاسخ‌های مدل را به جای «کار می‌کند یا نه»، بر اساس «آیا واقعاً تغییر لازم را اعمال کرد یا فقط کد را بازنویسی کرد» بسنجید.
• از فلگ --dry-run برای بررسی پرامپت‌ها بدون مصرف توکن استفاده کنید.

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