در چند سال اخیر، هوش مصنوعی شیوه ساخت نرم‌افزار را به‌طور چشمگیری تغییر داده است. ابزارهایی که می‌توانند کد تولید کنند، خطاها را شناسایی کنند، فایل‌های مختلف را اصلاح کنند و حتی بخش‌هایی از فرایند توسعه یک نرم‌افزار را به‌صورت خودکار انجام دهند، برنامه‌نویسی را برای افراد بیشتری در دسترس قرار داده‌اند.
یکی از اصطلاحاتی که در همین دوران رواج پیدا کرده، وایب کدینگ یا کدنویسی حسی (به زبان انگلیسی: Vibe coding) است؛ روشی که در آن فرد می‌تواند خواسته خود را با زبان طبیعی برای یک مدل هوش مصنوعی توضیح دهد و از آن بخواهد بخش قابل توجهی از کد موردنیاز را تولید کند.
اما با آسان‌تر شدن ساخت نرم‌افزار، یک مسئله جدید در حال شکل‌گیری است که شاید در نگاه اول چندان جدی به نظر نرسد:
وقتی ساختن چیزی بسیار آسان می‌شود، ممکن است بیش از اندازه شروع به ساختن کنیم.
در این شرایط، مسئله دیگر فقط کیفیت کد نیست؛ بلکه این سؤال مطرح می‌شود که آیا چیزی که در حال ساختنش هستیم، اساساً ارزش ساخته شدن دارد یا خیر.
در متن اصلی این مقاله که مجله اسید هولیک از آن بهره برده، نویسنده برای توصیف این وضعیت از اصطلاحی به نام دوم‌کدینگ (به زبان انگلیسی: Doomcoding) استفاده می‌کند؛ مفهومی که می‌توان آن را به‌صورت ساده، «غرق شدن در ساختن مداوم و بی‌پایان چیزهایی که الزاماً نیازی به آنها وجود ندارد» تعریف کرد.
Vibe Coding چگونه تغییر کرده است؟
اصطلاح Vibe Coding در مدت کوتاهی دستخوش تغییر شده است.
در شکل اولیه، ایده بسیار ساده بود: کاربر توضیح می‌داد چه برنامه‌ای می‌خواهد و مدل هوش مصنوعی تلاش می‌کرد آن را تولید کند.
مشکل اینجا بود که مدل ممکن بود برداشت ناقصی از نیاز کاربر داشته باشد و در نتیجه کدی تولید کند که از نظر امنیت، حریم خصوصی، معماری یا قابلیت نگهداری مشکلات جدی داشته باشد.
برای یک برنامه ساده، شاید چنین رویکردی قابل تحمل به نظر برسد؛ اما وقتی نرم‌افزار قرار است اطلاعات حساس کاربران را پردازش کند یا در مقیاس واقعی مورد استفاده قرار گیرد، کیفیت کد و نحوه طراحی سیستم اهمیت بسیار بیشتری پیدا می‌کند.
با پیشرفت مدل‌های هوش مصنوعی، وضعیت تغییر کرده است.
امروزه توسعه‌دهندگان حرفه‌ای‌تر معمولاً فقط یک درخواست کلی به مدل نمی‌دهند. آنها می‌توانند دستورالعمل‌های دقیق، مستندات، قوانین پروژه، ابزارهای بررسی امنیت، تست‌ها و فرایندهای مختلف کنترل کیفیت را در جریان توسعه قرار دهند.
بنابراین وایب کدینگ دیگر الزاماً به معنای «از هوش مصنوعی بخواه هر چیزی خواستم بسازد» نیست.
اما همین پیشرفت، مسئله جدیدی را ایجاد کرده است.
مشکل اصلی دیگر فقط کد بد نیست
یکی از تغییرات مهمی که ابزارهای هوش مصنوعی در برنامه‌نویسی ایجاد کرده‌اند، کاهش هزینه تولید کد است.
در گذشته، ساخت یک نرم‌افزار کوچک ممکن بود ساعت‌ها یا روزها زمان ببرد. بنابراین طبیعی بود که توسعه‌دهنده پیش از شروع کار، درباره ارزش ایده، معماری پروژه و کاربرد واقعی آن فکر کند.
اما وقتی یک سیستم هوش مصنوعی می‌تواند در مدت کوتاهی بخش بزرگی از این کار را انجام دهد، اصطکاک میان ایده و اجرا کاهش پیدا می‌کند.
این اتفاق از یک طرف بسیار مثبت است.
ایده‌ها سریع‌تر آزمایش می‌شوند.
نمونه‌های اولیه با هزینه کمتر ساخته می‌شوند.
افراد بیشتری می‌توانند ایده‌های خود را به محصول تبدیل کنند.
اما همین ویژگی یک خطر رفتاری نیز ایجاد می‌کند:
ممکن است فاصله میان «می‌توانم آن را بسازم» و «باید آن را بسازم» از بین برود.
و این دو جمله اساساً یک معنی ندارند.
از «آیا می‌توانم بسازم؟» تا «آیا باید بسازم؟»
یکی از مهم‌ترین مهارت‌های توسعه نرم‌افزار، توانایی تشخیص مسئله ارزشمند از مسئله کم‌اهمیت است.
ممکن است بتوانیم یک اپلیکیشن، وب‌سایت، ابزار، اتوماسیون یا سرویس جدید بسازیم؛ اما این قابلیت به‌تنهایی دلیل کافی برای ساخت آن نیست.
پیش از شروع هر پروژه بهتر است چند سؤال اساسی مطرح شود:
- چه مشکلی قرار است حل شود؟
- چه کسی واقعاً این مشکل را دارد؟
- آیا افراد حاضرند برای حل آن زمان یا پول صرف کنند؟
- آیا راه ساده‌تری برای حل مسئله وجود دارد؟
- چه چیزی این محصول را از گزینه‌های موجود متمایز می‌کند؟
- هزینه نگهداری آن چقدر خواهد بود؟
- اگر این پروژه ساخته شود، چه چیزی در زندگی یا کار کاربران بهتر خواهد شد؟
در دوره‌ای که ساخت نرم‌افزار دشوار بود، محدودیت فنی تا حدی جلوی پروژه‌های غیرضروری را می‌گرفت.
اما اکنون ممکن است این محدودیت کمتر شده باشد.
در نتیجه، توانایی تصمیم‌گیری درباره اینکه چه چیزی نباید ساخته شود، ارزش بیشتری پیدا می‌کند.
Doomcoding چیست؟
«Doomcoding» در متن اصلی که مجله اینترنتی اسید هولیک از آن استفاده کرده فقط یک اصطلاح توصیفی است، نه یک اصطلاح فنی استاندارد.
منظور از آن حالتی است که فرد وارد چرخه‌ای از ساختن مداوم می‌شود؛ ایده‌ای به ذهنش می‌رسد، آن را با کمک ابزارهای هوش مصنوعی پیاده می‌کند، سپس ایده دیگری پیدا می‌کند و دوباره شروع به ساختن می‌کند.
این چرخه می‌تواند بسیار لذت‌بخش باشد.
هر پروژه جدید تقریباً بلافاصله نتیجه قابل مشاهده‌ای ایجاد می‌کند.
یک ایده در ذهن تبدیل به یک رابط کاربری می‌شود.
بعد یک قابلیت جدید اضافه می‌شود.
سپس یک مشکل حل می‌شود.
و ناگهان فرد ساعت‌ها در حال ساخت چیزی است که چند ساعت قبل حتی وجود خارجی نداشته است.
مشکل زمانی آغاز می‌شود که فرایند ساختن جای هدف اصلی را بگیرد.
در این حالت، دیگر فرد نمی‌پرسد:
این محصول قرار است چه مشکلی را حل کند؟
بلکه بیشتر می‌پرسد:
حالا دیگر چه چیزی می‌توانم به آن اضافه کنم؟
چرا هوش مصنوعی می‌تواند این چرخه را تشدید کند؟
ساخت نرم‌افزار به‌طور سنتی شامل مقدار زیادی کار تکراری، خطایابی، جست‌وجو، مستندسازی و پیاده‌سازی جزئیات است.
هوش مصنوعی می‌تواند بخش قابل توجهی از این اصطکاک را کاهش دهد.
این ویژگی برای توسعه‌دهنده بسیار ارزشمند است، اما یک اثر جانبی احتمالی دارد.
وقتی هزینه اجرای یک ایده پایین می‌آید، تعداد ایده‌هایی که فرد می‌تواند اجرا کند افزایش پیدا می‌کند.
در نتیجه ممکن است ذهن انسان به‌جای انتخاب، وارد حالت تولید مداوم شود.
ایده جدید.
پروژه جدید.
ابزار جدید.
نسخه جدید.
قابلیت جدید.
و دوباره ایده جدید.
این چرخه الزاماً به معنای بهره‌وری بیشتر نیست.
گاهی فقط به معنای تولید بیشتر است.
و تولید بیشتر با ارزش بیشتر یکسان نیست.
حتی برنامه‌نویس‌های محتاط هم در معرض این مشکل هستند
یکی از نکات مهم متن اصلی این است که مسئله فقط افراد تازه‌کار یا اصطلاحاً Vibe Coderها نیستند.
حتی توسعه‌دهنده‌ای که سال‌ها تجربه دارد و نسبت به امنیت، معماری، سادگی و کیفیت کد حساس است، می‌تواند تحت تأثیر ابزارهای جدید قرار گیرد.
فرض کنید توسعه‌دهنده‌ای برای هر پروژه مجموعه‌ای از کنترل‌ها ایجاد کرده است:
- بررسی امنیت
- بررسی حریم خصوصی
- تست کد
- جلوگیری از ایجاد بدهی فنی
- ساده‌سازی معماری
- بررسی وابستگی‌ها
- مستندسازی
- کنترل کیفیت خروجی مدل
تمام این اقدامات می‌توانند کیفیت محصول را افزایش دهند.
اما هیچ‌کدام به یک سؤال بنیادی پاسخ نمی‌دهند:
آیا اصلاً لازم بود این محصول ساخته شود؟
این نکته بسیار مهم است.
ممکن است بتوانیم بهترین نرم‌افزار ممکن را برای حل یک مسئله بی‌اهمیت تولید کنیم.
در این حالت، کیفیت فنی بالا، مشکل اصلی را حل نمی‌کند.
دو تغییر رفتاری در عصر برنامه‌نویسی با هوش مصنوعی
بر اساس تجربه‌ای که متن اصلی مطرح می‌کند، استفاده از ابزارهای هوش مصنوعی می‌تواند دست‌کم دو تغییر رفتاری ایجاد کند.
تغییر اول: «احتمالاً کار می‌کند»
توسعه‌دهنده ممکن است بخشی از کد تولیدشده توسط هوش مصنوعی را بررسی کند و به این نتیجه برسد که:
احتمالاً درست است.
در گذشته، شاید لازم بود خود فرد جزئیات بیشتری را بررسی کند، مستندات را بخواند یا کد را از ابتدا بنویسد.
اما وقتی یک ابزار هوش مصنوعی می‌تواند کد را تولید، اصلاح و حتی بررسی کند، بخشی از فرایند نظارت به ماشین واگذار می‌شود.
این اتفاق لزوماً بد نیست.
در واقع، واگذاری بخشی از کار به ابزارهای خودکار یکی از دلایل اصلی استفاده از آنهاست.
مشکل زمانی ایجاد می‌شود که اعتماد به ابزار، جای قضاوت انسانی را به‌طور کامل بگیرد.
تغییر دوم: «شاید بتوانم این را هم بسازم»
تغییر دوم از نظر متن اصلی مهم‌تر است.
یک ایده ناگهان به ذهن فرد می‌رسد:
اگر بتوانم این قابلیت را هم بسازم چه؟
سپس چند دقیقه بعد، نمونه اولیه آن آماده است.
همین موفقیت کوچک می‌تواند انگیزه‌ای برای ایده بعدی ایجاد کند.
در نتیجه، فرد وارد چرخه‌ای می‌شود که در آن امکان ساختن خودش تبدیل به محرک ساختن می‌شود.
این همان نقطه‌ای است که وایب کدینگ می‌تواند به دوم‌کدینگ نزدیک شود.
ساختن سریع‌تر لزوماً به معنای پیشرفت سریع‌تر نیست
یکی از تصورات رایج درباره هوش مصنوعی این است که اگر بتوانیم با سرعت بیشتری نرم‌افزار تولید کنیم، الزاماً بهره‌وری نیز افزایش پیدا خواهد کرد.
اما بهره‌وری را نمی‌توان صرفاً با تعداد خطوط کد یا تعداد پروژه‌های ساخته‌شده اندازه‌گیری کرد.
فرض کنید یک توسعه‌دهنده در گذشته در یک ماه یک ابزار می‌ساخت و اکنون با کمک هوش مصنوعی می‌تواند ۲۰ ابزار بسازد.
اگر تنها یکی از این ابزارها واقعاً مورد استفاده قرار گیرد، آیا ۲۰ برابر بهره‌وری ایجاد شده است؟
لزوماً نه.
اکنون ۱۹ پروژه نیز وجود دارند که باید نگهداری، به‌روزرسانی، مستندسازی یا کنار گذاشته شوند.
بنابراین با کاهش هزینه تولید، ممکن است هزینه تصمیم‌گیری و انتخاب اهمیت بیشتری پیدا کند.
عصر «ساختن فضاپیما» به پایان رسیده است
متن اصلی به‌صورت استعاری از اصطلاح «ساختن فضاپیما» استفاده می‌کند؛ یعنی پروژه‌هایی که زمانی به دلیل دشواری فنی، نیازمند تخصص و منابع قابل توجه بودند.
امروز بسیاری از این موانع کاهش یافته‌اند.
یک فرد می‌تواند با کمک ابزارهای هوش مصنوعی، در مدت کوتاهی نمونه اولیه یک محصول را ایجاد کند.
این اتفاق از نظر دموکراتیک شدن فناوری بسیار مهم است.
اما نتیجه جانبی آن می‌تواند این باشد که تعداد محصولات، ابزارها و پروژه‌های ساخته‌شده بسیار سریع‌تر از گذشته افزایش پیدا کند.
در چنین محیطی، کمبود اصلی دیگر الزاماً توانایی ساختن نیست.
ممکن است کمبود اصلی، توجه، زمان و توانایی تشخیص چیزهای ارزشمند باشد.
مشکل واقعی: وفور نرم‌افزارهای غیرضروری
اگر روند فعلی ادامه پیدا کند، ممکن است با محیطی مواجه شویم که در آن ساخت یک نرم‌افزار بسیار آسان‌تر از گذشته است، اما پیدا کردن نرم‌افزار واقعاً مفید دشوارتر می‌شود.
ده‌ها ابزار می‌توانند یک مسئله مشابه را حل کنند.
صدها اپلیکیشن ممکن است قابلیت‌های مشابهی داشته باشند.
و هزاران پروژه کوچک ممکن است توسط افرادی ساخته شوند که هیچ‌گاه بررسی نکرده‌اند آیا واقعاً کسی به آنها نیاز دارد یا خیر.
در چنین شرایطی، مشکل از کمبود نوآوری نیست.
مشکل می‌تواند وفور نوآوری کم‌ارزش باشد.
چگونه از دام Doomcoding دور بمانیم؟
راه‌حل لزوماً کنار گذاشتن برنامه‌نویسی با هوش مصنوعی نیست.
اتفاقاً چنین کاری می‌تواند نادیده گرفتن یکی از مهم‌ترین پیشرفت‌های ابزارهای توسعه نرم‌افزار باشد.
مسئله، استفاده آگاهانه از این فناوری است.
قبل از ساخت، مسئله را تعریف کنید
پیش از اینکه از یک مدل هوش مصنوعی بخواهید چیزی بسازد، ابتدا مسئله را مشخص کنید.
به‌جای اینکه بگویید:
چه چیزی می‌توانم بسازم؟
بپرسید:
چه مشکلی ارزش حل کردن دارد؟
این تغییر کوچک در سؤال می‌تواند مسیر پروژه را کاملاً تغییر دهد.
برای ایده‌ها دوره آزمایشی تعیین کنید
هر ایده‌ای الزاماً نباید به محصول تبدیل شود.
می‌توان ابتدا یک نمونه اولیه بسیار کوچک ساخت و سپس بررسی کرد آیا واقعاً ارزش ادامه دادن دارد یا خیر.
اگر پاسخ منفی بود، کنار گذاشتن پروژه شکست نیست.
در واقع، جلوگیری از صرف زمان بیشتر روی یک ایده ضعیف می‌تواند یک تصمیم کاملاً منطقی باشد.
معیار موفقیت را «کد بیشتر» قرار ندهید
تعداد خطوط کد، تعداد قابلیت‌ها یا تعداد فایل‌های پروژه معیار مناسبی برای ارزش یک محصول نیستند.
گاهی بهترین نرم‌افزار، نرم‌افزاری است که با کمترین پیچیدگی، یک مسئله مشخص را حل می‌کند.
سادگی نیز می‌تواند یک دستاورد فنی باشد.
از خودتان بپرسید: اگر این پروژه ساخته نشود چه اتفاقی می‌افتد؟
این سؤال بسیار ساده اما مهم است.
اگر پاسخ این باشد که هیچ اتفاق مهمی نمی‌افتد، شاید پروژه ارزش اولویت بالایی نداشته باشد.
اما اگر نبود آن باعث ایجاد یک مشکل واقعی برای کاربران یا کسب‌وکار شود، ارزش ادامه دادن آن بیشتر است.
مهم‌ترین مهارت برنامه‌نویس آینده شاید «نه گفتن» باشد
هوش مصنوعی در حال کاهش هزینه ساخت نرم‌افزار است.
این روند احتمالاً فرصت‌های بسیار زیادی ایجاد خواهد کرد؛ از نمونه‌سازی سریع گرفته تا اتوماسیون و توسعه محصول برای افرادی که پیش‌تر توانایی برنامه‌نویسی نداشتند.
اما هرچه ساختن آسان‌تر شود، انتخاب کردن اهمیت بیشتری پیدا می‌کند.
در گذشته ممکن بود یک ایده به دلیل دشواری فنی هرگز اجرا نشود.
در آینده ممکن است تقریباً هر ایده‌ای قابلیت اجرا داشته باشد.
بنابراین سؤال مهم‌تر این نخواهد بود که:
آیا می‌توانیم این را بسازیم؟
بلکه این خواهد بود:
آیا باید این را بسازیم؟
این تفاوت، یکی از مهم‌ترین چالش‌های عصر برنامه‌نویسی با هوش مصنوعی است.
جمع‌بندی
وایب کدینگ توانایی ساخت نرم‌افزار را برای افراد بیشتری در دسترس قرار داده و هوش مصنوعی می‌تواند بسیاری از بخش‌های زمان‌بر توسعه را ساده‌تر کند.
اما همین سهولت می‌تواند یک خطر رفتاری جدید ایجاد کند: ساختن صرفاً به دلیل اینکه ساختن آسان شده است.
دوم‌کدینگ نامی است که می‌توان برای این وضعیت به کار برد؛ حالتی که در آن فرد به‌طور مداوم در حال ساخت پروژه‌ها، ابزارها و قابلیت‌های جدید است، بدون اینکه همیشه از خود بپرسد آیا این تلاش‌ها مسئله‌ای واقعی را حل می‌کنند یا خیر.
در چنین شرایطی، مهارت اصلی دیگر فقط برنامه‌نویسی نیست.
حتی ممکن است کیفیت کدنویسی نیز مهم‌ترین مسئله نباشد.
مسئله بنیادی‌تر، توانایی تشخیص مسئله ارزشمند، تعیین اولویت، مقاومت در برابر وسوسه ساختن و توقف به‌موقع است.
هوش مصنوعی می‌تواند سرعت ساختن را به‌شدت افزایش دهد؛ اما هنوز این انسان است که باید تصمیم بگیرد چه چیزی ارزش ساخته شدن دارد.
شاید در عصر جدید نرم‌افزار، ارزشمندترین جمله‌ای که یک توسعه‌دهنده می‌تواند بگوید، نه «می‌توانم این را بسازم»، بلکه این باشد:
می‌توانم آن را بسازم؛ اما آیا واقعاً لازم است؟
