چرا هوش مصنوعی در دست متخصص ابرقدرت و در دست آماتور یک اسباب بازی است

چرا هوش مصنوعی در دست متخصص، ابرقدرت است و در دست آماتور، یک اسباب بازی؟

توهم ساخت در عصر هوش مصنوعی؛ وقتی توانایی تولید یک محصول را با تخصص در مهندسی آن اشتباه می گیریم

تصور کنید شخصی که هیچ دانشی از مهندسی ساختمان ندارد، با کمک هوش مصنوعی نقشه یک برج ۳۰ طبقه را طراحی می کند. نقشه بسیار زیباست، تمام طبقات مشخص هستند، آسانسورها جانمایی شده اند و حتی یک مدل سه بعدی فوق العاده از ساختمان آماده شده است.

آیا این شخص اکنون یک مهندس ساختمان محسوب می شود؟ آیا می توان براساس نقشه او، ساخت برج را شروع کرد؟ چه کسی مقاومت ساختمان در برابر زلزله، فشار باد، وزن سازه و ایمنی ساکنان را تضمین می کند؟

پاسخ روشن است: توانایی تولید یک نقشه، به معنای توانایی مهندسی یک ساختمان نیست.

حالا همین مثال را به دنیای نرم افزار، موسیقی، سینما، پزشکی و سایر صنایع منتقل کنید.

امروز با گسترش ابزارهای هوش مصنوعی مانند ChatGPT و Claude، تقریبا هر فردی می تواند بدون دانش برنامه نویسی، تنها با توضیح ایده های خود، یک وب سایت، اپلیکیشن یا حتی یک سامانه نرم افزاری نسبتا پیچیده تولید کند.

این پیشرفت فوق العاده است، اما یک سوءتفاهم بزرگ نیز ایجاد کرده است.

بسیاری از افراد تصور می کنند چون می توانند چیزی را با هوش مصنوعی بسازند، پس دانش و تخصص لازم برای ساخت، ارزیابی و مدیریت آن را نیز به دست آورده اند.

این همان پدیده ای است که می توان آن را «توهم ساخت» نامید.

۱. تفاوت ساختن با مهندسی کردن چیست؟

فرض کنید دو نفر تصمیم می گیرند یک فروشگاه اینترنتی طراحی کنند.

نفر اول هیچ دانشی از برنامه نویسی ندارد. یک اشتراک ماهانه هوش مصنوعی خریداری می کند و شروع به توضیح خواسته هایش می کند.

بعد از مدتی، یک فروشگاه اینترنتی با طراحی زیبا دارد. کاربران می توانند ثبت نام کنند، محصولات را مشاهده کنند و سفارش ثبت کنند.

نفر دوم یک مهندس نرم افزار باتجربه است که اتفاقا او هم از هوش مصنوعی برای تسریع توسعه پروژه استفاده می کند.

در نگاه اول، ممکن است خروجی هر دو نفر کاملا مشابه باشد.

اما تفاوت اصلی در بخش هایی است که کاربران عادی نمی بینند.

مهندس نرم افزار هنگام توسعه سیستم به موضوعاتی مانند امنیت اطلاعات کاربران، طراحی پایگاه داده، معماری نرم افزار، مدیریت خطاها، پشتیبان گیری، بازیابی اطلاعات، ظرفیت سرورها و توسعه آینده محصول توجه می کند.

او فقط نمی پرسد: «چطور این قابلیت را بسازم؟»

بلکه سوالات مهم تری مطرح می کند:

• اگر هزاران کاربر همزمان وارد سیستم شوند، چه اتفاقی می افتد؟

• اگر ارتباط سرور هنگام پرداخت قطع شود، وضعیت سفارش و پول مشتری چه خواهد شد؟

• اگر فردی تلاش کند به اطلاعات سایر کاربران دسترسی پیدا کند، چه چیزی جلوی او را می گیرد؟

• اگر پایگاه داده آسیب ببیند، چگونه اطلاعات بازیابی می شوند؟

