مسعود بهرامی
پارادایم جدید توسعه یا فروپاشی مهندسی نرمافزار؟
از سینتکس به معنا؛ تعریف مفهوم Vibe Coding
در سالهای اخیر، اصطلاحی جدید در فضای مجازی و میان توسعهدهندگان پیچیده شده است. : Vibe Coding. این اصطلاح به شکلی توصیفگرانه به روشی از توسعه نرمافزار اشاره دارد که در آن، برنامهنویس دیگر با درگیر شدن در جزئیات ریزِ سینتکس (Syntax)، مدیریت حافظه یا ساختارهای پیچیده الگوریتمی، به کمک ابزارهای هوش مصنوعی مبتنی بر LLMها و با توصیف کردن آنچه میخواهد (با استفاده از زبان طبیعی و پرامپتهای هوشمند)، کدی را تولید میکند. در این حالت، توسعهدهنده بیشتر شبیه به یک رهبر ارکستر یا یک معمار مفهوم عمل میکند تا یک تایپیست کد.
اما این تغییر پارادایم، فراتر از یک ابزار جدید برای افزایش سرعت است. ما با یک تغییر بنیادین در مفهوم نرمافزار و مهندس نرمافزار روبرو هستیم: اگر کد دیگر محصول مستقیم تفکر منطقیِ خطبهخط انسان نباشد، بلکه خروجی احتمالات آماری یک مدل زبانی بزرگ (LLM) باشد، چه اتفاقی برای ماهیت مهندسی نرمافزار خواهد افتاد؟
اگر کد دیگر محصول مستقیم تفکر منطقیِ خطبهخط انسان نباشد، بلکه خروجی احتمالات آماری یک مدل زبانی بزرگ (LLM) باشد، چه اتفاقی برای ماهیت مهندسی نرمافزار خواهد افتاد؟
پارادوکس خواندن؛ آیا توسعهدهنده کدِ تولید شده توسط AI را میخواند؟
شاید یکی از بزرگترین نگرانیهای مهندسان سنتی این باشد که، اگر AI کد را مینویسد، چه کسی آن را درک و نگهداری میکند؟
برای روشن شدن این نگرانی بیاید اینطور به مسئله نگاه کنیم. در فرآیند نرمال موجود در توسعه نرمافزار، نوشتن کد، خود فرآیند درک مسئله است. وقتی شما کد مینویسید، در واقع دارید مدل ذهنی خود را از سیستم روی کاغذ (یا مانیتور) پیاده میکنید. اما در Vibe Coding، یک شکاف (Gap) بین ذهن برنامهنویس و کد تولید شده ایجاد میشود.
نوشتن کد، خود فرآیند درک مسئله است
در اینجا دو سناریو در پیش رو خواهیم داشت:
- سناریوی مهندس هوشمند: توسعهدهنده کد را به عنوان یک پیشنویس میبیند. او کد را با دقت میخواند، آن را نقد میکند و از AI میخواهد اصلاح کند. در اینجا، خواندن کد بخشی از فرآیند بازخورد (Feedback Loop) است.
- سناریوی توسعهدهنده منفعل: توسعهدهنده تنها به خروجی نگاه میکند؛ اگر کد کار میکند، آن را میپذیرد. این خطرناکترین حالت ممکن است. در این سناریو، ما با پدیدهای به نام کدهای جعبه سیاه (Black Box Code) روبرو هستیم؛ کدی که کار میکند، اما هیچ انسانی نمیداند چرا و چگونه کار میکند.
در حال حاضر که مشغول نوشتن این نوشته هستم، شاید بتوانم بگویم که در عصر Vibe Coding، مهارت اصلی از نوشتن کد به کدخوانی و تحلیل انتقادی (Code Auditing) تغییر مییابد. توسعهدهنده آینده، بیشتر شبیه به یک ویراستار ارشد خواهد بود که باید بتواند خطاهای ظریف منطقی را در میان انبوه کدهای تولید شده توسط AI پیدا کند.(سرعت تغییرات در هوش مصنوعی آنقدری زیاد است که خود را ملزوم میدارم که هر چند وقت یکبار تفکر و تجربهی نویی درباره موضوعات داشته باشم!)
در حال حاضر که مشغول نوشتن این نوشته هستم، شاید بتوانم بگویم که در عصر Vibe Coding، مهارت اصلی از نوشتن کد به کدخوانی و تحلیل انتقادی (Code Auditing) تغییر مییابد.
بازگشت به مستندسازی؛ آیا نیاز به داکیومنتیشن به شدت افزایش مییابد؟
این بخش رو کمی با احتیاط مینویسم. تا مجالی پیدا بشود که بیشتر توضیح بدهم! شما هم با احتیاط و دقت بیشتر بخوانید ولی نترسید و نهراسید😊
به عنوان یک برنامهنویس بخش بزرگی از وقت افراد در حین توسعه نرمافزار صرف خواندن کد موجود، جهت درک آن است. برای اینکه بتوانید تغییرات جدید را به یک سرویس، متد، کلاس یا هر تکه کدی اضافه کنید، فهمیدن کد فعلی حیاتی است.بخشی از چالش برانگیز بودن و وقت گیر بودن (time consuming) این موضوع پیچیدگی ذاتی صورت مسئله است. مثلا محاسبه حقوق ذاتا مسئله پیچیدهای است و این پیچیدگی دو دومین خود مسئله است. عامل دیگری که به این مسئله دامن میزند، دستخط های مختلف برنامهنویس(ان) در طول زمان، نسبت به افزودن و تغییرات در آن ماژول است. عامل ساده که علیرغم اهمیت و تاثیر بالای آن کمتر مورد توجه قرار میگیرد، فراموشی است، به وفور دیده میشود که یک ماژول، متد، سرویس و منطقی در کد وجود دارد که نه توسعهدهندگان و نه محصولچیها کسی از وجود آن خبر ندارد و نمیدانند چه منطقی پشت آن نهفته است. حتی ممکن است که تاریخچه گیت(Git History) آن کد کاملا به یکسری داستانهای کاربری بر روی جیرا هم متصل باشد!(برایتان آشنا نیست؟!). در گذشته، مستندات ضعیف باعث میشد که فهم سیستم دشوار شود. در عصر AI، ما با یک پارادوکس روبرو هستیم. اگر AI کد را میزند، آیا نیاز به مستندات کم میشود؟ خیر، دقیقاً برعکس.
در Vibe Coding، مستندات دیگر فقط برای انسانها نیستند؛ مستندات برای Context Window مدلهای AI هستند. برای اینکه یک AI بتواند در مراحل بعدی، تغییرات را در سیستم اعمال کند، باید از قوانین کسبوکار (Business Logic) و معماری سیستم آگاه باشد.
استراتژی جدید: مستندسازی به عنوان پرامپت (Documentation as Prompting)
به نظر میرسد ما به سمتی میرویم که در آن مستندات، به جای متون طولانی و خشک، به صورت ساختارهای دادهای از جمله فایلهای Markdown یا Schemaها، در دسترس خواهند بود تا AI بتواند آنها را به عنوان مرجع حقیقت (Source of Truth) بخواند. توسعهدهنده مدام از AI میخواهد که:
- این تغییر را اعمال کن و بلافاصله مستندات معماری را بروزرسانی کن.
- یک دیاگرام از جریان دادههای جدید بر اساس این کد تولید کن.
در واقع، مستندسازی از یک وظیفه پس از توسعه به یک بخش جداییناپذیر از فرآیند توسعه تبدیل میشود. اگر مستندات بروز نباشند، AI در پرامپتهای بعدی دچار توهم (Hallucination) شده و سیستم را خراب خواهد کرد.
رفتن به سمت Comprehensive Documentation؟
از آنجایی که مفهوم مالکیت کد در اینجا دستخوش تغییراتی بنیادی خواهد شد، و از طرف دیگر چون کدهای تولید شده نه توسط برنامهنویس(اکثرا) که توسط ابزار تولید میشود، لزوم داشتن مستندات فنی رفته رفته امری ضروری و باارزش تلقی خواهد شد. تا آنجایی که به بخشی از تعریف شرایط اتمام کار (Definition of Done (DoD))) تبدیل خواهد شد. انتظار میرود که پس از کوتاه مدت سیستم با یکسری مستندات قطوری همراه شود. به دلیل سرعت بسیار بالا، دستور پذیری کامل(برخلاف توسعهدهندگان که اغلب با مالکان محصول بر سر فیچرهای درخواستی از نقطه نظرات مختلف بحث و تبادل نظر میکنند) و همینطور راحتی در دسترس بودن، نسخههای اولیه تولید شده توسط AI مسئله لزوما غیر صحیحی را به روش (نسبتا) درستی پیادهسازی کنند. نتیجه اینکه در کوتاه مدت، شما با درک درست از خواستههایتان مجدد از AI بخواهید که تغییرات جدید را اعمال کند(اگر از توسعهدهنده دیگری بخواهید، اوضاع کمی بغرنج خواهد شد). این بدین معنی است که نسخههای مستندات نیز مدام در حال تغییر و بروزرسانی هستند. انتظار میرود که مستندات قطور کمکم تبدیل به ارزش شوند!. مراقب باشید.
Working (Black-Box) Software?
خیلی به ندرت پیش میآید که افراد تا مجبور نشوند، کد موجود را بخوانند. از معماری و طراحی سیستم در عمل و نه فقط روی کاغذ و درودیوار و وایتبرد سر در بیاورند. حتی اگر این کد را خود آنها قبلا نوشته باشند. تصور کنید کد تولید شده توسط تیم دیگری را قرار باشد تحویل بگیرید و از امروز مسئول نگهداری و همینطور توسعه آن شوید. با چه چالشها و نگرانیهایی مواجه خواهید شد. چه سوالاتی به ذهنتان متبادر میشود. در حقیقت شما با یکسری از Unknown-Unknowns مواجه خواهید. علاوه بر اینکه باید بر روی کسبوکار و دومین آن سوار باشید، باید کد را کامل بشناسید.
خب حالا تصور کنید که شما بصورت Vibe Coding شروع به توسعه سرویس و محصول خود کردهاید. احتمال اینکه همان توسعهدهندهای که تا دیروز کدی را تا مجبور نبود نمیخواند، از امروز بشیند و تمام کدهای تولید شده توسط AI را بخواند، بسیار غیر محتمل است. در نتیجه شما در بهترین حالت با یک نرمافزار کارکننده سروکار دارید که بصورت جعبهسیاه (Working Black-Box Software) برای شما به عنوان مالک آن وجود خواهد داشت.
بدیهی است که سوالات و چالشهای بسیار حیاتی در اینجا میتواند مطرح شود:
- تا چه میزان برای نگهداری و توسعه سیستم شما وابسته به ابزار AI(حتی وندور خاصی از AI) وابسته است؟
- در صورتی که نیاز به تغییر توسط توسعهدهنده و رفع باگ باشد، اگر او از ساختار داخلی کد و پیادهسازی باخبر نباشه و با همان رویکرد قبلی، یعنی عدم دنبال کردن کدها مگر به اجبار، این فرآیند چقدر زمانبر و حتی بحرانزا خواهد بود؟
- چه بر سر افراد به عنوان تیم توسعه خواهد آمد؟ آیا vibe ایجاد شده توسط یک نفر، قابل پذیرش و دنبال کردن توسط فرد دیگری هم هست یا خیر؟
مسئله مالکیت (Ownership)؛ وقتی خالق، کدنویس نیست
این یکی از پیچیدهترین سوالات حقوقی و اخلاقی است: مالک یک سرویس که توسط AI نوشته شده، کیست؟
اگر توسعهدهنده فقط حس و حال (Vibe) یا دستور کلی را داده باشد، آیا او مالک منطق بیزنس است؟ در دنیای حرفهای، مالکیت کد به مسئولیت (Accountability) گره خورده است.. گر یک سیستم بانکی توسط AI نوشته شود و دچار خطا شود، ما نمیتوانیم از AI شکایت کنیم. بنابراین، مالکیت همواره با مسئولیت همراه است. توسعهدهنده، حتی اگر مستقیماً کد را تایپ نکرده باشد، متولی (Steward) آن سیستم است. او مسئولیت انتخاب مدل، طراحی پرامپت، و نهایتاً تایید خروجی را بر عهده دارد. مالکیت در عصر AI، از مالکیت بر کلمات به مالکیت بر تصمیمات طراحی تغییر مییابد.
مالکیت در عصر AI، از مالکیت بر کلمات به مالکیت بر تصمیمات طراحی تغییر مییابد.
چه بر سر ارزش مهم مالکیت جمعی (Collective Ownership Value) خواهد آمد؟
مجدد مسئله مالکیت کد، از نقطه نضر تیم توسعه و سازمان ایندفعه! یکی از سنجهها و متریکهای اساسی جهت متر کردن سلامت تیمنرمافزاری و بهطبع آن سلامت خروجی تیم، داشتن حس مالکیت جمعی و همگانی افراد نسبت به محصولی بود که مسئول توسعه آن هستند. این بدین معنا است که نرمافزار به یک سری جزیره تبدیل نمیشود که هر کسی در تیم خود را مسئول تنها آن بخش بداند و نسبت به سایر بخشها مسئولیت و احساسی نداشته باشد.
حالا اما با حضور AI و نوشتن کد توسط آنها این امر مطمئنا دستخوش تغییرات اساسی خواهد شد. حتی توسعهدهنده هم آن حسی که نسبت به ایجاد و نوشتن فیچرهای یک محصول را داشت نیز نسبت به قبل نداشته باشد. شاید نرمافزار تولید شده توسط این تیمها شبیه بچه سر راهی شود(تئوری توطئه نسبت به AI و LLMها و Vibe Coding).
اما حقیقتا، مسئله مالکیت و حس مالکیت جمعی و تیمی نسبت به سرویسهای توسعه داده شده توسط این ابزارها دستخوش تغیرات بنیادین خواهد شد. فکر میکنم که بیشتر به سمت سرویسهایی خواهیم رفت که یک نفره توسعه داده خواهند شد و شاید تیم توسعه شامل توسعهدهدگان، به آن صورت که امروز نگاه میکنیم نداشته باشیم(هر چند عقیده دارم که تا رسیدن به این نقطه، به نوعی که واقعا کارا باشد، نه صرفا یک هیجان باشد، راه زیادی در پیش داریم. علاوه بر عوامل تکنیکال، فاکتورهای بسیار مهم اقتصادی و حاکمیت هم بیشک بسیار موثر هستند). اما خب، ضروری است که جهت آماده شدن برای این شرایط باید اول فرضیات فعلی خود را مجدد مرور و باز تعریف کنیم! آیا شما آماده هستید!؟
پاسخ به تغییرات (Responding to Change) و میراث پرامپتها
بزرگترین قدرت نرمافزار، قابلیت تغییر است. Vibe Coding این سرعت را به شدت بالا میبرد، اما یک چالش استراتژیک ایجاد میکند: انتقال دانش (Knowledge Transfer).
فرض کنید تقی، با یک سری پرامپتهای خاص و یک Vibe مشخص، یک سیستم پیچیده را با AI میسازد. حالا مهندس تقی از تیم خارج میشود و شهین جایگزین او میشود.
مسئله اصلی شهین در سازمان و با این کد به ارث رسیده (Legacy) این است که چگونه بفهمد سیستم چیست و چطور کار میکند و چه معماری دارد و هزاران سوال دیگری که موقع اضافه شدن یک برنامهنویس به تیم با آن مواجه بودید؟ پرامپتهای قبلی، روح سیستم هستند. اگر این پرامپتها و تاریخچه گفتگوها (Chat History) مستند نشده باشند، شهین در میان کدی که کار میکند اما منطق پشت آن مفقود شده، سردرگم خواهد شد.
راهکار: مدیریت میراث پرامپت (Prompt Heritage Management)
برای اینکه سیستمها در برابر تغییر پرسنل مقاوم باشند، ما باید به جای ذخیره کردن فقط کد، تاریخچه تصمیمگیری را ذخیره کنیم. این یعنی:
- ذخیره پرامپتهای کلیدی که منجر به تصمیمات معماری شدهاند.
- نگهداری از نقشه راه منطقی (Logical Roadmap) که نشان میدهد هر تغییر بر اساس چه نیاز بیزنسی توسط AI انجام شده است.
- تبدیل Vibe بهSpec (مشخصات فنی). مهندس باید بتواند آن حس و حال و دستورات ذهنی را به گونهای ثبت کند که مهندس بعدی بتواند با همان فاز و با دقت بالا، کار را ادامه دهد.
بازتعریف مهندس نرمافزار
Vibe Coding به معنای پایان مهندسی نیست، بلکه به معنای پایان تایپ کردن است. ما در حال ورود به دورانی هستیم که در آن قدرت تفکر انتزاعی (Abstract Thinking) و توانایی مدیریت پیچیدگی (Complexity Management)*، بسیار مهمتر از دانستن دستورات یک زبان برنامهنویسی است.
مهندس آینده، کسی نیست که میداند چگونه یک حلقه `for` بنویسد، بلکه کسی است که میداند چگونه یک سیستم توزیعشده را با استفاده از زبان طبیعی و ابزارهای AI، طراحی، مستند، کنترل و توسعه دهد. در این عصر، Vibe شما، همان معماری شماست. اگر بتوانید Vibe درستی از سیستم داشته باشید، AI ابزار شما خواهد بود؛ در غیر این صورت، شما بردهی کدهایی خواهید بود که خودتان هم آنها را نمیفهمید.
