کد ارزون شده، فهمیدنش گرون
هوش مصنوعیخلاصهٔ کاملتر
تو این مقاله، کارسن گراس (سازندهی htmx) میگه نمیشه این واقعیتو انکار کرد که طی یه سال گذشته تولید کد خیلی ارزونتر شده؛ هوش مصنوعی میتونه با سرعت باورنکردنی حجم زیادی کد با کیفیت نسبتاً قابلقبول تولید کنه. نویسنده با این حرفِ رایج که «کدنویسی اصلاً مشکل نبود» کاملاً موافق نیست و میگه کدنویسی دستکم بخشی از مشکل بوده — و حالا اون بخش با ابزارهای کدنویسی هوش مصنوعی خیلی کوچیک شده.
به نظر نویسنده، نتیجهی کماهمیتتر شدنِ خود کدنویسی اینه که «فهمیدن» کد گرونتر شده. وقتی کلی کد تولید میشه — بهجای اینکه بهسختی از انگشتای یه برنامهنویس بیرون بیاد — هیچ درکی از اون کد وجود نداره، و اگه قراره این درک شکل بگیره باید بعد از نوشتهشدن کد و با خوندنش به دست بیاد. عقل متعارف هم میگه خوندن کد یکی دیگه از نوشتن کد خودت سختتره.
نویسنده با این استدلالِ بعضی طرفدارای هوش مصنوعی که «مگه خروجی کامپایلرا رو میفهمی؟» مخالفه و اونو یه خطای مقولهای میدونه: کامپایلرها قطعیان ولی مدلهای زبانی ذاتاً غیرقطعیان؛ تو جریان کاری کامپایلر سورسکد اصلی حفظ میشه ولی تو جریان کاری مدل زبانی معمولاً نه؛ و خروجی کامپایلر تو یه دامنهی محدوده (کد ماشین) ولی خروجی مدل زبانی نرمافزار عمومیه. به همین خاطر توصیه میکنه از مدلهای زبانی بهصورت تدریجی استفاده بشه، نه اینکه بذاری تغییرات عظیمی تولید کنن که نه تو و نه کس دیگهای نمیتونه بفهمدشون.
نویسنده برای توصیف این خطر سراغ صحنهی «شاگرد جادوگر» تو انیمیشن Fantasia میره: شاگردی که برای فرار از کار نظافت یه جارو رو جادو میکنه و اولش همهچی خوب پیش میره تا اینکه جارو از کنترل خارج میشه و همهجا رو غرق آب میکنه، و آخرش جادوگرِ اصلی برمیگرده و اوضاعو کنترل میکنه. پیام این استعاره اینه که تو عصر هوش مصنوعی باید جادوگر باشی نه شاگرد — و جادوگر باید کد رو بفهمه.
به گفتهی نویسنده، خطر اصلیِ ارزونشدن کد، پیچیدگیه؛ چیزی که ادعا میکنه دستکم بهصورت هندسی و اغلب نمایی با اندازهی سیستم رشد میکنه. قبل از مدلهای زبانی هم برنامهنویسای پُرکار بودن که بدون ترس درست از پیچیدگی، اونقدر کد رو روی هم تلنبار میکردن تا کل سیستم به یه حالت غیرقابلتغییر فرو بریزه که هر تغییری بهاندازهای که باگ درست میکنه باگ هم میسازه. مدلهای زبانی هم پُرکارن و هم اصلاً ترسی از پیچیدگی ندارن، و همین خطرناکه.
راهحلی که نویسنده پیشنهاد میده «مهندسِ کمکننده و محدودکننده»ست: کسی که «نه» میگه، خروجی مدل زبانی رو با دقت بررسی میکنه، سادهسازی پیشنهاد میده و دستشو محکم رو کار نگه میداره. این مهندس بهجای افتخار به کدی که میسازه، به کد و لایههایی که از سیستم حذف میکنه یا جلوی ورودشون رو میگیره افتخار میکنه — یه ذهنیتِ مجسمهساز، نه سازنده. نویسنده میگه این رویکرد هنرِ برنامهنویسی رو حفظ میکنه و همزمان دو واقعیتو میپذیره: کد خیلی ارزونتر شده، و پیچیدگی هنوز شکارچی اصلی ماست.
نکات کلیدی:
- نویسنده میگه با هوش مصنوعی تولید کد ارزون شده، ولی «فهمیدن» کد گرونتر شده
- خوندن و درک کدِ تولیدشده از نوشتنش سختتره و مدل میتونه سریعتر از فهم آدم کد بسازه
- استفادهی تدریجی از مدل زبانی توصیه میشه، نه تولید تغییرات عظیم و نامفهوم
- خطر اصلی، رشد هندسی یا نمایی پیچیدگی با بزرگتر شدن سیستمه
- راهحل، «مهندسِ کمکننده»ست که به حذف کد افتخار میکنه نه به اضافهکردنش
