پیچیدگی، سقفِ کاریه که به هوش مصنوعی میسپاری
هوش مصنوعیخلاصهٔ کاملتر
نویسنده که خودش رهبری تیم مهندسی هوش مصنوعی تو یه شرکت تحقیقات حقوقیه، با این جملهٔ پرتکرار که «حالا کد ارزونه پس خودِ کد دیگه مهم نیست» مخالفه. به گفتهٔ اون نوشتن کد ارزونه، ولی فهمیدنش و تغییرش بدون خرابکردن یه جای دیگه ارزون نیست — و یه مدل قبل از اینکه بتونه یه codebase رو با خیال راحت تغییر بده، باید اول بفهمدش. پس پیچیدگی سیستم همون سقفیه که تعیین میکنه چهقدر از کار رو میتونی به ماشین بسپاری.
نویسنده برمیگرده به مقالهٔ معروف «No Silver Bullet» از Fred Brooks تو سال ۱۹۸۷. بروکس سختی ساخت نرمافزار رو دو جور میدونه: پیچیدگی عَرَضی (accidental) که ابزارها بهمون تحمیل میکنن مثل سینتکس و boilerplate، و پیچیدگی ذاتی (essential) که خود مسئله میطلبه یعنی فهمیدن اینکه سیستم باید چیکار کنه و طراحی ساختاری که موقع رشد دووم بیاره. حرفش اینه که ابزارها فقط از پیچیدگی عَرَضی میزنن، و پیچیدگی ذاتی که بخش اصلی کاره دستنخورده میمونه.
نویسنده میگه دستیارهای کدنویسی هوش مصنوعی مؤثرترین حمله به پیچیدگی عَرَضیان، ولی سراغ تعریف John Ousterhout میره: پیچیدگی یعنی هر چیزی تو ساختار سیستم که فهمیدن یا تغییرش رو سخت میکنه. این پیچیدگی خودشو بهصورت تقویتِ تغییر (یه تغییر کوچیک، ویرایش تو کلی جا رو مجبور میکنه)، بار شناختی، و «مجهولاتِ ناشناخته» نشون میده. به گفتهٔ نویسنده هوش مصنوعی این حسابوکتاب رو بدتر میکنه، چون مدل خیلی بیشتر و سریعتر از آدم کد تولید میکنه و در نتیجه سطح بیشتری برای فهمیدن و جاهای بیشتری میمونه که یه تغییر میتونه بهشون برسه.
یه تمایز کلیدی که از اوسترهات نقل میکنه، برنامهنویسِ تاکتیکی در برابر استراتژیکه. برنامهنویس تاکتیکی فقط کاری میکنه که تسک فعلی کار کنه و رد میشه؛ استراتژیک یهخرده انرژی بیشتر میذاره که ساختار تمیز بمونه تا تغییر بعدی ارزونتر باشه. نویسنده معتقده یه مدل زبانی بهطور پیشفرض یه برنامهنویس کاملاً تاکتیکیه: یه بلوک رو کپی میکنه بهجای اینکه ایدهٔ مشترک رو فاکتور بگیره، یا یه پارامتر دیگه اضافه میکنه بهجای بازطراحی interface. این همون چیزیه که The Pragmatic Programmer بهش میگه آنتروپی نرمافزار.
نویسنده به یه مطالعهٔ ۲۰۲۶ اشاره میکنه که بیش از ۳۰۰٬۰۰۰ کامیتِ نوشتهشده توسط هوش مصنوعی رو تو بیش از ۶٬۰۰۰ ریپازیتوری عمومی بررسی کرده: بیش از پونزده درصد کامیتها حداقل یه مشکل جدید اضافه کرده بودن و نزدیک نُهتا از هر ده مشکل، code smell بوده — مشکلات ساختاری که کامپایل میشن و تستها رو پاس میکنن ولی کد رو سختتر میکنن. یعنی کد کار میکنه ولی طراحی بیسروصدا داره خراب میشه.
راهحلی که نویسنده از اوسترهات میگیره، ماژول عمیق (deep module) ـه: یه واحد با interface ساده که یه پیادهسازی قدرتمند رو پشتش پنهان میکنه. این ایده به مقالهٔ David Parnas تو ۱۹۷۲ برمیگرده که گفت سیستم باید بر اساس تصمیمهایی که هر بخش میتونه از بقیه پنهان کنه تقسیم بشه، نه بر اساس مراحل محاسبه. نویسنده میگه همین عمق تعیین میکنه چهقدرش رو میتونی به هوش مصنوعی بسپاری: یه ماژول عمیق مثل یه «جعبهٔ خاکستری»ـه که فقط لبههاش و بخشهای پرریسکش رو بازبینی میکنی و بقیهش میتونه پیچیده بمونه. برعکس، تو کد درهموبرهم مدل نمیتونه بفهمه چی به چی وابستهست و بدتر از همه، در حالی که انگار داره کمک میکنه کارو بیسروصدا خرابتر میکنه.
شواهد این «سقف» هم رسیده. تو یه آزمایش تصادفیکنترلشده از METR تو اوایل ۲۰۲۵، شونزده توسعهدهندهٔ باتجربه رو ریپازیتوریهایی که خوب میشناختن کار کردن؛ انتظار داشتن ابزار حدود یکپنجم سریعترشون کنه ولی در عمل حدود همون مقدار کندترشون کرد. نویسنده میگه نکته این نیست که هوش مصنوعی همیشه آدمو کند میکنه، بلکه پیچیدگی سیستمه که تعیین میکنه کمک میکنه یا نه — گزارش DORA گوگل ۲۰۲۵ هم هوش مصنوعی رو یه تقویتکننده میدونه که اونجا که بنیان مهندسی تیم قویه throughput رو بالا میبره و اونجا که ضعیفه بیثباتی رو بیشتر میکنه. جمعبندی نویسنده اینه که طراحی شده «معرفِ محدودکننده»، و همون بخشی از کاره که هنوز مال ماست.
نکات کلیدی:
- هوش مصنوعی نوشتن کد رو ارزون کرده، ولی فهمیدن و تغییر امنِ سیستم رو نه
- پیچیدگی یه سیستم سقفِ کاریه که میشه بدون نظارت به مدل سپرد
- مدلها بهطور پیشفرض برنامهنویس تاکتیکیان و آنتروپی نرمافزار رو بیشتر میکنن
- یه مطالعهٔ بزرگ نشون داد بیشتر مشکلاتِ کدِ هوش مصنوعی، code smellهای ساختاریان
- ماژولهای عمیق با interface ساده، سطحِ کاری رو که میشه به مدل سپرد بالا میبرن
- خروجی بازبینینشده تمومهشده نیست؛ اعتماد جای تأیید رو نمیگیره
