تصور کنید ابزاری می‌سازید که تمام چراغ‌های سبزِ داشبوردِ تست را روشن کرده است، اما به محض انتشار، در برابر اولین کاربر واقعی از کار می‌افتد. این کابوسِ هر برنامه‌نویس، حالا به یک هشدار جدی برای کسانی تبدیل شده که تمام چرخه تولید نرم‌افزار را به هوش مصنوعی می‌سپارند.
به گزارش وب‌سایت dev.to در تاریخ ۳ اکتبر ۲۰۲۶، یک توسعه‌دهنده برای ساخت یک ابزار تجاری تحلیل کرش‌های (Crash) بازی ماینکرفت از Claude استفاده کرد. نتیجه تکان‌دهنده بود: ابزاری که در ۶ مورد از ۶ تست داخلی‌اش موفق شده بود، پس از استقرار در محیط واقعی، در ۵ مورد از ۸ سناریوی واقعی شکست خورد.
این اتفاق در حالی رخ می‌دهد که صنعت به سمت جریان‌های کاری عامل‌محور (Agentic) — شبیه به استخدام کارمندی که از نوشتن کد تا انتشار محصول را به‌تنهایی مدیریت می‌کند — حرکت می‌کند. برای صاحبان کسب‌وکار، این وعده یعنی کاهش هزینه‌های مهندسی، اما ریسک واقعی اینجاست که هوش مصنوعی در واقع دارد «برگه امتحان خودش را تصحیح می‌کند» و با ایجاد یک توهمِ موفقیت، محصولی شکسته را به عنوان محصول سالم تحویل می‌دهد. در همین راستا، برخی از توسعه‌دهندگان برای مقابله با این چالش‌ها از متدهای سخت‌گیرانه‌تری استفاده کرده‌اند، مشابه راهکار یک مؤسس SaaS برای حذف توهمات عامل‌های هوش مصنوعی که بر اساس یک سیستم پرسش و پاسخ دقیق طراحی شده است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی توهمات مدل‌های زبانی اشاره کردیم، مشکل اصلی در اینجا عدم توانایی مدل در درک «پیچیدگی‌های پیش‌بینی‌نشده» است.
تله‌ی تست‌های مصنوعی
توسعه‌دهنده از Claude خواست تا یک خواننده گزارش کرش و یک اعتبارسنج شناسه برای سرورهای ماینکرفت بسازد. هدف این بود که مدل تمام مراحل، از کدنویسی و نوشتن تست‌ها تا راه‌اندازی فروشگاه و انتشار آن را با کمترین دخالت انسانی انجام دهد. تنها چیزی که مدل نمی‌توانست شبیه‌سازی کند، یک سرور واقعی با ۲۳۴ مود (Mod)، لاگ‌های (Logs) جاری آن و گزارش‌های کرش واقعی بود.
مدل کد و تست‌ها را به‌طور هم‌زمان نوشت. چون هر دو توسط یک مدل ساخته شده بودند، تست‌ها دقیقاً بر اساس برداشت‌های محدودِ خودِ مدل از الگوهای خطا تنظیم شده بودند. نسخه اول، ۶ حالت شکست را شناسایی کرد و برای هر کدام یک تست نوشت که دقیقاً همان رشته متنی (String) مورد نظر مدل را داشت. هر نمونه‌ی تست (Fixture) در واقع یک لاگ کوچک بود که دقیقاً حاوی همان رشته‌ای بود که الگوی مدل به دنبالش می‌گشت.
اما وقتی ابزار با پوشه‌ای از گزارش‌های واقعی مواجه شد، عملکردش فروپاشید. مدل نمونه‌های «تمیز» از خطاها ساخته بود، اما در واقعیت، کرش‌ها در میان استثناهای (Exceptions) پیچیده فریم‌ورک پنهان بودند، یا به صورت خطاهای NoClassDefFoundErrors ناشی از فایل‌های JAR قدیمی ظاهر می‌شدند، یا شناسه‌های منابع (Resource IDs) بدشکلی داشتند که هیچ نمونه‌ی مصنوعی پیش‌بینی نکرده بود. تنها پس از بازنویسی قوانین بر اساس ۱۳ گزارش واقعی، ابزار توانست به نرخ موفقیت ۱۳ از ۱۳ برسد.
شکست‌های منطقی و فنی
بر اساس مستندات این پروژه، چندین شکست فنی بحرانی رخ داد که استدلال داخلی مدل قادر به حل آن‌ها نبود:
- فاجعه در Regex: پردازش یک لاگ ۳.۴ مگابایتی ۵۹ ثانیه زمان برد. مدل تئوری داد که تأخیر به دلیل وجود یک خط با ۱۰۷,۴۴۵ کاراکتر (یک صفحه HTML که توسط یک مود لاگ شده بود) است. اما وقتی طول خطوط را محدود کرد، زمان اجرا از ۵۸.۸۴ ثانیه به ۵۸.۸۴ ثانیه تغییر کرد؛ یعنی هیچ تغییری رخ نداد. اندازه‌گیری زمان‌بندی مراحل (Stage timing) حقیقت را فاش کرد: مرحله
read_logتنها ۰.۰۴ ثانیه زمان برد، اما مرحلهdiagnoseبیش از ۱۱۵ ثانیه طول کشید. مقصر اصلی یک دستورre.search()با الگویr"(?P<mod>\S+).*is client ?-?only"بود. استفاده از\S+بدون محدودیت و دنباله‌ی.*باعث می‌شد موتور Regex در خطوط طولانی که تطبیق ندارند، تمام حالت‌های ممکن را امتحان کند. با محدود کردن آن بهr"(?P<mod>\S{1,80}) is client[ \-]?only"زمان اجرا به ۱.۹۷ ثانیه کاهش یافت. - خطای لیست‌های نادیده (Skip List): ارزش اصلی ابزار، حاشیه‌نویسی فریم‌های استک (Stack frames) با فایل JAR منبع برای شناسایی اولین JAR شخص ثالث در یک ردپای خطا بود. اما لیست نادیده‌گیری (Skip list) مدل غلط بود. نسخه اول نیمی از کرش‌ها را به گردن
netty-commonمی‌انداخت، چون Netty در بالای ردپاهای شبکه قرار دارد. پس از اصلاح، مدلfmlloaderو سپسmodlauncherرا مقصر دانست. هر پاسخ مدل مقتدرانه به نظر می‌رسید اما غلط بود و تنها با اجرای گزارش‌هایی که علتشان از قبل مشخص بود، شناسایی شد. در این نقطه، اهمیت مدیریت صحیح داده‌های سیستمی آشکار می‌شود؛ چرا که لاگ‌های CI و گزارش‌های کرش اگر به‌درستی مدیریت نشوند، علاوه بر خطاهای منطقی، می‌توانند نقشه‌هایی مخفی برای مهاجمان باشند. - خطاهای تطبیق تقریبی (Fuzzy Matching): اعتبارسنج شناسه‌ها، ۱۶۹ مورد غلط املایی گزارش کرد که در واقع غلط نبودند (مثلاً پیشنهاد
wastelandmod:icepickبرایwastelandmod:alicepack). مدل مسیرهای کامل شناسه‌ها را مقایسه می‌کرد و چون فضای نام (Namespace) مشترک بود، ۱۳ کاراکتر یکسان به امتیاز هر مورد اضافه می‌شد. وقتی مقایسه فقط روی مسیرها انجام شد، ۱۶۹ کاندید به ۶۳ مورد کاهش یافت و مشخص شد که در پکی که توسط هزاران نفر بازی شده بود، تنها سه مورد واقعاً غلط املایی بودند. - توهمات API: Claude ادعا کرد که API فروشگاه قابلیت آپلود فایل را ندارد و هر نسخه باید دستی آپلود شود. مدل چهار نام فرضی برای نقاط اتصال (Endpoints) حدس زده بود و چون با خطای ۴۰۴ مواجه شد، نتیجه گرفت که این قابلیت اصلاً وجود ندارد. در حالی که در واقعیت، ارسال یک فایل به نقطه اتصال به‌روزرسانی محصول، یک پیام خطا برمی‌گرداند که کل جریان آپلود را مستند کرده بود: پیش‌امضا (Presign)، آپلود بخش‌ها، تکمیل و پیوست کردن.
پارادوکس نظارت و نشت داده
مدل حتی در نظارت بر محصول خودش شکست خورد. ابزاری نوشت تا بررسی کند آیا فایل‌ها به فروشگاه متصل شده‌اند یا خیر. وقتی API یک فیلد خالی {} برگرداند — که زمانی رخ می‌دهد که دو فایل وجود داشته باشد یا یک فایل در محتوای غنی (Rich content) جاسازی شده باشد، به جای یک پیوست ساده — مدل استنتاج کرد که فایل «گم شده است».
این موضوع منجر به یک هشدار اشتباه شد که ادعا می‌کرد یک محصول پولی هیچ فایل دانلودی ندارد. توسعه‌دهنده مجبور شد یک تست جدید را دقیقاً به نام این «مثبت کاذب» (False Positive) پیاده‌سازی کند و بررسی را به نقطه اتصالی منتقل کند که واقعاً لیست فایل‌ها را برمی‌گرداند.
نگران‌کننده‌ترین بخش، نشت داده (Data Leakage) بود. مدل از نام یک مود واقعی شخص ثالث به عنوان مثال از یک «مود خراب» در فایل README، مجموعه تست‌ها و یک مقاله منتشر شده استفاده کرد، زیرا آن مود واقعاً باعث کرش شدن یکی از لاگ‌های توسعه‌دهنده شده بود. این یعنی مدل در صورت انتشار، یک اتهام عمومی را علیه یک توسعه‌دهنده واقعی به مشتریان پولی تحویل می‌داد. این مورد تنها از طریق یک بررسی دستی که برای اسکن خروجی‌ها جهت یافتن این دسته از نشت‌ها طراحی شده بود، شناسایی و با یک نام ساختگی جایگزین شد.
شکاف واقعیت
این آزمایش نشان می‌دهد محدودیت فعلی هوش مصنوعی، سرعت نوشتن یا سینتکس نیست، بلکه توانایی «تأیید حقیقت» است. Claude در نوشتن سریع و با رعایت بهداشت کد عالی بود، اما در تشخیص درست یا غلط بودن پاسخ‌هایش، هیچ تفاوتی با حدس زدن نداشت. تمام باگ‌ها نه با پرامپت‌های بیشتر، نه با استدلال بیشتر و نه با تست‌های بهتر، بلکه تنها با برخورد با یک سیستم واقعی پیدا شدند.
برای توسعه‌دهندگان و صاحبان کسب‌وکار، نقش انسان در حال تغییر است. تقسیم کار دیگر این نیست که «هوش مصنوعی کارهای سخت را انجام دهد»، بلکه این است که هوش مصنوعی سریع و منظم بنویسد و انسان نقش «تأییدکننده واقعیت» را ایفا کند. شغل شما حالا این است که بخشی از حلقه باشید که با دنیای واقعی — لاگ‌های واقعی، کرش‌های واقعی، پاسخ‌های واقعی API و کاربران واقعی — در تماس است.
برای اجتناب از این تله‌ها، توسعه‌دهندگان باید نسبت به تست‌های «سبز» و موفق مشکوک باشند، به‌ویژه اگر کد و تست هر دو توسط یک مدل نوشته شده‌اند. هدف باید حرکت از «اعتبارسنجی مصنوعی» به سمت «تأیید تجربی» از طریق پیاده‌سازی تست‌های خصمانه (Adversarial Testing) با استفاده از داده‌های واقعی محیط تولید باشد.
گام بعدی شما
- هرگز به تست‌های «سبز» و موفق اعتماد نکنید، به‌خصوص اگر کد و تست هر دو توسط یک مدل نوشته شده‌اند.
- از داده‌های واقعی محیط تولید (Production) برای ایجاد تست‌های خصمانه (Adversarial Testing) استفاده کنید.
- فرآیند بررسی دستی (Manual Review) را برای خروجی‌های عمومی مدل‌ها، به‌ویژه در مورد نام برندها و اشخاص، اجباری کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو