اگر امروز کدی را صرفاً چون «منطقی به نظر می‌رسد» تایید می‌کنید، در واقع دارید برای یک قطعی گسترده در محیط عملیاتی (Production) زمینه‌سازی می‌کنید. طبق یک راهنمای مهندسی ارشد که در ۱۴ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، کدهای تولیدشده توسط هوش مصنوعی اغلب از بازبینی‌های سطحی عبور می‌کنند اما در محیط‌های واقعی شکست می‌خورند.
این ریسک از مفهومی به نام «توهم صلاحیت» ناشی می‌شود. مدل‌های هوش مصنوعی کدی می‌نویسند که شبیه به نوشته‌های یک متخصص است و همین باعث می‌شود بازبین‌های انسانی به‌طور ناخودآگاه شکاف‌های منطقی را پر کنند. همان‌طور که در پوشش پیشین ما درباره‌ی ابزار GitX و سازماندهی کامیت‌های نامنظم هوش مصنوعی دیدیم، اکنون تمرکز از «نحوه سازماندهی» به «نحوه تایید ایمنی» این کدها تغییر کرده است. برای مقابله با این چالش، پیاده‌سازی سازوکارهای ممیزی رفتاری برای کنترل خروجی‌های مدل‌های برنامه‌نویسی می‌تواند مانع از ادغام کورکورانه کدهای AI در مخازن اصلی شود.
برای اکثر توسعه‌دهندگان، خطر اصلی خطای سینتکس (Syntax Error) نیست — چون کامپایلر آن را می‌گیرد — بلکه «شکست خاموش» است؛ وضعیتی که در آن کد دقیقاً همان چیزی است که در پرامپت خواسته‌اید، اما نه آن چیزی که کسب‌وکار واقعاً به آن نیاز دارد.
شکاف منطق و هدف
نخستین خط دفاعی، زیر سوال بردن مسئله‌ای است که کد سعی در حل آن دارد. هوش مصنوعی زاینده (Generative AI) — مثل دانش‌آموزی که فقط کلمات سوال را می‌بیند و نه مفهوم پشت آن — تمایل دارد به متن صریح پرامپت پاسخ دهد نه هدف واقعی. به نقل از این راهنما، تابعی برای دریافت «کاربران فعال» ممکن است صرفاً یک پرچم بله/خیر را چک کند، در حالی که هدف تجاری، بررسی ورود کاربر در ۳۰ روز گذشته است.
بازبین‌ها باید از نگاه سریع فاصله بگیرند. این راهنما آزمون «توضیح شفاهی» را پیشنهاد می‌کند: اگر نمی‌توانید مراحل اصلی یک تابع را در یک جمله برای هر مرحله بلند بلند توضیح دهید، یعنی واقعاً آن را بازبینی نکرده‌اید.
شناسایی پیش‌فرض‌های پنهان
هوش مصنوعی به‌طور مکرر پیش‌فرض‌های خطرناکی درباره ساختار داده‌ها می‌سازد. یک مثال رایج، فرض بر این است که یک آرایه (Array) — شبیه به لیستی از خریدها که ترتیبش مهم است — همیشه مرتب است یا هرگز خالی نیست. اگر این موارد صراحتاً در کد چک نشوند، سیستم هنگام مواجهه با ورودی‌های غیر استاندارد کرش می‌کند.
ورودی بد یک قطعیت است، نه یک مورد استثنایی. بازبین‌ها باید سه سناریوی خاص را برای هر تابع ردیابی کنند:
- ورودی‌های خالی
- انواع داده‌های اشتباه
- مقادیر به‌شدت بزرگ
شکست‌های زیرساختی و امنیتی
کدهای تولیدشده اغلب مسیر «بهترین حالت» (Happy Path) را برای سرویس‌های خارجی فرض می‌کنند. بر اساس مستندات منتشر شده، این کدها معمولاً فاقد مهلت زمانی (Timeout) یا مدیریت خطا برای پاسخ‌های غیر ۲۰۰ در پروتکل HTTP هستند. اگر یک API شخص ثالث کند شود، نبود یک راه جایگزین می‌تواند کل اپلیکیشن را منجمد کند.
بررسی‌های امنیتی نقطه شکست رایج دیگری هستند. هوش مصنوعی اغلب احراز هویت (Authentication) را پیاده می‌کند اما مجوز دسترسی (Authorization) را فراموش می‌کند؛ یعنی چک می‌کند کاربر وارد شده است، اما بررسی نمی‌کند که آیا این کاربر واقعاً مالک منبع درخواستی هست یا خیر.
علاوه بر این، هوش مصنوعی اغلب داده‌های حساس را از طریق بلوک‌های خطا لو می‌دهد. گنجاندن err.stack در پاسخ‌های محیط عملیاتی می‌تواند مسیرهای داخلی فایل‌ها و تکه‌های کوئری را در اختیار مهاجمان قرار دهد.
نگهداری و بدهی فنی
مهندسی بیش از حد (Over-engineering) یک ویژگی تکراری در مدل‌ها است. مدل‌ها اغلب لایه‌های انتزاعی غیرضروری را برای مسائل ساده معرفی می‌کنند. اگر تابعی می‌توانست نصف طول فعلی‌اش باشد و همچنان درست کار کند، این یعنی یک هزینه نگهداری دائمی.
تست‌های تولیدشده توسط هوش مصنوعی اغلب «دوری» هستند. آن‌ها تایید می‌کنند کد کاری را می‌کند که در حال حاضر انجام می‌دهد، نه کاری که «باید» انجام دهد. تستی که فقط محاسبه تخفیف موفق را چک می‌کند، نمی‌تواند نحوه برخورد سیستم با قیمت منفی یا تخفیف بالای ۱۰۰٪ را بسنجد.
در نهایت، کد باید با استانداردهای موجود در پروژه همخوانی داشته باشد. معرفی یک کلاینت HTTP جدید یا سبک لاگ‌گذاری متفاوت، صرفاً چون هوش مصنوعی آن را پیشنهاد داده، باعث ایجاد بدهی فنی پراکنده می‌شود.
تله هم‌زمانی (Concurrency)
کدی که برای یک درخواست کار می‌کند، اغلب زیر فشار زیاد می‌شکند. هوش مصنوعی مکرراً عملیات‌های غیراتمیک «خواند-سپس-نوشت» را برای وضعیت‌های مشترک پیشنهاد می‌دهد که منجر به از دست رفتن به‌روزرسانی‌ها در دسترسی‌های هم‌زمان می‌شود.
آخرین بررسی، «تست غریبه» است. اگر توسعه‌گری هشت ماه بعد بدون هیچ زمینه‌ای فایل را باز کند، آیا می‌تواند «چرایی» پیاده‌سازی را فقط از روی کامنت‌ها بفهمد؟
این تغییر در انضباط بازبینی ضروری است زیرا حجم کدهای تولیدشده توسط هوش مصنوعی سریع‌تر از عادت‌های بازبینی ما رشد کرده است. هدف این است که با کد هوش مصنوعی نه به عنوان یک محصول نهایی، بلکه به عنوان پیش‌نویس یک برنامه‌نویس جونیور برخورد کنیم که با اعتمادبه‌نفس زیاد، گاهی دچار توهم می‌شود.
گام بعدی شما
- برای هر تابع تولیدشده، سه مورد «ورودی خالی»، «نوع داده غلط» و «مقدار غیرمنطقی» را تست کنید.
- آزمون توضیح شفاهی را اجرا کنید: هر مرحله از کد را در یک جمله ساده برای خودتان تعریف کنید.
- بررسی کنید که آیا کد بین «احراز هویت» و «مجوز دسترسی» تفکیک قائل شده است یا خیر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو