تصور کن سهشنبه هفته پیشه و یه برنامهنویس سه ساعت تمام وقتش رو گذاشته تا باگی رو پیدا کنه که اصلاً وجود خارجی نداره! کد در ظاهر حرف نداشت؛ ساختار تمیز، رعایت تمام اصول و حتی کامنتهای دقیق برای هر تابع. اما مشکل از جای عجیبی آب میخورد: یکی از تابعها داشت مسئلهای رو حل میکرد که اصلاً کسی ازش نخواسته بود! Claude با اون دانشِ الگویابیِ بیپایانش، خودش تصمیم گرفته بود که اندپوینت API حتماً به صفحهبندی نیاز داره. در حالی که اصلاً نیازی بهش نبود. همین کدِ اضافه، ساختار پاسخها رو جوری بهم ریخته بود که دیباگ کردنش بیشتر از زمانی که آدم خودش کد رو از صفر بنویسه، طول کشید.
این دقیقاً همون مشکل ۶۶ درصدیه.
طبق آخرین نظرسنجی «استک اورفلو» از ۹۰ هزار برنامهنویس، ۶۶ درصدشون گفتن بزرگترین کلافگیشون با هوش مصنوعی اینه که کدها «تقریباً درستن، اما نه کاملاً». ۴۵ درصد دیگه هم معتقد بودن که عیبیابی کدهای هوش مصنوعی، اصلاً به زحمتش نمیارزه. ابزارهایی که قرار بود سرعت ما رو بالا ببرن، یه مدل باگ جدید ساختن که تا چند سال پیش اصلاً نبود: باگی که ظاهرش کاملاً شبیه کد سالمه.
داستان کدی که کلاً غلطه واضحه؛ ارور میده، اجرا نمیشه و توی تستها معلوم میشه. اما کدی که «تقریباً درسته» چی؟ این همون کدیه که تستها رو پاس میکنه، میره روی سرور و بعد ساعت ۲ نصفهشب، وقتی مشتری داره یه کاری انجام میده، یهو یه رفتار عجیب و غریب از خودش نشون میده که کل سیستم رو میبره زیر سوال.
باگهای قدیمی صادق بودن و خودشون رو لو میدادن. اما این باگهای جدید خیلی مودب هستن؛ صبر میکنن تا در بدترین زمانِ ممکن غافلگیرت کنن. برنامهنویسهای قدیمی هر اشتباهی که فکرش رو بکنی انجام دادن؛ از سوتیهای امنیتی تا پاک کردن دیتابیس اصلی. اونها اشتباهات خودشون بود و وقتی سیستم میترکید، سریع میفهمیدن چی شده. چرخه بازخورد سریع بود: یه کار اشتباه انجام میدادی، سیستم اطلاع میداد و یاد میگرفتی دیگه تکرارش نکنی.
اما باگهای هوش مصنوعی اینطوری نیستن. الان وقتی چیزی خراب میشه، اولین سؤال این نیست که «من کجای کار رو اشتباه کردم؟»، بلکه اینه که «هوش مصنوعی چه کاری انجام داده که من متوجهش نشدم؟». این یه مدل کاملاً متفاوت از عیبیابییه. به جای فهمیدن منطق خودت، باید فرضیات یکی دیگه رو مهندسی معکوس کنی. 
تحقیقات مایکروسافت هم این رو تایید میکنه. مدلهای هوش مصنوعی توی تستهای عیبیابی واقعی، حتی بهترینشون مثل Claude 3.7 Sonnet، زیر ۵۰ درصد موفق بودن. این نشون میده مدلها در نوشتن کد عالیان، اما در اصلاح کردنش بدجوری لنگ میزنن. 🧩 چرا؟ چون تولید کد برای هوش مصنوعی یعنی «تکمیل الگو». اون بر اساس میلیاردها نمونه، پیشبینی میکنه کلمات بعدی چی باشن. این برای کدهای تکراری عالیه، اما دیباگ کردن یعنی «تست کردن فرضیهها». هوش مصنوعی نمیدونه چرا ساختار سیستم تو این شکلیه یا فلان قانون بیزنس که منطقی به نظر نمیرسه، چقدر حیاتیه. اون فقط الگوها رو میبینه و تکرار میکنه.
یه آزمایش جالب نشون داده برنامهنویسهایی که از هوش مصنوعی استفاده کردن، ۱۹ درصد کندتر بودن، اما حس میکردن ۲۴ درصد سریعتر شدن! یعنی اون لذتِ سریع آماده شدنِ کد، باعث شده بود بدهی فنی که پشت سرشون جمع میشد رو نبینن. 
قرار نیست کسی استفاده از این ابزارها رو کنار بذاره. اما باید جوری بهشون نگاه کرد که انگار یه برنامهنویس تازهکار اونها رو نوشته؛ کسی که خیلی به خودش مطمئنه ولی مهارتش معمولیه. مشکل این نیست که این ابزارها بد هستن؛ مشکل اینجاست که اونقدر خوب هستن که میتونن خطرناک باشن. چکشی که کلاً به میخ نخوره رو اعصابه، اما چکشی که «تقریباً» جای درست میخوره، آخرش یه خونه کج و معوج بهت تحویل میده.
فعلاً راه حل قطعی وجود نداره. شاید در آینده هوش مصنوعی یاد بگیره به جای فرض کردن، سوال بپرسه. اما تا اون موقع، بهتره برنامهنویسها حواسشون به تستها و کدهای خودشون باشه. بعضی مهارتها رو نباید سپرد به ماشین؛ باید اونها رو دقیقتر کرد.
—-
مثل همیشه کنجکاو بمونید :)🆔 @MdDaily
