یک برنامه‌نویس از هوش مصنوعی می‌خواهد قابلیتی تازه برای نرم‌افزار بسازد؛ چند ثانیه بعد، ده‌ها خط کد مرتب جلوی چشمش ظاهر می‌شود. کد اجرا می‌شود و در نگاه اول همه‌چیز درست به‌نظر می‌رسد؛ اما بعدتر مشخص می‌شود اطلاعات کاربران درست بررسی نمی‌شوند و یک تغییر کوچک، بخش دیگری از سامانه را از کار می‌اندازد.
در میان تبلیغات و هیاهوی هوش مصنوعی، یک واقعیت از نظرها دور می‌ماند: هوش مصنوعی در تولید کد، خلاصه‌سازی و انجام کارهای تکراری بسیار سریع است؛ اما سرعت تولید فقط بخشی از کار است. فهمیدن اینکه چه چیزی باید ساخته شود، چه خطرهایی دارد و چگونه با بخش‌های دیگر یک سامانه هماهنگ می‌شود، همچنان نیازمند شناخت و داوری انسانی است.
پارادوکس سرعت و کیفیت
ابزارهایی مانند «گیت‌هاب کوپایلوت»، «کلاود» و «کرسر» می‌توانند کدهای تکراری بسازند، آزمون اولیه بنویسند و برای یافتن خطا پیشنهاد بدهند. این توانایی‌ها به برنامه‌نویس کمک می‌کنند بعضی کارها را سریع‌تر پیش ببرد، اما هر خط از کد همچنان باید بررسی، آزمایش و نگهداری شود.
گزارش سال ۲۰۲۵ موسسه DORA (وابسته به گوگل) هوش مصنوعی را یک «تقویت‌کننده» توصیف می‌کند: تیم‌های منظم می‌توانند با کمک آن بهتر عمل کنند، اما ضعف تیم‌هایی که آزمون‌های ناقص، فرایندهای مبهم و معماری شکننده دارند نیز بیشتر به چشم می‌آید. در واقع در بررسی این موسسه، استفاده از هوش مصنوعی با افزایش «سرعت تحویل نرم‌افزار» همراه بود، اما همچنان رابطه‌ای منفی با «ثبات انتشار» داشت.
به بیان ساده، هوش مصنوعی می‌تواند تولید را سریع‌تر پیش ببرد، اما اگر ظرفیت بازبینی و آزمایش همزمان رشد نکند، کدهای بیشتری پشتِ درِ تیم کنترل کیفیت صف می‌کشند.
هوش مصنوعی خستگی نمی‌شناسد و می‌تواند در چند دقیقه، صدها خط کد تولید کند؛ اما آزمودن کد، بازبینی امنیتی و فهم تاثیر کد بر کل سامانه همچنان زمان می‌برد. تولید سریع‌تر، مسئولیت بررسی را حذف نمی‌کند.
وایب کدینگ؛ وقتی نتیجه از فهمیدن مسیر مهم‌تر می‌شود
«وایب کدینگ» به شیوه‌ای از برنامه‌نویسی گفته می‌شود که در آن، کاربر خواسته خود را با زبان عادی برای هوش مصنوعی توضیح می‌دهد و بدون درک کامل کد تولیدشده، بارها از مدل می‌خواهد آن را تغییر دهد تا در نهایت برنامه به‌درستی اجرا شود.
این روش برای ساخت نمونه اولیه، آزمودن ایده‌ها یا راه‌اندازی یک پروژه‌ای شخصی می‌تواند جذاب باشد. مشکل زمانی آغاز می‌شود که همان شیوه برنامه‌نویسی، وارد سامانه‌ای حساس و بزرگ شود. ممکن است هر قطعه کد به‌تنهایی کار کند، اما با معماری کلی، محدودیت‌های امنیتی یا روش نگهداری اطلاعات سازگار نباشد.
هنگام بروز خطا نیز ممکن است مدل به‌جای پیدا کردن علت اصلی، لایه‌ای تازه به کد اضافه کند. برنامه دوباره اجرا می‌شود، اما پیچیدگی پنهان آن بیشتر خواهد شد. اگر تیم نداند چرا کد کار می‌کند، هنگام خرابی نیز به‌سختی می‌تواند آن را تعمیر کند.
پژوهش‌ها درباره کیفیت کد تولیدشده با هوش مصنوعی نتایج یکسانی نداشته‌اند. برخی آزمایش‌های گیت‌هاب نشان داده‌اند برنامه‌نویسانی که از کوپایلوت استفاده می‌کنند، در برخی وظایف مشخص، کدهایی خواناتر و پذیرفتنی‌تر تولید کرده‌اند.
در مقابل، پژوهش METR در سال ۲۰۲۵ نشان داد ۱۶ توسعه‌دهنده باتجربه هنگام کار روی ۲۴۶ وظیفه واقعی در پروژه‌های آشنا (و با ابزارهای در دسترس آن زمان) به‌طور میانگین ۱۹ درصد کُندتر شدند؛ درحالی‌که خودشان احساس می‌کردند سریع‌تر کار کرده‌اند. METR نیز تأکید کرده که این نتیجه به ابزارها و شرایط همان دوره محدود است و نباید آن را به تمام برنامه‌نویسان تعمیم داد.
هشدار
اجرای موفق برنامه به‌تنهایی نشان نمی‌دهد که کد امن، سریع یا قابل‌نگهداری است. در پروژه‌های جدی، آزمون خودکار، بازبینی انسانی، اسکن امنیتی و فراهم بودن امکان بازگرداندن تغییرات همچنان ضروری‌اند.
هوش مصنوعی از دانش سازمانی چه می‌داند؟
بخش مهمی از مهارت کارکنان در هیچ فایل یا دستورالعملی نوشته نشده است. یک مهندس باتجربه ممکن است بداند کدام قطعه در شرایط خاص خراب می‌شود، یک کارشناس پشتیبانی لحن مشتری ناراضی را می شناسد و یک برنامه‌نویس قدیمی، دلیل تصمیمی عجیب در معماری سامانه را به یاد می‌آورد
نوشدارو پلاس
دانشی که در ذهن کارکنان باتجربه باقی مانده، همیشه در پایگاه داده شرکت وجود ندارد. اگر این افراد پیش از انتقال تجربه از سازمان خارج شوند، هوش مصنوعی نیز چیزی برای یاد گرفتن از آن بخش پنهان کار نخواهد داشت.
این «دانش سازمانی» با حذف نیروها از بین می‌رود و لزوماً بخشی از داده‌های آموزشی هوش مصنوعی نیست. تجربه شرکت فورد نمونه‌ای قابل‌توجه است
. این خودروساز پس از اتکای بیش از حد به سامانه‌های خودکار کنترل کیفیت، طی سه سال حدود ۳۵۰ متخصص باتجربه را استخدام کرد یا به شرکت بازگرداند. وظیفه آن‌ها فقط پیداکردن ایرادها نبود؛ این مهندسان به آموزش نیروهای جوان و بهبود داده‌ها و سامانه‌های هوش مصنوعی نیز کمک کردند.
فورد هوش مصنوعی را کنار نگذاشت. در عوض، تجربه انسانی را دوباره در مرکز فرایند قرار داد و از اتوماسیون برای تقویت همان تجربه کمک گرفت.
حذف نیروی تازه‌کار = تضعیف آینده‌ی تیم
نیروهای ارشد از همان روز اول ارشد نبوده‌اند. آن‌ها با انجام کارهای ساده، دیدن خطاها، دریافت بازخورد و مسئولیت‌پذیری، به شکلی تدریجی به این مرحله رسیده‌اند. اگر تمام کارهای سطح پایه به هوش مصنوعی سپرده شوند و فرصت ورود نیروهای تازه‌کار کاهش پیدا کند، چند سال بعد چه کسی جای متخصصان امروز را خواهد گرفت؟
ابزار هوشمند می‌تواند به نیروی تازه‌کار در توضیح کد، ساخت آزمون و یافتن ایراد کمک کند؛ اما اگر پاسخ آماده جای فهم مسئله را بگیرد، مسیر یادگیری نیز مختل می‌شود.
حتی در شرکت IBM، پس از خودکارسازی بخش بزرگی از درخواست‌های تکراری منابع انسانی، مدیران بر ادامه جذب نیروهای سطح پایه تاکید کردند تا مسیر پرورش متخصصان آینده خشک نشود.
ایجنت‌های هوش مصنوعی لزوماً همیشه قابل‌اتکا نیستند
ایجنت هوش مصنوعی فقط پاسخ نمی‌دهد؛ می‌تواند چند مرحله را برنامه‌ریزی کند، ابزارهای دیگر را به کار بگیرد و اقداماتی مانند جست‌وجو، ثبت اطلاعات یا ارسال پیام را پیش ببرد.
این قابلیت جذاب است، اما هر مرحله‌ی تازه، احتمال بروز خطا را افزایش می‌دهد. در یک ارزیابی از ایجنت‌های هوش مصنوعی در محیط شبیه‌سازی‌شده یک شرکت، حتی بهترین مدل‌ها نیز بخش بزرگی از وظایف اداری و چندمرحله‌ای را کامل نکردند.
پژوهش دیگری روی وظایف مدیریت ارتباط با مشتری، موفقیت ۵۸ درصدی در کارهای تک‌مرحله‌ای و موفقیت ۳۵ درصدی در کارهای چندمرحله‌ای را گزارش کرد. این اعداد معیار جهانی تمام ایجنت‌ها نیستند، اما فاصله میان نمایش‌های تبلیغاتی و فرایندهای واقعی را نشان می‌دهند.
به همین دلایل، بهتر است پیش از سپردن یک فرایند کاری به هوش مصنوعی، باهم این چند پرسش را مرور کنیم:
- اگر ابزار اشتباه کند، چه کسی متوجه خواهد شد؟
- آیا پیش از هر اقدام حساس، تایید انسانی وجود دارد؟
- سامانه به چه اطلاعات و ابزارهایی دسترسی دارد؟
- آیا فعالیت‌های آن ثبت می‌شوند؟
- در صورت بروز مشکل، می‌توان ایجنت را به سرعت متوقف کرد؟
- آیا کارمندان می‌فهمند خروجی چگونه تولید شده است؟
واقعیت هوش مصنوعی برای تیم‌های ایرانی
در ایران، اتکای کامل به ابزارهای ابری هوش مصنوعی یک خطر اضافی دارد: دسترسی به آن‌ها همیشه پایدار یا تضمین‌شده نیست. تحریم، محدودیت حساب، اختلال اینترنت، تغییر روش پرداخت و مسدودشدن ناگهانی سرویس می‌توانند ابزار را درست هنگام نیاز از دسترس خارج کنند.
از سوی دیگر، مدل‌ها همیشه شناخت کاملاً دقیقی از زبان فارسی، قوانین ایران، شیوه‌های پرداخت داخلی و محدودیت‌های زیرساختی ندارند. بنابراین خروجی آن‌ها باید با واقعیت محلی سنجیده شود. برای یک تیم ایرانی، مهندسی که معماری سامانه و محدودیت‌های شبکه، میزبانی و بازار داخلی را می‌شناسد، فقط تولیدکننده کد نیست؛ او بخشی از حافظه و توان سازگاری سازمان است.
در پایان
هوش مصنوعی قرار نیست شکست بخورد تا ارزش انسان ثابت شود. این ابزار همین حالا هم می‌تواند بخشی از کار ما را سریع‌تر و آسان‌تر کند. مسئله این است که سرعت را با فهم و تولید را با مهندسی اشتباه نگیریم.
شاید بهتر باشد هوش مصنوعی را همکار سریعی ببینیم که از انجام کارهای تکراری خسته نمی‌شود، اما همچنان به کسی نیاز دارد که مسئله درست را تعریف کند، نتیجه را بسنجد و هنگام دشوارشدن شرایط، مسئولیت تصمیم را بپذیرد.
آینده احتمالاً نه متعلق به تیم‌هایی است که هوش مصنوعی را کنار می‌گذارند و نه سازمان‌هایی که انسان را حذف می‌کنند؛ بلکه برای کسب‌وکارهایی است که می‌دانند چه کاری را به ماشین بسپارند و قضاوت درباره چه چیزی را خود پیش ببرند.
آدرس مطلب: https://nooshdaroo.ir/safe-ecommerce-selling/ai-human-workforce-limitations/