• اگر فردا قرار باشد قابلیت جدیدی اضافه شود، آیا معماری فعلی امکان توسعه بدون تخریب بخش های قبلی را فراهم می کند؟

تفاوت در همین سوالات است.

فرد غیرمتخصص معمولا به دنبال مشاهده نتیجه است؛ متخصص علاوه بر نتیجه، به صحت فرایند، محدودیت ها و پیامدهای آن فکر می کند.

۲. بزرگ ترین مشکل افراد غیرمتخصص: نمی دانند چه چیزهایی را نمی دانند!

این شاید مهم ترین بخش ماجرا باشد.

فرض کنید فردی هیچ دانشی از امنیت سایبری ندارد و با هوش مصنوعی یک سامانه مدیریت اطلاعات مشتریان طراحی می کند.

سامانه به خوبی کار می کند. کاربران وارد حساب خود می شوند، اطلاعاتشان را ثبت می کنند و گزارش می گیرند.

اما ممکن است یک آسیب پذیری امنیتی ساده در آن وجود داشته باشد که به فرد دیگری اجازه دهد اطلاعات سایر مشتریان را مشاهده کند.

در امنیت نرم افزار، یکی از نمونه های چنین مشکلاتی، ضعف کنترل دسترسی به اشیا یا IDOR است.

فردی که با امنیت نرم افزار آشنایی ندارد، ممکن است حتی نداند چنین آسیب پذیری هایی وجود دارند.

پس طبیعتا نمی داند باید برای شناسایی و جلوگیری از آنها چه اقداماتی انجام دهد.

ممکن است بگویید: «خب، از هوش مصنوعی می پرسیم که آیا نرم افزار امن است یا نه!»

اما سوال اصلی همین جا مطرح می شود:

اگر هوش مصنوعی پاسخ دهد که سیستم امن است، فردی که هیچ دانش امنیتی ندارد، از کجا متوجه می شود این ارزیابی درست است؟

هوش مصنوعی می تواند در بررسی امنیت کمک کند، اما تایید خودکار یک سیستم توسط مدلی که در ساخت آن نقش داشته، جایگزین ارزیابی مستقل و تخصصی نمی شود.

متخصص فقط کسی نیست که پاسخ سوالات را می داند؛ متخصص کسی است که می داند چه سوالاتی باید مطرح شوند، چه فرض هایی باید آزمایش شوند و چه خطراتی ممکن است پنهان مانده باشند.

این تفاوت، حاصل تجربه، آموزش و شناخت عمیق یک حوزه است.

«فراتر از آسیب‌پذیری‌های کلاسیک، هوش مصنوعی ریسک‌های امنیتی کاملاً جدیدی را هم وارد چرخه تولید کرده است. برای نمونه، مدل‌های زبانی گاهی دچار توهم (Hallucination) می‌شوند و برای حل یک مسئله، نصب کتابخانه‌ها یا پکیج‌های نرم‌افزاری‌ای را پیشنهاد می‌دهند که در واقعیت وجود ندارند. امروز مهاجمان سایبری همین نام‌های تخیلیِ پرتکرار را در مخازن کد ثبت کرده و درون آن‌ها بدافزار قرار می‌دهند (پدیده‌ای موسوم به Slopsquatting). فرد غیرمتخصص با اجرای کورکورانه دستور نصب پیشنهادیِ AI، عملاً با دست خود درهای سرور را به روی مهاجم باز می‌کند.»

۳. وقتی با هر اصلاح، بخشی از پروژه خراب می شود

یکی از جدی ترین مشکلات توسعه نرم افزار بدون دانش تخصصی، مسئله پسرفت عملکردی یا Regression است.

تصور کنید فردی با کمک هوش مصنوعی یک اپلیکیشن طراحی کرده که ۲۰ قابلیت مختلف دارد.

همه چیز ظاهرا به خوبی کار می کند.

حالا تصمیم می گیرد قابلیت بیست و یکم را به برنامه اضافه کند.

از هوش مصنوعی درخواست می کند تغییرات لازم را اعمال کند. مدل هم کدها را اصلاح می کند و قابلیت جدید اضافه می شود.

