یک داشبورد SaaS برای مدیریت سفارش‌های فروشگاه آنلاین را در 48 ساعت اول با وایب کدینگ ساختیم؛ در هفته‌ی سوم کاربر اول شکایت کرد و فهمیدیم 80 درصد مسیر را با سرعت باورنکردنی طی کرده‌ایم، اما 20 درصد باقی‌مانده — امنیت، معماری و نگهداری — دقیقاً همان مهارت‌هایی است که این روش به‌جای آموزش، پنهان میکند.
وایب کدینگ چیست و چه فرقی با کدنویسی سنتی دارد؟#
وایب کدینگ (Vibe Coding) روش توسعه‌ای است که در آن نیت و جریان کار را به مدل زبانی بزرگ (LLM) منتقل می‌کنی و خروجی را بازبینی می‌کنی، بدون نوشتن خطبهخط کد. آندری کارپاتی (Andrej Karpathy) این اصطلاح را رایج کرد و خودش آن را برای پروتوتایپ و پروژه‌های کوچک توصیف کرد، نه سیستم‌های تولیدی.
ریشه‌ی اصطلاح و تعریف کارپاتی: تمرکز بر نیت به‌جای جزئیات#
کارپاتی در پستی توضیح داد که در پروژه‌های شخصی از این روش استفاده میکند: به‌جای ذهنیت مهندسی، «حس و حال» (vibe) کلی را به مدل می‌گوید و اجازه می‌دهد کد بنویسد. نکته‌ای که معمولاً در بازگشت‌های بعدی از دست می‌رود: کارپاتی این روش را در بستر پروژه‌های شخصی و بدون بازبینی کد به کار می‌برد، نه در سیستم‌های تولیدی. کسی که وایب کدینگ را مستقیم به محیط تولید می‌برد، از خودِ کارپاتی هم جلوتر رفته — و نه به‌معنای مثبت.
تفاوت با توسعه سنتی: چه چیزی حذف میشود و چه چیزی اضافه میشود#
در توسعه سنتی، برنامهنویس همزمان با نوشتن کد، معماری را تصمیم می‌گیرد، نام‌گذاری میکند، و تست می‌نویسد. در وایب کدینگ، نوشتن کد حذف میشود اما دو کار اضافه میشود: پرامپت‌نویسی دقیق و بازبینی انسانی خروجی. اگر بازبینی نکنی، عملاً کد را به‌صورت جعبه‌سیاه (Black Box) در محصولت جا می‌دهی.
حذف نوشتن کد، حذف فهمیدن کد نیست. این اشتباه، گران‌ترین سوءبرداشتی است که از وایب کدینگ میشود.
تفاوت با No-Code و Low-Code: وایب کدینگ هنوز کد تولید میکند#
پلتفرمهای No-Code اصلاً کد تولید نمی‌کنند؛ شما در چارچوب پلتفرم کار میکنید و خروجی قابل انتقال نیست. وایب کدینگ کد واقعی تولید میکند — فایل‌هایی که در ویرایشگر باز می‌شوند، قابل نسخه‌بندی در Git هستند، و روی هر سروری قابل دیپلوی (Deploy)اند. همین کد واقعی، دیباگ و نگهداری هم می‌طلبد.
در پروژه‌ی داشبورد، اولین پرامپت این بود: «یک داشبورد با React و Tailwind بساز که لیست سفارش‌ها را از یک API فیک بخواند، فیلتر وضعیت داشته باشد، و در هر ردیف دکمه‌ی تغییر وضعیت بگذارد.» نتیجه در 20 دقیقه قابل‌مشاهده بود. اما همان 20 دقیقه، بدهی فنی‌ای ساخت که هفته‌ی سوم سر رسید.
مقایسه عملی Cursor، Lovable و Replit: کدام برای چه کسی؟#
Cursor برای کسی است که حداقل منطق برنامهنویسی را می‌فهمد و کنترل دقیق‌تر می‌خواهد؛ Lovable برای خروجی سریع بدون لمس کد؛ Replit برای محیط ابری یکپارچه با دیپلوی فوری. انتخاب ابزار اشتباه، هزینه‌ی مهاجرت بعدی می‌سازد — و آن هزینه معمولاً بیشتر از صرفه‌جویی اولیه است.
جدول مقایسه‌ای: نوع خروجی، سطح دانش لازم، امکان ویرایش دستی، هزینه و محدودیت‌ها#
| معیار | Cursor | Lovable | Replit |
|---|---|---|---|
| نوع خروجی | کد واقعی در ویرایشگر محلی | کد واقعی + محیط بصری | کد واقعی در فضای ابری |
| حداقل دانش لازم | مبتدی تا متوسط | بدون دانش کد | مبتدی |
| ویرایش دستی کد | آسان (ویرایشگر کامل) | محدود | آسان |
| دیپلوی | دستی | خودکار | خودکار |
| محدودیت اصلی | نیاز به محیط محلی | وابستگی به پلتفرم | محدودیت منابع ابری |
تجربه‌ی واقعی: چرا در پروژه‌ی داشبورد، Cursor انتخاب شد و Lovable کنار گذاشته شد#
وقتی کاربر اول شکایت کرد که فیلترها بعد از تغییر وضعیت سفارش ریست می‌شوند، در Lovable دسترسی به منطق داخلی کامپوننت محدود بود. در Cursor همان خط را باز کردیم، علت را دیدیم، و پرامپت اصلاحی دادیم. امکان ویرایش مستقیم کد — نه سرعت اولیه — تعیین‌کننده‌ی انتخاب ابزار است.
اشتباه رایج: شروع با ابزار اشتباه و هزینه‌ی مهاجرت بعدی#
الگویی که در پروژه‌های اعضای کامیونیتی اسکول مکرر دیده شده: فردی بدون دانش فنی با Lovable شروع میکند، MVP را می‌سازد، بعد بهمحض نیاز به تغییر منطق، گیر میکند و مجبور میشود از صفر با Cursor شروع کند. این مهاجرت، همان 48 ساعت اول را دوباره هزینه میکند — و این‌بار با ناامیدی بیشتر.
پرامپت‌نویسی برای کد تمیز: سه اشتباه رایج#
پرامپت مبهم، بدون محدودیت فنی و بدون تعریف ورودی/خروجی، کد ناپایدار و غیرمقیاس‌پذیر تولید میکند. پرامپت خوب مثل یک شرح‌کار (Brief) مهندسی است: چارچوب را مشخص میکند، تصمیمات معماری را به مدل واگذار نمی‌کند، و مرزهای کیفیت را از قبل تعیین میکند.
اشتباه اول: توصیف نتیجه بدون توصیف محدودیت‌ها#
«داشبوردی بساز که سفارش‌ها را نشان دهد» پرامپتی است که خروجی بی‌کیفیت می‌سازد. محدودیت‌ها را بگویید: چه فریمورکی، چه ساختار داده‌ای، چه رفتارهایی در حالت خالی یا خطا باید وجود داشته باشد. مدل زبانی بزرگ بدون محدودیت، تصمیمات معماری را خودش می‌گیرد — و معمولاً بد.
اشتباه دوم: یک پرامپت بلند به‌جای چند پرامپت مرحله‌ای#
پرامپت 500 کلمه‌ای که همزمان فرانت‌اند، بک‌اند، احراز هویت و دیتابیس را توصیف میکند، کد ناپایدار تولید میکند. مرحله‌ای کار کنید: اول ساختار داده، بعد API، بعد کامپوننت لیست، بعد فیلترها. هر مرحله را جدا بازبینی کنید.
اشتباه سوم: نادیده گرفتن context و فایلهای موجود پروژه#
وقتی پروژه بزرگ میشود، مدل زبانی بدون context فایلهای قبلی، نام‌گذاری‌های موجود و ساختار پوشه‌ها را نمی‌داند. نتیجه: کد تولیدشده با بقیه‌ی پروژه ناسازگار است. در Cursor، فایلهای مرتبط را به context اضافه کنید یا از قابلیت @file استفاده کنید.
الگوی تکرارشونده از پروژه‌های کامیونیتی اسکول: پرامپت‌هایی که واقعاً کار کردند#
- تعریف ساختار داده قبل از هر درخواست UI: «این schema را برای مدل سفارش تعریف کن، بعد کامپوننت لیست را بر اساس آن بساز»
- محدودیت فنی صریح: «از React Hook Form استفاده کن، نه state دستی»
- تست‌محور: «این تابع را بنویس، بعد 3 تست واحد (Unit Test) برای آن بنویس که حالت خالی، حالت خطا و حالت موفق را پوشش دهد»
آیا بدون دانش فنی می‌توان محصول قابل‌استفاده ساخت؟#
بله، تا سطح MVP و پروتوتایپ قابل‌نمایش به کاربر اولیه. اما بهمحض ورود داده حساس، احراز هویت چندمرحله‌ای یا ترافیک واقعی، بدون فهم فنی نمی‌توانید مشکل را تشخیص دهید — و بدتر: نمی‌فهمید که مشکلی وجود دارد.
مرز عملی: چه چیزی را واقعاً می‌سازید و چه چیزی را نمی‌سازید#
می‌سازید: پروتوتایپ، داشبورد ساده، صفحه‌ی فرود، فرم ثبت‌نام. نمی‌سازید: سیستم پرداخت با PCI Compliance، احراز هویت چندعاملی، API با مقیاس‌پذیری افقی، یا هر چیزی که دادهی حساس دارد.
هزینه و زمان ساخت MVP با وایب کدینگ#
برای پروتوتایپ اولیه، بازه‌ی چند ساعت تا چند روز واقع‌بینانه است. اما «قابل ارائه به کاربر واقعی» هفته‌ها زمان می‌برد — نه به‌خاطر نوشتن کد، بلکه به‌خاطر بازبینی، دیباگ و اصلاح معماری. هزینه‌ی واقعی در نگهداری و بازنویسی بعدی ظاهر میشود.
روایت پروژه (ادامه): هفته‌ی اول — همه‌چیز کار می‌کرد؛ هفته‌ی سوم — کاربر اول شکایت کرد#
هفته‌ی اول: داشبورد روی سرور محلی بالا بود، فیلترها کار می‌کردند، و برای نمایش به همکاران کافی بود. هفته‌ی سوم: یک کاربر واقعی با 200 سفارش ورود کرد، فیلترها ریست می‌شدند، و فرم ورود بدون اعتبارسنجی سمت سرور بود. وایب کدینگ در همان لحظه از «سرعت» به «بحران» تبدیل شد.
دیباگ و امنیت: نقاط شکست کدهای تولیدشده با هوش مصنوعی#
مدل‌های زبانی بزرگ بخش عمده‌ای از کدهای ساده و تکراری را تولید می‌کنند، اما در مدیریت معماری پیچیده و رفع خطاهای منطقی عمیق همچنان نیاز به نظارت انسانی دارند. بدون بازبینی امنیتی، آسیب‌پذیری‌های رایج مثل تزریق SQL و اسکریپت‌نویسی بین‌سایتی در کد باقی می‌مانند.
روش‌شناسی دیباگ کدهای AI: اول خطا را بازتولید کن، بعد پرامپت اصلاحی بده#
- خطا را دقیق بازتولید کن: چه ورودی‌ای، چه خروجی‌ای، چه انتظاری
- محل خطا را در کد پیدا کن — نه با حدس، با خواندن
- پرامپت اصلاحی بنویس که فقط همان بخش را هدف بگیرد، نه کل فایل
- بعد از اصلاح، دوباره بازتولید کن تا مطمئن شوی خطا رفته و خطای جدید نیامده
سه آسیب‌پذیری امنیتی که در کدهای وایب‌کدینگ مکرر دیده میشود#
- تزریق SQL (SQL Injection): کوئری‌های ساختاریافته با رشته‌های خام، بدون prepared statement
- اسکریپت‌نویسی بین‌سایتی (XSS): رندر ورودی کاربر بدون sanitize در فرانت‌اند
- احراز هویت ضعیف: توکن‌های JWT بدون اعتبارسنجی امضا یا بدون انقضا (Expiration)
این سه الگو در پروژه‌های اعضای کامیونیتی اسکول مکرر تکرار شده‌اند — نه به‌خاطر بدی ابزار، بلکه به‌خاطر نبود بازبینی انسانی.
بدهی فنی (Technical Debt): هزینه‌ی پنهانی که در ماه ششم مشخص میشود#
کدی که AI تولید کرده و بازبینی نشده، معمولاً نام‌گذاری ناسازگار، تکرار منطق، و وابستگی‌های پنهان دارد. تا ماه اول مشکلی نیست. ماه ششم، وقتی یک فیچر جدید اضافه میکنید، سه کامپوننت قدیمی می‌شکنند. این هزینه‌ی پنهان است.
روایت پروژه (ادامه): کشف آسیب‌پذیری در فرم ورود و تصمیم برای بازنویسی#
در همان هفته‌ی سوم، متوجه شدیم فرم ورود بدون اعتبارسنجی سمت سرور است و ورودی کاربر مستقیماً در کوئری دیتابیس می‌رود. تصمیم گرفتیم کل لایه‌ی احراز هویت را بازنویسی کنیم — کاری که با وایب کدینگ اولیه 20 دقیقه طول کشیده بود، اما بازنویسی امن آن با نظارت انسانی چند روز.
چه پروژه‌هایی برای وایب کدینگ مناسب نیستند؟#
پروژه‌هایی با دادهی حساس (مالی، بهداشتی)، معماری توزیع‌شده، نیاز به SLA بالا، یا تیمی که قرار است کد را بلندمدت نگهداری کند — وایب کدینگ در این موارد هزینه‌ی پنهان می‌سازد که در لحظه‌ی شروع نامرئی است.
فهرست معیارهای «نه»: چه زمانی باید از وایب کدینگ دست بردارید#
- دادهی مالی یا بهداشتی با الزامات انطباق (Compliance)
- معماری میکروسرویس یا سیستم توزیع‌شده
- نیاز به SLA بالا (در دسترس بودن بیش از 99 درصد)
- تیمی که قرار است کد را بیش از 6 ماه نگهداری کند
- اپلیکیشن با عملکرد بومی (Native) یا دسترسی به سختافزار
پروژه‌هایی که با وایب کدینگ شروع شدند و بعد بازنویسی شدند: الگوی تکرارشونده#
الگویی که در چند پروژه‌ی اعضای کامیونیتی اسکول دیده شده: MVP سریع با AI ساخته میشود، کاربر واقعی وارد میشود، خطاهای امنیتی و عملکردی سر برمی‌دارند، و تیم مجبور میشود بخش‌های کلیدی را بازنویسی کند. بازنویسی معمولاً 2 تا 3 برابر زمان ساخت اولیه طول می‌کشد.
روایت پروژه (پایان): تصمیم برای استخدام توسعهدهنده و هزینه‌ی واقعی این مهاجرت#
در پروژه‌ی داشبورد، بعد از کشف آسیب‌پذیری، یک توسعهدهندهی فول‌استک استخدام کردیم. هزینه‌ی واقعی مهاجرت نه در حقوق، بلکه در زمان بود: دو هفته صرف شد تا توسعهدهنده کد تولیدشده با AI را بفهمد، ساختار را بازچینی کند، و لایه‌ی امنیتی را پیاده‌سازی کند. این هزینه‌ای است که وایب کدینگ در 48 ساعت اول پنهان کرده بود.
نقش توسعهدهنده در عصر وایب کدینگ#
توسعهدهندهی سنتی حذف نمی‌شود؛ تبدیل میشود به کسی که معماری را طراحی میکند، خروجی AI را بازبینی میکند، و بدهی فنی را مدیریت میکند. این سه مهارت — معماری، بازبینی، مدیریت بدهی — دقیقاً همان چیزهایی‌اند که وایب کدینگ نمی‌تواند جایگزینشان کند.
از کدنویس به بازبین و معمار: تغییر نقش عملی#
در پروژه‌ی داشبورد، توسعه‌دهنده‌ای که استخدام کردیم کمتر از قبل کد نوشت و بیشتر از قبل خواند، تصمیم گرفت، و بازبینی کرد. نقش «معمار و بازبین» جای «نویسنده» را گرفت. این تغییر نقش، برای کارآفرینان هم پیام دارد: اگر فقط به‌دنبال سرعت هستید، وایب کدینگ کافی است؛ اگر به‌دنبال بقا هستید، بازبین لازم است.
مهارت‌هایی که ارزششان بیشتر میشود: معماری، امنیت، تست‌نویسی#
- معماری نرم‌افزار: تصمیم‌گیری درباره‌ی مرزها، الگوهای طراحی، و مقیاس‌پذیری
- امنیت: شناخت آسیب‌پذیری‌های رایج و بازبینی کد تولیدشده
- تست‌نویسی: نوشتن تست‌هایی که رفتار سیستم را تضمین کنند، نه فقط خوش‌بینانه‌ترین مسیر را
توصیه‌ی عملی برای کارآفرینان: چه زمانی توسعهدهنده استخدام کنید#
وقتی کاربر واقعی وارد سیستم شد، دادهی حساس رد و بدل شد، یا ترافیک از حالت پروتوتایپ خارج شد — آن لحظه، وایب کدینگ بهتنهایی کافی نیست. لحظه‌ی دست‌کشیدن را از قبل تعریف کنید.
وایب کدینگ ابزار قدرتمندی است، اما برای مرحله‌ای از پروژه که معماری و امنیت هنوز وارد بازی نشده‌اند. اگر می‌خواهید ایده‌تان را بدون کدنویسی به محصول تبدیل کنید و همزمان بفهمید کجا باید متوقف شوید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در اسکول دقیقاً روی همین مرز کار میکند — نه اینکه فقط سرعت بدهد، بلکه بگوید کجا ترمز کنید.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.