آخرین مهارتی که هوش مصنوعی نمی‌تونه ازت بگیره
هوش مصنوعی
فرانتاندخلاصهٔ کامل‌تر
کنت سی. دادز بیش از یه دهه‌ست که به مهندس‌های نرم‌افزار یاد می‌ده چطور تست بنویسن، با ری‌اکت و Remix کار کنن و ویژگی‌های واقعی بسازن. روش آموزشیش همیشه شبیه‌سازی محیط کار واقعی بود: یه مدیر محصول یه تسک بهت می‌ده، مستندات رو می‌خونی، توی کدبیس کار می‌کنی و بعد راه‌حلت رو با راه‌حل اون مقایسه می‌کنی. این روش ارزشمند بود چون پیاده‌سازی ارزشمند بود. هنوزم هست. ولی دیگه کمیاب نیست.
دادز می‌گه ایجنت‌های کدنویس هوش مصنوعی دارن آروم‌آروم کارهایی رو که مهندس‌های نرم‌افزار دهه‌هاست انجام می‌دن، می‌بلعن. یه سال پیش کمتر کسی پیش‌بینی می‌کرد که ایجنت‌ها این‌قدر توی پیاده‌سازی قوی بشن. همین تجربه بهش ثابت کرده که نمی‌تونه با اطمینان بگه یه سال دیگه کجا خواهیم بود.
اما به جای اینکه نگران «بعد از اینکه مهندسی نرم‌افزار تموم شد چی میشه؟» باشه، یه سوال متفاوت می‌پرسه: «درست یه قدم قبل از اون لحظه، چه چیزی هنوز ارزش داره؟» جواب این سوال، بادوام‌ترین چیزیه که می‌تونه یاد بده.
اگه زمان رو جلو ببریم تا جایی که هوش مصنوعی تمام کارهای فعلی مهندس‌های نرم‌افزار رو انجام می‌ده، و بعد یه قدم به عقب برگردیم، آخرین چیز ارزشمندی که «آخرین مهندس نرم‌افزار» داره چیه؟ نه تایپ کردن کد، نه انتخاب کتابخانه، نه حتی طراحی پیاده‌سازی. آخرین چیز ارزشمند «قضاوت» هست: تصمیم‌گیری درباره اینکه چی ارزش ساختن داره، کدام محدودیت‌ها نباید نقض بشن، کدام مبادله‌ها قابل قبولن و چه آسیبی می‌تونه موفقیت رو بی‌معنا کنه.
دادز با استعاره‌ی تیراندازی این تغییر رو توضیح می‌ده: مدت‌هاست مهندس‌ها مثل تیراندازا بر اساس دقت نشانه‌گیریشون قضاوت می‌شدن. بهشون هدف می‌دادن و کار اونا این بود که تیر رو درست بزنن. ایجنت‌های هوش مصنوعی دارن پیاده‌سازی رو به یه تیر هوشمند تبدیل می‌کنن که خودش راهش رو پیدا می‌کنه. وقتی تیرها می‌تونن خودشون هدایت بشن، مهارت کمیاب دیگه «دقت دست» نیست، بلکه «انتخاب هدف درست» هست.
این یعنی مهندسی نرم‌افزار به‌عنوان پیاده‌سازی داره جاش رو به «مهندسی محصول به‌عنوان قضاوت» می‌ده. سوال دیگه فقط این نیست که «آیا می‌تونی به هدفت بزنی؟» بلکه اینه که «آیا اصلاً این هدف باید وجود داشته باشه؟ آیا زدن به این هدف چیز دیگه‌ای رو خراب می‌کنه؟ آیا هدف بهتری در همون نزدیکی هست؟»
اما چرا «باید» رو سخته که به اتوماسیون سپرد؟ چون «باید» یعنی انتخاب یه آینده‌ی ممکن به جای آینده‌ی دیگه‌ای و پذیرش عواقب اون انتخاب. این کار به قضاوت و تعادل بین محدودیت‌های مختلف نیاز داره. اطلاعات مرتبط هم اغلب درون پرامپت نیستن؛ انتظارات کاربرها، مدل کسب‌وکار، اعتماد به برند، ظرفیت تیم، ریسک‌های قانونی و هزار قول کوچیکی که یه محصول در طول زمان داده بدون اینکه جایی نوشته باشه.
مسئله‌ی دیگه «مسئولیت‌پذیری» هست. سیستمی که هزینه‌ی اشتباه بودنش رو نمی‌پردازه، می‌تونه یه انتخاب بهینه‌ی محلی پیشنهاد بده که هیچ مالک مسئولی نباید قبولش کنه. یه باگ‌فیکس برای یه کاربر می‌تونه برای کاربر دیگه‌ای یه تغییر ورک‌فلو بشه. یه ویژگی جدید برای یه مشتری می‌تونه پیچیدگی کدبیس رو برای بقیه زیاد کنه. مهندس محصول کسیه که می‌دونه چطور این اثرات انسانی و فنی رو قبل از اینکه پیاده‌سازی اونا رو به واقعیت تبدیل کنه، بسنجه.
نکات کلیدی:
- هوش مصنوعی داره پیاده‌سازی نرم‌افزار رو کمیاب‌زدایی می‌کنه، ولی قضاوت رو نه
- آخرین مهارت ارزشمند مهندس نرم‌افزار «دانستن اینکه چی باید ساخته بشه» هست، نه «چطور ساخته بشه»
- وقتی هزینه‌ی پیاده‌سازی کم میشه، انتخاب هدف درست اهمیت بیشتری پیدا می‌کنه
- تصمیم‌گیری درباره‌ی «باید» نیازمند اطلاعاتی هست که اغلب بیرون از پرامپت زندگی می‌کنن
- مسئولیت‌پذیری هم یه عامل کلیدیه که اتوماسیون کامل رو سخت می‌کنه
- این تغییر پارادایم از «مهندسی نرم‌افزار به‌عنوان پیاده‌سازی» به «مهندسی محصول به‌عنوان قضاوت» هست