اما این تغییر ناخواسته باعث شده دو قابلیت قبلی دچار مشکل شوند.

فرد غیرمتخصص ممکن است اصلا متوجه این مسئله نشود.

چند روز بعد، مشکل دیگری ظاهر می شود. دوباره از هوش مصنوعی کمک می گیرد و تغییرات تازه ای انجام می دهد.

این چرخه می تواند بارها تکرار شود. «دلیل فنی این اتفاق در نحوه کارکرد مدل‌های زبانی نهفته است. هوش مصنوعی برخلاف یک معمار نرم‌افزار، درک ذهنی ثابتی از کل سیستم ندارد و دید آن محدود به حجم مشخصی از اطلاعات (Context Window) است. وقتی پروژه بزرگ می‌شود، مدل برای رفع یک خطای موضعی در فایل فعلی، وابستگی‌های پنهان در فایل‌های دیگر را فراموش می‌کند و برای تحویل یک پاسخ سریع، انسجام کل معماری را قربانی می‌کند.»

در مهندسی نرم افزار، برای کنترل چنین مشکلاتی از روش هایی مانند تست خودکار (Automated Testing)، تست رگرسیون (Regression Testing)، بازبینی کد (Code Review) و مدیریت نسخه (Version Control) استفاده می شود.

البته هوش مصنوعی می تواند در ایجاد و اجرای این تست ها نیز کمک کند.

اما یک مسئله همچنان باقی می ماند:

اگر فرد نداند یک سیستم دقیقا چگونه باید کار کند، چگونه می تواند تشخیص دهد که تست ها تمام رفتارهای مهم آن را به درستی بررسی کرده اند؟

ممکن است تمام تست های موجود موفق باشند، اما یک مشکل اساسی همچنان در سیستم باقی مانده باشد؛ چون اساسا برای آن وضعیت، تست مناسبی طراحی نشده است.

اینجاست که داشتن دانش فنی و قدرت تحلیل اهمیت پیدا می کند.

 

۴. چرا هوش مصنوعی در دست متخصص، ابرقدرت است؟

برای درک بهتر موضوع، از دنیای برنامه نویسی فاصله بگیریم.

موسیقی؛ تفاوت تولید آهنگ با شناخت موسیقی

امروز ابزارهایی مانند Suno می توانند با دریافت چند جمله، یک قطعه موسیقی کامل تولید کنند.

حتی فردی که هیچ دانشی از نت خوانی، آهنگسازی یا تنظیم موسیقی ندارد، می تواند قطعه ای تولید کند که برای مخاطبان جذاب باشد.

اما یک آهنگساز حرفه ای می تواند کارهای بیشتری انجام دهد.

او هارمونی (Harmony)، ملودی (Melody)، ساختار قطعه، ریتم، تنظیم (Arrangement)، میکس (Mixing) و مسترینگ (Mastering) را می شناسد.

می تواند تشخیص دهد کدام بخش آهنگ ضعیف است، کجا باید تنظیم تغییر کند و چگونه می توان خروجی را به سطح حرفه ای نزدیک کرد.

ممکن است فرد غیرمتخصص هم با AI یک آهنگ موفق تولید کند؛ موفقیت هنری همیشه به داشتن مدرک یا آموزش رسمی وابسته نیست.

اما متخصص ابزارهای بیشتری برای کنترل کیفیت، اصلاح آگاهانه و تکرار موفقیت در اختیار دارد.

هوش مصنوعی به هر دو نفر قدرت تولید داده، اما دانش موسیقی به متخصص قدرت هدایت و اصلاح آن تولید را می دهد.

سینما؛ ساخت یک تصویر زیبا با ساخت یک فیلم تفاوت دارد

فردی بدون دانش فیلمسازی می تواند با ابزارهای هوش مصنوعی، یک صحنه سینمایی بسیار جذاب تولید کند.

اما ساخت یک فیلم حرفه ای فقط کنار هم گذاشتن تصاویر زیبا نیست.

کارگردان باید روایت، بازی، نورپردازی، ترکیب بندی، زاویه دوربین، ریتم تدوین و پیوستگی میان صحنه ها را درک کند.

برای مثال، اگر نور یک شخصیت در دو نمای متوالی ناسازگار باشد یا حرکت دوربین با منطق صحنه هماهنگی نداشته باشد، یک فیلمساز باتجربه معمولا سریع تر متوجه مشکل می شود.

هوش مصنوعی ابزار تولید تصویر را فراهم کرده، اما دانش سینما به هنرمند کمک می کند خروجی های پراکنده را به یک اثر منسجم تبدیل کند.

بازارهای مالی؛ وقتی یک ربات سودآور می تواند سرمایه را نابود کند

تصور کنید فردی بدون دانش اقتصاد، آمار و مدیریت ریسک، از هوش مصنوعی می خواهد یک ربات معامله گر طراحی کند.

ربات ساخته می شود و در آزمایش روی داده های گذشته بازار، سود بسیار بالایی نشان می دهد.

فرد تصور می کند یک سیستم معاملاتی فوق العاده ساخته است.

اما یک تحلیلگر مالی متخصص می داند که چنین نتایجی ممکن است به دلایلی مانند بیش برازش (Overfitting)، نشت اطلاعات آینده (Data Leakage)، کارمزد معاملات یا نادیده گرفتن لغزش قیمت (Slippage) گمراه کننده باشند.

ممکن است همان رباتی که در آزمایش های اولیه عالی عمل کرده، در بازار واقعی زیان سنگینی ایجاد کند.

متخصص نیز ممکن است اشتباه کند، اما دانش او کمک می کند خطرات را بهتر شناسایی و نتایج را دقیق تر ارزیابی کند.

حقوق؛ قراردادی که حرفه ای به نظر می رسد

فردی بدون دانش حقوق می تواند با هوش مصنوعی یک قرارداد تجاری طولانی و ظاهرا حرفه ای تولید کند.

اما آیا بندهای قرارداد با قوانین محل اجرا سازگار هستند؟ آیا مسئولیت طرفین به درستی تعریف شده؟ آیا بندهای مختلف با یکدیگر تناقض ندارند؟

وکیل متخصص می تواند با تکیه بر دانش حقوقی، خروجی هوش مصنوعی را بررسی و اصلاح کند.

در تمام این مثال ها، یک اصل مشترک وجود دارد: تولید خروجی آسان تر شده، اما تشخیص کیفیت واقعی همچنان به دانش، تجربه و روش های معتبر ارزیابی نیاز دارد.

۵. یک محصول نرم افزاری فقط مجموعه ای از کدها نیست

یکی از بزرگ ترین سوءبرداشت ها این است که افراد تصور می کنند برای راه اندازی یک کسب و کار نرم افزاری، کافی است یک اپلیکیشن ساخته شود.

در حالی که برنامه نویسی تنها بخشی از چرخه عمر یک محصول است.

فرض کنید با کمک هوش مصنوعی، یک پلتفرم آنلاین ساخته اید.

حالا سوالات مهم تری مطرح می شوند.

زیرساخت و سرورها (Infrastructure)

محصول شما باید در محیطی قابل اعتماد اجرا شود. انتخاب سرور، پیکربندی شبکه، مدیریت منابع، مانیتورینگ، پشتیبان گیری و بازیابی پس از خرابی، همگی به تصمیم های فنی نیاز دارند.

امنیت (Cybersecurity)

اطلاعات کاربران باید محافظت شود. کنترل دسترسی، مدیریت رمزهای عبور، حفاظت از داده ها، مدیریت نشست ها، امنیت API و به روزرسانی وابستگی های نرم افزاری موضوعاتی نیستند که بتوان صرفا با مشاهده ظاهر برنامه درباره آنها قضاوت کرد.

مقیاس پذیری (Scalability)

ممکن است برنامه با ۱۰ کاربر عالی کار کند، اما با افزایش تعداد کاربران به هزاران نفر، دچار کندی یا اختلال شود. اینکه چه زمانی و چگونه باید زیرساخت توسعه پیدا کند، بخشی از مهندسی محصول است.

