وایب‌کدینگ و مسئولیت مهندسی

وایب‌کدینگ؛ وقتی کد تولید می‌شود، اما آیا مهندسی هم انجام شده است؟

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

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

به نظرم این اتفاق را نه باید بی‌دلیل ستایش کرد و نه از روی ترس کنار گذاشت. اما یک سؤال مهم وجود دارد که ارزش دارد درباره‌اش بحث کنیم:

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

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

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

اما اینجا یک تفاوت مهم وجود دارد.

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

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

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

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

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

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

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

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

من شخصاً ترجیح می‌دهم به‌جای بحث درباره‌ی اینکه چه کسی کد را نوشته، بپرسم چه کسی می‌تواند توضیح بدهد چرا این راه‌حل انتخاب شده، کجا ممکن است شکست بخورد و چطور می‌توان از درست کار کردنش مطمئن شد.

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

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

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

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

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