‏بدهی فنی پنهان: وقتی هوش مصنوعی کد IoT رو خراب می‌کنه

در ۴ ژوئن ۱۹۹۶، موشک آریان ۵ کمتر از ۴۰ ثانیه پس از پرتاب منفجر شد. علت؟ یک ماژول نرم‌افزاری از نسخه قبلی بدون بررسی سازگاری با محیط جدید بازاستفاده شده بود. نه کد بدی بود، نه باگ آشکاری داشت — فقط با context جدید هماهنگ نبود. این داستان سی‌ساله، درس امروزی جالبی برای توسعه‌دهنده‌هایی داره که از ابزارهای هوش مصنوعی استفاده می‌کنن.

ابزارهای AI مثل GitHub Copilot کد کارکردی تولید می‌کنن که در سطح یه تابع یا سرویس منفرد درست به نظر می‌رسه، ولی نه معماری کلی سیستم رو می‌بینن، نه محدودیت‌های سخت‌افزاری رو حساب می‌کنن. در دنیای IIoT و نگهداری پیشگویانه، این مسئله می‌تونه از یه باگ محلی تبدیل بشه به یه شکست سیستمی گران‌قیمت.

۱. تکرار الگوهای قدیمی و اشتباهات میراثی

AI بر اساس کدی که می‌بینه پیشنهاد می‌ده. اگه پروژه‌ای شامل رویکردهای منسوخ یا workaroundهای بد معماری باشه، مدل اون‌ها رو به‌عنوان نُرم می‌شناسه و تکثیر می‌کنه. GitHub خودش تصریح کرده که Copilot می‌تونه اشتباهات و تعصبات ریپازیتوری‌های موجود رو به ارث ببره. یه تحقیق روی ۳۰۴ هزار کامیت تأییدشده از بیش از ۶۰۰۰ ریپازیتوری واقعی نشون داد که بیش از ۱۵٪ از کامیت‌های هر پنج ابزار AI ارزیابی‌شده حداقل یه مشکل کیفی داشتن — و یه‌چهارم اون‌ها در نسخه نهایی کد هم رفع نشدن.

۲. راه‌حل‌های موضعی بدون دید معماری

AI در حل مشکلات مهندسی محلی عالیه: تست بنویس، بویلرپلیت بساز، endpoint استاندارد CRUD تحویل بده. ولی معماری رو نمی‌بینه. یه مطالعه از Ox Security روی ۳۰۰ پروژه اوپن‌سورس نشون داد که کد AI کارکردی بود ولی به‌طور سیستماتیک فاقد قضاوت معماری بود. در IIoT این یعنی: وقتی از مدل می‌خوای داده جدیدی ذخیره کنه، از وجود دیتابیس‌های جداگانه بهینه‌شده برای time series، reference data و لاگ‌ها بی‌خبره و کدی می‌نویسه که آروم‌آروم قراردادهای معماری تیم رو نقض می‌کنه.

۳. دوپلیکیشن منطق و پیچیدگی نگهداری

AI نمی‌دونه که همین منطق جای دیگه‌ای از سیستم وجود داره، پس دوباره می‌نویسه. تحلیل GitClear روی ۲۱۱ میلیون خط کد تغییریافته از ۲۰۲۰ تا ۲۰۲۴ نشون داد که سهم کد تکراری از ۸.۳٪ به ۱۲.۳٪ رسیده. سال ۲۰۲۴ اولین سالی بود که مقدار کد تکراری از مقدار ریفکتورینگ بیشتر شد. در IoT، اگه منطق پارس‌کردن پکت یا اعتبارسنجی اتصال در چند جای مختلف مستقل پیاده شده باشه، رفع باگ در یه نسخه بدون پیدا کردن بقیه می‌تونه باعث بشه دستگاه‌های میدانی تحت ورودی یکسان رفتار متفاوت داشته باشن.

۴. نادیده گرفتن محدودیت‌های سخت‌افزاری

دستگاه‌های IoT حافظه، پهنای باند و باتری محدودی دارن. AI این محدودیت‌ها رو فقط وقتی حساب می‌کنه که توسعه‌دهنده صراحتاً بگه. وگرنه مدل برای محیطی کد می‌نویسه که بیشتر باهاش آشناست: سرورهای ابری با حافظه عملاً نامحدود و شبکه پایدار. نتیجه؟ حلقه‌های retry بی‌پایان بدون timeout، فرمت‌های متنی سنگین به‌جای پروتکل‌های باینری فشرده، و کدی که در emulator درست کار می‌کنه ولی روی برد فیزیکی با منابع محدود خراب می‌شه.

چطور از این بدهی فنی جلوگیری کنیم؟

اول: کد ریویو اجباری انسانی — و نه فقط «آیا کامپایل می‌شه؟» بلکه بررسی سازگاری با سخت‌افزار، عدم تکرار منطق، و انطباق با معماری کلی. بر اساس یه تحقیق روی بیش از ۱۱۰۰ توسعه‌دهنده، فقط ۴۸٪ همیشه کد AI-generated رو قبل از کامیت ریویو می‌کنن. طبق LeadDev، ۲۹٪ از سازمان‌ها الان بیشتر از قبل وقت صرف کد ریویو می‌کنن، که نشون می‌ده این فرآیند به‌تنهایی به یه bottleneck تبدیل می‌شه.

دوم: تعریف «مناطق ممنوعه» برای تولید خودکار AI — بخش‌هایی مثل پردازش پکت‌های ورودی دستگاه‌ها، منطق احراز هویت، مدیریت وقفه و watchdog timer، و هر کدی که مستقیماً با firmware تعامل داره باید از دسترس تولید خودکار AI دور بمونن.

نکات کلیدی:

• کد AI ممکنه محلی درست باشه ولی با معماری، سخت‌افزار یا قراردادهای سیستمی ناسازگار باشه
• بیش از ۱۵٪ کامیت‌های AI-generated حداقل یه مشکل کیفی دارن و یه‌چهارم اون‌ها رفع نمی‌شن
• سهم کد تکراری از ۸.۳٪ به ۱۲.۳٪ رسیده و ۲۰۲۴ اولین سالی بود که duplication از refactoring پیشی گرفت
• AI محدودیت‌های سخت‌افزاری IoT رو فقط وقتی رعایت می‌کنه که به‌صراحت در پرامپت مشخص شده باشن
• کد ریویو انسانی ضروریه ولی بدون ابزارهای خودکار به‌سرعت تبدیل به گلوگاه می‌شه
• بخش‌های حیاتی پروژه IoT باید به‌صراحت از تولید خودکار AI محروم بشن