نگهداری و پشتیبانی (Maintenance & Support)

نرم افزار یک محصول ثابت نیست. خطاهای جدید کشف می شوند، فناوری ها تغییر می کنند، نیازهای کاربران تکامل پیدا می کنند و مشکلات عملیاتی رخ می دهند.

ساخت نسخه اولیه پایان پروژه نیست؛ شروع مسئولیت نگهداری آن است.

بازاریابی و فروش (Marketing & Sales)

حتی اگر بهترین نرم افزار دنیا را بسازید، هیچ تضمینی وجود ندارد که مشتری پیدا کند.

شناخت بازار هدف، تحلیل رقبا، قیمت گذاری، جذب مشتری، حفظ کاربران و تدوین مدل کسب و کار از عوامل اصلی موفقیت یک محصول هستند.

از منظر اقتصادی نیز یک تله پنهان وجود دارد: اگر تمام ارزش یک کسب‌وکار، نرم‌افزاری باشد که یک فرد غیرمتخصص توانسته در چند روز و صرفاً با نوشتن چند پرامپت بسازد، آن محصول هیچ حاشیه امنیت یا «خندق رقابتی» (Competitive Moat) ندارد؛ چرا که هر رقیب دیگری هم می‌تواند فردا صبح با همان ابزارها، کپی برابر اصل آن را در چند ساعت تولید کند. مزیت رقابتی پایدار، دقیقاً در همان لایه‌های پیچیده مهندسی، زیرساخت اختصاصی و امنیتی شکل می‌گیرد که با یک پرامپت ساده قابل کپی‌برداری نیستند.

تجربه کاربری (User Experience)

زیبا بودن ظاهر نرم افزار کافی نیست. محصول باید مشکل واقعی مخاطب را حل کند و استفاده از آن ساده، منطقی و قابل اعتماد باشد.

بنابراین، کسی که تصور می کند با خرید یک اشتراک ماهانه AI تمام مسیر راه اندازی یک کسب و کار نرم افزاری را طی کرده، تنها بخشی از واقعیت را دیده است.

هوش مصنوعی می تواند به تمام این بخش ها کمک کند، اما کمک به تصمیم گیری با تضمین درست بودن تصمیم ها تفاوت دارد.

۶. چرا ساخت نسخه اولیه با ساخت محصول واقعی قابل مقایسه نیست؟

در مهندسی نرم افزار، میان نمونه اولیه (Prototype) و محصول آماده استفاده عملیاتی (Production-Grade Product) تفاوت مهمی وجود دارد.

نمونه اولیه برای نمایش ایده، آزمایش یک قابلیت یا بررسی امکان پذیر بودن یک طرح ساخته می شود.

اما محصول عملیاتی باید بتواند در شرایط واقعی، با کاربران واقعی و مشکلات پیش بینی نشده، عملکرد قابل قبولی داشته باشد.

برای مثال، تصور کنید شخصی با هوش مصنوعی یک پیام رسان طراحی کرده است.

دو نفر می توانند به یکدیگر پیام ارسال کنند. تصاویر منتقل می شوند و حتی تماس صوتی برقرار می شود.

از نگاه کاربر عادی، محصول آماده به نظر می رسد.

اما ساخت یک پیام رسان قابل اعتماد فقط ارسال پیام نیست.

امنیت ارتباطات، تحویل پیام در شرایط اختلال شبکه، مدیریت همزمان کاربران، حفاظت از اطلاعات، مدیریت کلیدهای رمزنگاری، مقابله با سوءاستفاده و بازیابی پس از خرابی، همگی بخشی از پیچیدگی واقعی چنین محصولی هستند.

این موضوع در سامانه های حساس اهمیت بیشتری پیدا می کند.

برای مثال، کسی که دانش مهندسی هوافضا ندارد، ممکن است با AI مدل ظاهری یک فضاپیما یا یک شبیه ساز جذاب بسازد.

اما این به معنای توانایی طراحی و تایید یک فضاپیمای عملیاتی نیست.

در اینجا دیگر ظاهر زیبا یا اجرای موفق یک شبیه سازی به تنهایی اهمیتی ندارد؛ صحت محاسبات، مدل های فیزیکی، آزمون های مهندسی و استانداردهای ایمنی تعیین کننده هستند.

ساخت یک نمونه نمایشی که کار می کند، با ساخت محصولی که بتوان به عملکرد آن اعتماد کرد، یکسان نیست.

۷. وابستگی کامل به هوش مصنوعی؛ وقتی سازنده محصول خودش را نمی شناسد

فرض کنید فردی طی چند ماه با هوش مصنوعی، یک پروژه شامل ده ها هزار خط کد تولید کرده است.

او نمی داند ساختار برنامه چگونه طراحی شده، پایگاه داده چگونه کار می کند یا چرا از فناوری های مشخصی استفاده شده است.

تا زمانی که همه چیز به خوبی اجرا می شود، مشکلی احساس نمی کند.

اما حالا یک خطای پیچیده اتفاق افتاده است.

فرد دوباره به هوش مصنوعی مراجعه می کند.

مدل یک راه حل پیشنهاد می دهد. او اجرا می کند، اما مشکل حل نمی شود.

راه حل دوم ارائه می شود و این بار برنامه اجرا می شود، ولی قابلیت دیگری از کار می افتد.

ممکن است مدل بعدی راه حل متفاوتی ارائه دهد یا تغییرات قبلی را نامناسب تشخیص دهد.

چنین وضعیتی همیشه رخ نمی دهد و ابزارهای پیشرفته AI می توانند بسیاری از مشکلات را با موفقیت برطرف کنند. اما وقتی فرد هیچ درکی از سیستم ندارد، توانایی او برای تشخیص اینکه کدام تغییر صحیح و قابل اعتماد است، محدود می شود.

این وضعیت را می توان بحران مالکیت فنی (Technical Ownership) نامید.

فرد مالک فایل ها و کدهای پروژه است، اما درک و کنترل فنی کافی بر محصولی که ساخته ندارد.

مشکل دیگر، انباشت بدهی فنی (Technical Debt) است.

گاهی برای اینکه یک قابلیت سریع تر ساخته شود، راه حل هایی انتخاب می شوند که در کوتاه مدت جواب می دهند، اما توسعه و نگهداری آینده پروژه را دشوارتر می کنند.

با افزایش این تصمیم ها، ممکن است هزینه اصلاح و توسعه نرم افزار به شدت افزایش پیدا کند.

در چنین شرایطی، صرف داشتن کدهای پروژه به معنای توانایی مدیریت آینده آن نیست.

۸. آیا یعنی افراد غیرمتخصص نباید از AI برای ساخت محصول استفاده کنند؟

قطعا نه.

این نتیجه گیری کاملا اشتباه است.

هوش مصنوعی یکی از ارزشمندترین ابزارهایی است که برای یادگیری، آزمایش ایده ها و کاهش هزینه تولید در اختیار انسان قرار گرفته است.

یک فرد غیرمتخصص می تواند با کمک AI یک وب سایت شخصی، ابزار ساده، نمونه اولیه یا حتی محصولی تجاری بسازد که در بازار موفق شود.

اما میان این دو طرز فکر تفاوت اساسی وجود دارد:

فرد اول می گوید: «با کمک هوش مصنوعی توانستم چیزی بسازم که قبلا نمی توانستم.»

فرد دوم می گوید: «چون هوش مصنوعی می تواند همه چیز را برای من بسازد، دیگر نیازی به دانش و تخصص ندارم.»

طرز فکر اول نشانه استفاده درست از فناوری است.

طرز فکر دوم می تواند به تصمیم های پرهزینه منجر شود.

هرچه محصول پیچیده تر، حساس تر و وابسته تر به اطلاعات و سرمایه کاربران باشد، اهمیت ارزیابی تخصصی نیز بیشتر می شود.

