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

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

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

دمو، محصول نیست

هر دمو مربوط به کدنویسی با هوش مصنوعی را تماشا کنید، خواهید دید که یک رابط کاربری زیبا در عرض چند دقیقه شکل می‌گیرد. آنچه نخواهید دید، تخلیه شدن استخر اتصال پایگاه داده (database connection pool) تحت فشار بارِ کاری است. آنچه نخواهید دید، نبودِ محدودیت‌های نرخ (rate limits) در یک نقطه پایانی API، نبودِ گزارش‌های بازرسی (audit logs)، یا هزینه‌های ذخیره‌سازیِ ثبتِ هر تعامل کاربر در یک object bucket است، صرفاً چون هوش مصنوعی فکر کرده آنجا مکان مناسبی برای ریختن وضعیت (state) است.

سیستم‌های عملیاتی (Production) نیازمند مقیاس‌پذیری، امنیت، عملکرد و کنترل هزینه هستند. این ویژگی‌ها در یک جلسه بازبینیِ سریع (sprint review) نامرئی هستند. آن‌ها تنها زمانی خود را نشان می‌دهند که کاربران واقعی با رفتارهای غیرقابل پیش‌بینی، موارد خاص (edge cases) و امتناع از کلیک کردن روی دکمه‌ها به ترتیبی که شما انتظار داشتید، از راه می‌رسند. من پروژه‌های بسیار زیادی را دیده‌ام که با کمک هوش مصنوعی در مرحله تضمین کیفیت (QA) عالی به نظر می‌رسیدند، اما یک هفته پس از عرضه، به درس‌های گران‌قیمتی تبدیل شدند.

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

آنچه اکنون اهمیت دارد

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

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

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

  • آن‌ها پیشنهادات هوش مصنوعی را به چالش می‌کشند. اعتمادبه‌نفس مدل یک سراب است. مدل ممکن است معماری‌هایی پیشنهاد دهد که تأخیر شبکه (network latency) را نادیده می‌گیرند، کتابخانه‌هایی را توصیه کنند که سال‌هاست منسوخ شده‌اند، یا ویژگی‌هایی را حل کنند که اصلاً در نیازمندی‌ها وجود ندارند.