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

چرا جایگزینی برنامه‌نویسان با هوش مصنوعی این‌قدر آسان نخواهد بود؟

با تمام مقالاتی که درباره چقدر شگفت‌انگیز بودن پیشرفت‌های هوش مصنوعی نوشته شده، نگرانی‌های زیادی در مورد احتمال اینکه ما به‌عنوان توسعه‌دهندگان نرم‌افزار به زودی شغل خود را از دست بدهیم و جایگزین هوش مصنوعی شویم وجود دارد. آنها تصور می‌کنند که تمام مدیران کسب‌وکار و محققان محصول ممکن است بیشتر یا تمام توسعه‌دهندگان نرم‌افزار خود را کنار گذاشته و مستقیماً از هوش مصنوعی بخواهند دقیقاً آنچه را که فکر می‌کنند به آن نیاز دارند، بسازند. به‌عنوان کسی که ۱۵ سال در حال ایجاد نرم‌افزار از روی مشخصاتی که این افراد می‌سازند، بوده‌ام، سخت است که تمام این نگرانی‌ها را جدی بگیرم.

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

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

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

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

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

ناگهان از مشتری پرسیدم: “آیا باید ورودی‌ای که به کاربر اجازه می‌دهد شرایط و ضوابط صحیح را نادیده بگیرد، حذف کنم؟” پاسخی که دریافت کردم، از آن زمان به ذهنم حک شده است. کلمات دقیق او با اطمینان کامل گفته شد:

“این هرگز اتفاق نخواهد افتاد.”

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

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

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

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

هوش مصنوعی در حال حاضر: شطرنج در مقابل خودروهای خودران

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

هوش مصنوعی از دهه 1980 در شطرنج مورد استفاده قرار گرفته است. این موضوع به طور گسترده‌ای پذیرفته شده است که هوش مصنوعی از توانایی انسان‌ها در برنده شدن در شطرنج پیشی گرفته است. این امر همچنین تعجب‌آور نیست، چرا که پارامترهای شطرنج محدود (FINITE) هستند (اگرچه هنوز این بازی حل نشده است).

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

در جبهه دیگری، هوش مصنوعی در حال فعالیت است – خودروهای خودران. تولیدکنندگان مدت‌هاست وعده خودروهای خودران را داده‌اند. برخی از خودروها توانایی خودران بودن دارند، اما این ویژگی‌ها محدودیت‌هایی دارند. در بسیاری از شرایط، خودرو به نظارت فعال نیاز دارد؛ راننده ممکن است مجبور باشد دست‌های خود را روی فرمان نگه دارد، بنابراین ویژگی خودران کاملاً خودکار نیست.

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

در تکنولوژی، استاندارد برای در دسترس بودن، پنج یا حتی شش “9” است — یک وب‌سایت یا سرویس باید 99.999% (یا 99.9999%) از زمان در دسترس باشد. هزینه دستیابی به 99% اول چندان بالا نیست. این بدان معناست که وب‌سایت یا سرویس شما می‌تواند بیش از سه روز (87.6 ساعت) قطع شود در یک سال. اما برای هر “9” که به انتها اضافه می‌شود، هزینه رسیدن به آن به طور نمایی افزایش می‌یابد. زمانی که به 99.9999% می‌رسید، تنها 31.5 ثانیه قطعی در سال مجاز است. این نیاز به برنامه‌ریزی و تلاش بسیار بیشتری دارد و البته هزینه آن نیز بالاتر است.

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

دلیل دشواری در رسیدن به سطح ایمنی قابل قبول این است که رانندگی با خودرو شامل متغیرهای بسیار بیشتری نسبت به شطرنج است و این متغیرها محدود نیستند. 95% یا 99% اول ممکن است قابل پیش‌بینی و آسان برای مدیریت باشد. اما پس از این سطح، هزاران حالت خاص وجود دارد و هر یک از آن‌ها ممکن است ویژگی‌هایی مشترک داشته باشند اما هرکدام منحصر به فرد هستند؛ خودروهای دیگر که توسط انسان‌های دیگر رانده می‌شوند، مسدود شدن راه‌ها، ساخت‌وساز، تصادفات، شرایط آب و هوایی. به چند بار برخورد کرده‌اید که پس از آسفالت کردن جاده، خطوط تقسیم‌کننده هنوز رنگ نشده باشند؟ این بسیار دشوارتر است که مدل هوش مصنوعی شما قادر باشد این ناهنجاری‌ها و شرایط خاص را شناسایی کند و از آن‌ها به‌درستی اجتناب کند تا تصادف رخ ندهد.

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

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

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

بدتر از آن، نیازها تغییر می‌کنند یا نادیده گرفته می‌شوند. به تازگی از من خواسته شد که به تیمی کمک کنم تا ابزاری بسازند که به مردم کمک کند اطلاعاتی در مورد مسائل بهداشتی مربوط به COVID-19 دریافت کنند. این اپلیکیشن قرار بود برای ناحیه‌ای از جهان ساخته شود که دسترسی به وای‌فای پایدار نداشت. تیم می‌خواست من کمک کنم تا اپلیکیشنی بسازیم که بتواند نظرسنجی‌ها را از طریق پیامک (پیامک تلفن همراه) انجام دهد. ابتدا هیجان‌زده بودم که درگیر شوم.

وقتی شروع به شنیدن توضیحات تیم در مورد آنچه که فکر می‌کردند می‌خواهند، متوجه شدم که این یک مشکل خواهد بود. این یک چیز است که از یک فروشگاه درخواست کنید که در مقیاس 1-10 بپرسند چقدر احتمال دارد دوباره از فروشگاه خرید کنید. اما خیلی متفاوت است که نظرسنجی‌های چندمرحله‌ای با سوالات چندگزینه‌ای در مورد علائمی که ممکن است با COVID-19 تجربه کنید، انجام دهید. هرگز نگفتم نه، اما تمام نقاط احتمالی خرابی در این فرآیند را مطرح کردم و خواستم تیم به‌طور واضح تعیین کند که چگونه پاسخ‌های ورودی به تمامی سوالات را مدیریت خواهیم کرد.

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

آیا ایده استفاده از هوش مصنوعی برای ایجاد نرم‌افزار این است که همان ذینفعان مستقیماً با کامپیوتر صحبت کنند تا یک نظرسنجی مبتنی بر پیامک ایجاد کنند؟ آیا هوش مصنوعی در مورد نحوه مدیریت تمام مشکلات احتمالی جمع‌آوری داده‌های نظرسنجی از طریق پیامک سوالات کاوشی خواهد پرسید؟ آیا به تمام مشکلاتی که ما به عنوان انسان ممکن است در طول مسیر اشتباه انجام دهیم و نحوه مدیریت این اشتباهات توجه خواهد کرد؟

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

در دهه گذشته، صنعت نرم‌افزار از متدولوژی آبشاری به چابک (Agile) منتقل شده است. آبشاری دقیقاً تعریف می‌کند که چه می‌خواهید پیش از نوشتن هر کدی، در حالی که چابک به اندازه کافی انعطاف‌پذیری می‌دهد تا بتوانید در مسیر تغییرات لازم را ایجاد کنید.

پروژه‌های نرم‌افزاری زیادی که از روش آبشاری استفاده کرده‌اند، شکست خورده‌اند، زیرا ذینفعان فکر می‌کردند می‌دانند چه می‌خواهند و

بعداً متوجه شدند که باید چیزی کاملاً متفاوت بسازند.

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

نتیجه‌گیری

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