البته قرار نیست یک بنیانگذار به تنهایی متخصص تمام حوزه ها باشد. او می تواند از تیم مهندسی، متخصصان امنیت، مشاوران حقوقی و کارشناسان کسب و کار کمک بگیرد.

اما موضوع این مقاله مشخصا افرادی هستند که بدون داشتن تخصص و بدون استفاده از کمک متخصصان، تصور می کنند هوش مصنوعی به تنهایی می تواند جای تمام دانش مورد نیاز برای ساخت و اداره یک محصول پیچیده را بگیرد.

۹. وقتی یک متخصص از هوش مصنوعی استفاده می کند، چه تفاوتی ایجاد می شود؟

نکته مهم اینجاست که مقایسه واقعی، میان «مهندس انسان» و «هوش مصنوعی» نیست.

چون مهندسان حرفه ای نیز می توانند از هوش مصنوعی استفاده کنند.

مقایسه واقعی میان این دو وضعیت است:

فردی که بدون دانش تخصصی، تمام تصمیم های فنی را به AI واگذار می کند؛ و متخصصی که از AI برای افزایش سرعت و قدرت مهندسی خود بهره می برد.

یک مهندس نرم افزار ممکن است از هوش مصنوعی برای نوشتن کد، طراحی تست ها، شناسایی خطاها، مستندسازی و بررسی معماری استفاده کند.

اما در عین حال می تواند خروجی را نقد کند، پیشنهادهای نامناسب را رد کند و درباره پیامدهای فنی تصمیم بگیرد.

هوش مصنوعی برای چنین فردی یک ابزار افزایش بهره وری و قدرت تحلیل است.

در مقابل، فردی که هیچ شناختی از فناوری ندارد، ممکن است نتواند بین یک پاسخ دقیق و یک پاسخ ظاهرا قانع کننده اما اشتباه تمایز قائل شود.

به بیان ساده:

متخصص از هوش مصنوعی استفاده می کند تا کارهایی را که می فهمد، سریع تر و بهتر انجام دهد. فرد غیرمتخصص ممکن است از هوش مصنوعی استفاده کند تا کارهایی را انجام دهد که حتی درستی آنها را نمی تواند ارزیابی کند.

البته تخصص نیز تضمین نمی کند که محصول بدون خطا خواهد بود. مهندسان حرفه ای هم اشتباه می کنند. تفاوت در این است که دانش، تجربه و فرایندهای مهندسی به آنها ابزارهای بیشتری برای کشف، پیشگیری و اصلاح خطاها می دهد.

۱۰. آیا اشتراک ماهانه هوش مصنوعی جای هزینه توسعه حرفه ای را می گیرد؟

یکی از پرسش های رایج امروز این است:

«وقتی می توانم با پرداخت هزینه اشتراک یک ابزار AI نرم افزار خودم را بسازم، چرا باید برای توسعه حرفه ای آن هزینه کنم؟»

پاسخ به این سوال بستگی به نوع پروژه دارد.

برای ساخت یک ابزار شخصی یا نمونه اولیه ساده، شاید استفاده مستقیم از هوش مصنوعی انتخابی کاملا منطقی و اقتصادی باشد.

اما اگر قرار است یک پلتفرم تجاری با کاربران واقعی، اطلاعات حساس، تراکنش های مالی و نیاز به پشتیبانی مستمر راه اندازی شود، موضوع متفاوت خواهد بود.

هزینه توسعه حرفه ای صرفا هزینه تایپ کردن کد نیست.

بخشی از این هزینه مربوط به تحلیل نیازمندی ها، طراحی معماری، کنترل کیفیت، امنیت، تست، استقرار، مستندسازی و کاهش ریسک های آینده است.

هنگامی که یک متخصص توسعه پروژه را بر عهده می گیرد، ارزش کار او فقط در تعداد خطوط کدی نیست که تولید کرده است.

ارزش مهم تر در تصمیم هایی است که می گیرد، مشکلاتی که پیش بینی می کند و خطاهایی که پیش از تبدیل شدن به بحران شناسایی می شوند.

البته کیفیت خدمات متخصصان نیز یکسان نیست و پرداخت هزینه بالا به خودی خود تضمین کننده کیفیت نیست. تخصص باید با سابقه، روش کار، مستندات، تست و نتایج قابل ارزیابی همراه باشد.

پس پرسش اصلی این نیست که اشتراک AI ارزان تر است یا استخدام یک مهندس.

پرسش دقیق تر این است:

هزینه واقعی ساخت، راه اندازی، امنیت، نگهداری و توسعه محصول در طول عمر آن چقدر خواهد بود؟

گاهی یک پروژه ارزان که بدون معماری و نظارت مناسب ساخته شده، در آینده هزینه اصلاح بسیار بیشتری ایجاد می کند.

هوش مصنوعی تخصص را حذف نکرده؛ ارزش آن را تغییر داده است

ما در دورانی زندگی می کنیم که فاصله میان داشتن یک ایده و مشاهده نمونه اولیه آن، به شکل چشمگیری کاهش پیدا کرده است.

این یک تحول تاریخی است.

اما نباید فراموش کنیم که کاهش دشواری تولید، لزوما به معنای کاهش دشواری مهندسی، اعتبارسنجی و مدیریت یک محصول نیست.

در گذشته، بخش قابل توجهی از ارزش یک برنامه نویس در توانایی نوشتن کد بود.

امروز که هوش مصنوعی می تواند مقدار زیادی کد تولید کند، اهمیت مهارت هایی مانند طراحی معماری، تحلیل مسئله، امنیت، ارزیابی کیفیت و تصمیم گیری فنی برجسته تر شده است.

این اتفاق تنها به برنامه نویسی محدود نیست.

در موسیقی، دانش آهنگسازی؛ در سینما، شناخت زبان تصویر؛ در حقوق، قدرت تحلیل قانونی؛ و در مهندسی، توانایی سنجش صحت و ایمنی همچنان اهمیت دارند.

هوش مصنوعی می تواند توانایی افراد را افزایش دهد، اما نباید استفاده از یک ابزار قدرتمند را با تسلط بر دانشی که پشت آن قرار دارد اشتباه گرفت.

موضوع این نیست که فرد غیرمتخصص هرگز نمی تواند محصول موفقی بسازد. موضوع این است که موفقیت اولیه، ظاهر حرفه ای و عملکرد صحیح چند قابلیت، به تنهایی ثابت نمی کنند که یک محصول از نظر مهندسی قابل اعتماد، امن و قابل توسعه است.

به همین دلیل، قبل از اینکه با افتخار بگوییم «من این محصول را فقط با هوش مصنوعی ساختم»، بهتر است از خودمان بپرسیم:

اگر فردا یک مشکل امنیتی جدی کشف شود، آیا توانایی تشخیص و رفع آن را دارم؟

اگر محصول زیر بار کاربران واقعی دچار اختلال شود، آیا می دانم مشکل از کجاست؟

اگر هوش مصنوعی راه حل اشتباهی ارائه دهد، آیا دانش کافی برای تشخیص آن دارم؟

و مهم تر از همه:

اگر هوش مصنوعی محصولی را برای من ساخته که حتی منطق و زیرساخت آن را درک نمی کنم، بر چه اساسی می توانم درباره صحت، امنیت و کیفیت آن ادعا کنم؟

این سوالات مرز میان تولید یک خروجی و مسئولیت پذیری در قبال یک محصول واقعی را مشخص می کنند.

هوش مصنوعی در دست متخصص، یک ابرقدرت است؛ زیرا دانش و تجربه او را تقویت می کند. اما در دست فردی که بدون تخصص و بدون نظارت حرفه ای، صرفا به تولید خروجی دل خوش کرده، ممکن است چیزی فراتر از یک اسباب بازی پیشرفته نباشد.

در نهایت، مهم نیست چه کسی یا چه ابزاری کد را نوشته است.

مهم این است که چه کسی می تواند درستی آن را اثبات کند، مسئولیت عملکردش را بپذیرد و در شرایط واقعی از آن نگهداری کند.