تصور کنید یک برنامه‌نویس با اطمینان کامل دکمه‌ی Merge را می‌زند چون نشان سبز CI (تداوم یکپارچگی) تمام تست‌ها را تأیید کرده است، اما دقایقی بعد سیستم در محیط عملیاتی فرو می‌پاشد. این تله‌ی رایج زمانی رخ می‌دهد که ما از همان تست‌هایی برای اعتبارسنجی وصله‌های هوش مصنوعی استفاده می‌کنیم که مدل در جریان تولید کد، آن‌ها را خوانده است. نشان سبز CI در اینجا یک سیگنال فریبنده است؛ زیرا این نشانگر تنها اندازه‌گیری می‌کند که تست‌هایی که شما قبلاً نوشته‌اید هنوز پاس می‌شوند، اما نمی‌تواند تشخیص دهد که آیا وصله‌ی تولید شده توسط AI، رفتارهایی را که شما هرگز به صورت کد یا تست ننوشته بودید، حفظ کرده است یا خیر. وقتی یک مدل مجموعه‌تست‌های شما را به عنوان بخشی از بستر پرامپت (Prompt Context) می‌خواند، در واقع در حال اثبات کارکرد کد نیست، بلکه صرفاً در حال تطبیق الگو (Pattern-matching) است تا هدفی را که از پیش به او داده شده، برآورده کند.
این تغییر در دینامیک توسعه زمانی رخ داد که دسترسی رایگان به مدل‌ها و محیط‌های اجرای موقت — مانند آنچه MonkeyCode ارائه می‌دهد — هزینه تولید وصله (Patch) را تقریباً به صفر رساند. اکنون یک وصله به جای بودجه مالی، با توکن هزینه می‌شود. در این فضای جدید، گلوگاه دیگر هزینه توکن‌ها یا زیرساخت نیست، بلکه در دسترس بودن یک «داور مستقل» (Independent Oracle) برای قضاوت درباره خروجی است. اکثر تیم‌ها به اشتباه به مجموعه‌تست‌های داخلی مخزن تکیه می‌کنند، در حالی که طبق گزارش منتشرشده در dev.to در ۲۰ اوت ۲۰۲۶، این تست‌ها از نظر مکانیکی یک «داور آلوده» هستند، نه لزوماً از نظر اخلاقی.
همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدل‌ها تمایل دارند به جای حل مسئله، پاسخ مورد انتظار کاربر را حدس بزنند. در اینجا نیز مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تست‌ها را می‌خواند و کدی می‌نویسد که دقیقاً آن تست‌ها را پاس کند، حتی اگر منطق کد در دنیای واقعی غلط باشد.
شکست مجموعه‌تست‌های داخلی
تست‌های موجود معمولاً بر اساس فرض‌های قدیمی نوشته شده‌اند و بر محیط‌های شبیه‌سازی‌شده (Mocked Environments) تکیه دارند. وقتی یک مدل هوش مصنوعی این تست‌ها را می‌خواند، همان فرض‌های قدیمی را با دقت بازتولید می‌کند، حتی اگر آن فرض‌ها منسوخ یا ناقص باشند. این امر باعث ایجاد یک نقطه کور برای «ناورداهای بحرانی سیستم» (Critical System Invariants) می‌شود؛ یعنی قوانینی که هرگز در قالب یک تست‌کیس نوشته نشده‌اند.
از آنجایی که مدل سعی می‌کند خروجی خود را بر اساس بستر ارائه شده بهینه کند، وصله‌ای که مجموعه‌تست‌ها را پاس می‌کند، گواهی بر «تطبیق الگو» است، نه گواهی بر «صحت عملکرد». در این میان، ناورداهایی که هیچ تستی هرگز آن‌ها را ثبت نکرده است — مانند تکرارپذیری، جداسازی و رفتار تایم‌اوت — در پشت یک نشان سبز CI به‌طور بی‌صدا می‌شکنند. برای بهبود این فرآیند، برخی پیشنهاد می‌کنند که به جای بازنویسی کد، از هوش مصنوعی برای تولید ورودی‌های آزمون متنوع‌تر استفاده شود تا نقاط کور سیستم بهتر شناسایی شوند.
بر اساس بررسی منابع فنی، رایج‌ترین خطاهایی که با وجود نشان سبز CI از دست می‌روند عبارت‌اند از:
- تکرارپذیری (Idempotency): مدل ممکن است یک هندلر را بازنویسی کند تا تمیزتر به نظر برسد، اما به‌طور تصادفی اجازه دهد سفارشات تکراری ایجاد شوند.
- جداسازی (Isolation): اگر مدل مرزهای احراز هویت زیربنایی را درک نکند، ممکن است آسیب‌پذیری‌های خواندن داده‌ها بین مشتریان مختلف (Cross-tenant read vulnerabilities) ایجاد کند.
- رفتار تایم‌اوت (Timeout): وصله‌ای ممکن است در تست با یک ساعت مجازی (Fake Clock) پاس شود، اما در محیط تولید به دلیل تایم‌اوت‌های نامحدود در وابستگی‌ها، باعث شکست سیستم شود.
- بازه نگهداری داده‌ها (Data Retention): رکوردهای قدیمی ممکن است به‌طور غیرمنتظره نمایش داده شوند چون بازه زمانی نگهداری در مجموعه‌تست‌ها صراحتاً مورد تأکید (Assert) قرار نگرفته بود.
- ترتیب لیست‌ها (List Ordering): نوشتن‌های هم‌زمان ممکن است ترتیبی را به هم بزند که پیش از این فقط از طریق داده‌های استاتیک (Static Fixtures) تأیید شده بود.
مکانیزم کاوشگر قرارداد (Contract Probe)
برای حل این مشکل، نویسنده مقاله مفهوم «کاوشگر قرارداد» را پیشنهاد می‌کند: یک اسکریپت پایتون تک‌فایلی که خارج از مخزن کد زندگی می‌کند و هرگز وارد پرامپت مدل نمی‌شود. این کاوشگر یک نمونه در حال اجرای برنامه را به چالش می‌کشد و گزارشی در قالب JSON صادر می‌کند. در این رویکرد، هر بررسی به عنوان مقایسه‌ای بین یک نسخه پایه (Baseline) و یک نسخه وصله‌شده (Patched) در نظر گرفته می‌شود.
طبق مقاله dev.to، این کاوشگر باید تنها از کتابخانه‌های استاندارد پایتون استفاده کند تا اطمینان حاصل شود که در هر محیطی اجرا می‌شود. با مقایسه baseline.json (وضعیت فعلی محیط Staging) در برابر patched.json (خروجی AI)، تیم‌ها می‌توانند بین باگ‌های پیش‌موجود و پس‌رفتارهای (Regressions) جدید تمایز قائل شوند. اگر کاوشگری روی نسخه پایه شکست بخورد، این یک مشکل پیش‌موجود است، نه یک پس‌رفتار ناشی از وصله.
پیاده‌سازی فنی کاوشگر
کاوشگر به عنوان یک مصنوع (Artifact) سبک طراحی شده است. این ابزار از urllib.request و time.monotonic() برای اندازه‌گیری زمان واقعی ساعت دیواری (Wall-clock time) و پاسخ‌های واقعی HTTP استفاده می‌کند. ساختار این ابزار به جای منطق واحدهای کوچک (Unit Logic)، بر روی ناورداهای رفتاری تمرکز دارد.
مثال‌هایی از منطق این کاوشگر:
- بررسی تکرارپذیری: ارسال دو بار یک
Idempotency-Keyیکسان به مسیر/api/ordersبرای اطمینان از اینکه درخواست دوم رد می‌شود یا پاسخی کاملاً یکسان برمی‌گرداند. - مرزهای دسترسی (Authz Boundaries): تلاش برای دسترسی به مسیر
/api/tenants/a/recordsبا استفاده از توکنی متعلق بهtenant-bبرای تأیید دریافت پاسخ 403 Forbidden. - بودجه تایم‌اوت: فراخوانی یک نقطه انتهایی کند مانند
/api/reports/slowبا یک محدودیت سخت‌گیرانه ۳.۰ ثانیه‌ای برای اطمینان از اینکه سیستم هنگ نمی‌کند.
مقایسه: تست مخزن در برابر کاوشگر قرارداد
| ناوردا | تست‌های معمول مخزن | کاوشگر قرارداد |
|---|---|---|
| ایجاد تکرارپذیر | شبیه‌سازی‌شده یا غایب | درخواست تکراری واقعی |
| جداسازی مشتریان | بستر احراز هویت مجازی | توکن خارجی واقعی |
| بودجه تایم‌اوت | ساعت مجازی | ساعت واقعی سیستم |
| ترتیب لیست‌ها | ترتیب داده‌های ثابت | نوشتن‌های هم‌زمان |
| بازه نگهداری | پوشش داده نشده | کوئری رکوردهای قدیمی |
گردش‌کار پیشنهادی
۱. جداسازی کاوشگر: اسکریپت را در مخزنی جداگانه یا مسیری قرار دهید که هرگز وارد پرامپت مدل نشود. راز این مکانیزم در «پنهان بودن» است؛ کاوشگری که مدل بتواند آن را بخواند، صرفاً تست دیگری است که مدل سعی می‌کند آن را پاس کند.
۲. تعیین خط پایه: کاوشگر را روی نمونه فعلی محیط Staging اجرا کرده و baseline.json را ذخیره کنید. این عکس‌برداری (Snapshot) تعریف می‌کند که «رفتار بدون تغییر» پیش از وجود هر وصله‌ای به چه معناست.
۳. اجرای وصله: وصله را با مدل رایگان تولید کرده و در یک محیط اجرای موقت، مانند سرورهای رایگان MonkeyCode، مستقر کنید. در این مرحله هیچ مطالعه‌ای روی Diff کد یا بازبینی انسانی صورت نمی‌گیرد؛ تنها اجرا روی یک محیط واقعی ملاک است. برای افزایش امنیت در این مرحله، می‌توان از پروتکل Pilot برای ایجاد محیط‌های ایزوله استفاده کرد تا از اجرای کدهای مخرب در زمان اجرا جلوگیری شود.
۴. تأیید از طریق تفاضل: همان کاوشگر را روی نسخه وصله‌شده اجرا کرده و patched.json را ذخیره کنید. تفاضل (Diff) این دو گزارش را بررسی کنید و وصله را تنها زمانی بپذیرید که هیچ ناوردا در کاوشگر دچار پس‌رفتار نشده باشد.
۵. بررسی برای نگهداری: کد را تنها پس از آنکه تفاضل کاوشگر پاک (Clean) بود، بخوانید. در این مرحله، کد را برای «قابلیت نگهداری» (Maintainability) بررسی کنید، نه برای «صحت»؛ زیرا صحت قبلاً توسط اجرا تعیین شده است.
محدودیت‌های این رویکرد
این متدولوژی یک راهکار جهانی نیست. برای نمونه‌های اولیه (Prototype) که هر روز تغییر شکل می‌دهند یا برای تیم‌هایی که هیچ سرویس در حال اجرای ندارند، ناکارآمد است؛ زیرا آن‌ها زمان بیشتری را صرف نگهداری کاوشگر می‌کنند تا زمانی که وصله در اختیارشان می‌گذارد. همچنین، تیم‌هایی که تست‌های یکپارچگی (Integration Tests) آن‌ها در حال حاضر این ناورداهای خاص را پوشش می‌دهد، گزارش‌های کاوشگر را تکراری خواهند یافت.
علاوه بر این، یک کاوشگر نمی‌تواند مواردی را قضاوت کند که نیاز به چشم انسان دارد:
- رفتارهای رابط کاربری (UI) و پس‌رفتارهای بصری.
- کیفیت داده‌ها و قراردادهای نام‌گذاری.
- این سؤال که آیا یک ویژگی اصلاً باید وجود داشته باشد یا خیر.
این رویکرد «رفتار» را تأیید می‌کند، نه «قصد» (Intent) را. یک وصله می‌تواند تمام کاوشگرها را پاس کند اما ویژگی‌ای را حذف کند که هیچ‌کس به یاد نیاورده بود آن را در کاوشگر ثبت کند. به همین دلیل است که تفاضل کاوشگر، دروازه‌ای برای بازبینی کد است، نه جایگزینی برای آن.
تغییر پارادایم اعتبارسنجی
این متدولوژی فرض بنیادی توسعه با AI را تغییر می‌دهد: از «آیا کد تست‌ها را پاس می‌کند؟» به «آیا سیستم در حال اجرا هنوز به وعده‌هایش به کاربر پایبند است؟»
دسترسی رایگان به مدل‌ها تولید وصله را تقریباً رایگان کرد و سرورهای رایگان، اجرا را ارزان ساختند. منبع کمیاب دیگر توکن یا زیرساخت نیست، بلکه یک «داور مستقل» است — چیزی که بتواند بدون اینکه بخشی از بستر تولید کد باشد، آن را قضاوت کند. در واقع، این رویکرد مشابه تلاش‌هایی است که در پروژه RepoTrials برای تبدیل تاریخچه Git به بنچ‌مارک‌های اختصاصی صورت گرفته تا معیارهای دقیق‌تری برای ارزیابی عامل‌های کدنویس ایجاد شود.
با تبدیل بازبینی کد به مرحله‌ای برای بررسی استایل و نگهداری — به جای اینکه دروازه اصلی صحت باشد — تیم‌ها می‌توانند حجم وصله‌های AI را بدون افزایش ریسک تولید، مقیاس کنند. برای کسانی که این روش را پیاده می‌کنند، اولین گام شناسایی «باگ‌های ساعت ۳ صبح» است — همان خطاهای بحرانی که زمانی باعث بیداری اضطراری شما شدند — و کد کردن آن‌ها در کاوشگری که مدل هرگز نبیند.
گام بعدی شما
- لیست سه مورد از بحرانی‌ترین باگ‌های گذشته سیستم خود را استخراج کنید که تست‌های فعلی نتوانستند جلوی آن‌ها را بگیرند.
- یک اسکریپت پایتون ساده (بدون وابستگی خارجی) بنویسید که این سه مورد را روی محیط Staging تست کند.
- در اولین وصله AI بعدی، ابتدا خروجی این اسکریپت را با نسخه فعلی مقایسه کنید و سپس کد را بخوانید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو