وایب کدینگ (Vibe Coding) وعده‌ی ساخت اپلیکیشن بدون نوشتن کد است. اما وقتی 3 هفته بعد از انتشار، باگی در کدی ظاهر شود که خودت ننوشتی و نمی‌فهمی، بدون قضاوت فنی مینیمال (Minimal Technical Judgment) گیر می‌کنی. این مقاله روایت واقعی یک پروژه از پرامپت اول تا بحران نگهداشت است — نه تبلیغ ابزار، نه فهرست ترفندها.
وایب کدینگ چیست: از توییت کارپاتی تا اپلیکیشن واقعی#
وایب کدینگ روشی است که در آن به‌جای نوشتن کد، محصول را به زبان طبیعی توصیف می‌کنی و هوش مصنوعی کد قابل اجرا تولید میکند. اصطلاح را اندراج کارپاتی در فوریه 2025 ابداع کرد و به‌سرعت به واژه‌ی عمومی تبدیل شد.
کارپاتی در توییتش نوشت که در این روش «کاملاً با حس پیش می‌روی، نمایی را در آغوش می‌گیری و فراموش می‌کنی که کد اصلاً وجود دارد» — یعنی پرامپت می‌زنی، خروجی را اجرا میکند، و اگر کار کرد، ادامه می‌دهد. این تعریف اولیه، بیشتر از آنکه یک روش ساخت باشد، یک حالت ذهنی است.
خاستگاه اصطلاح و تعریف دقیق کارپاتی#
کارپاتی «vibe coding» را نه یک متدولوژی، بلکه یک سبک کار توصیف کرد: تو ایده را می‌گویی، مدل کد را می‌نویسد، تو اجرا می‌کنی، و اگر خطا داد، خطا را به مدل برمی‌گردانی. چرخه‌ی ساده‌ای که در آن «درک عمیق کد» حذف شده است.
اما همین سادگی، نقطه‌ی ضعف را پنهان میکند. وقتی چرخه شکست می‌خورد — مثلاً باگی که مدل نمی‌فهمد از کجاست — همان «حس» دیگر کافی نیست.
وایب کدینگ پرامپت‌نویسی نیست — سه مهارت پنهان#
اکثر راهنماها وایب کدینگ را به «خوب پرامپت بنویس» تقلیل میدهند. این تقلیل خطرناک‌تر از آن است که به‌نظر می‌رسد، چون خواننده را متقاعد میکند که تنها مهارت لازم، صیقل دادن جملات است. سه مهارت پنهان وجود دارد که تعیین‌کننده‌ی موفقیت یا شکست‌اند:
- انتخاب معماری: قبل از پرامپت اول باید بدانی اپ چند صفحه دارد، داده‌ها کجا ذخیره می‌شوند، و آیا نیاز به احراز هویت دارد یا نه.
- بازخوانی خروجی: کد تولیدشده را باید حداقل یک‌بار بخوانی و بفهمی چه میکند. نه خط‌به‌خط، بلکه ساختاری.
- مدیریت scope: هر بار که «یک قابلیت کوچک» اضافه می‌کنی، ممکن است معماری را بشکنی.
تفاوت «ساخت» و «نگهداشت» در وایب کدینگ#
ساخت حداقل محصول قابل‌ارائه (MVP) با وایب کدینگ ممکن است دو هفته طول بکشد. نگهداشت همان MVP، اگر قضاوت فنی نداشته باشی، نامحدود است. اکثر راهنماها دقیقاً در نقطه‌ی «منتشر شد، تمام» متوقف می‌شوند. این مقاله از همان‌جا شروع میکند.
وایب کدینگ در برابر نودکد و لوکد: تفاوت در مالکیت کد#
فرق وایب کدینگ با نودکد و لوکد در مالکیت کد و انعطاف‌پذیری نهایی است. نودکد خروجی بدون کد می‌دهد، لوکد کد کم می‌خواهد، و وایب کدینگ کد کامل تولید میکند ولی کاربر آن را نمی‌نویسد.
جدول مقایسه‌ای: نودکد، لوکد، وایب کدینگ، برنامه‌نویسی سنتی#
| معیار | نودکد | لوکد | وایب کدینگ | برنامه‌نویسی سنتی |
|---|---|---|---|---|
| ورودی کاربر | کلیک و کشیدن | کلیک + کد کم | پرامپت زبان طبیعی | کدنویسی کامل |
| خروجی | اپلیکیشن در پلتفرم | اپلیکیشن + کد محدود | کد کامل قابل export | کد کامل |
| مالکیت کد | معمولاً نه | محدود | بله، کامل | بله، کامل |
| انعطاف‌پذیری | محدود به پلتفرم | متوسط | بالا (با دانش فنی) | نامحدود |
| مناسب برای | فرم، لندینگ، اتوماسیون ساده | داشبورد، CRUD ساده | MVP سریع با منطق سفارشی | محصول نهایی مقیاس‌پذیر |
چه زمانی نودکد بهتر از وایب کدینگ است؟#
اگر فقط یک فرم ثبت‌نام، یک لندینگ‌پیج، یا یک اتوماسیون ساده نیاز داری، نودکد سریع‌تر و کم‌ریسک‌تر است. وایب کدینگ در این موارد، کدی تولید میکند که تو باید بخوانی و بفهمی — در حالی که نودکد اصلاً کدی نشان نمی‌دهد.
چه زمانی وایب کدینگ بر نودکد برتری دارد؟#
وقتی منطق تجاری سفارشی داری، نیاز به export کد داری، یا باید با APIهای خاص یکپارچه شوی. نودکد در این نقطه‌ها به دیوار می‌خورد؛ وایب کدینگ هنوز کار میکند چون کد واقعی تولید میشود.
ابزارهای وایب کدینگ: انتخاب بر اساس سطح فنی#
برای شروع وایب کدینگ، انتخاب ابزار باید بر اساس سطح فنی فعلی باشد، نه تبلیغات. Lovable و Bolt.new ساده‌ترین شروع برای کسی‌اند که هیچ کد نمی‌داند؛ Cursor مناسب کسی است که کمی کد می‌فهمد و می‌خواهد کنترل بیشتری داشته باشد.
مقایسه ابزارها#
| ابزار | پروفایل کاربر | خروجی | محدودیت نسخه رایگان |
|---|---|---|---|
| Lovable | بدون دانش فنی | اپلیکیشن React + Supabase | تعداد پروژه‌های محدود |
| Bolt.new | بدون دانش فنی | اپلیکیشن Full-stack | تعداد پرامپت روزانه محدود |
| v0 by Vercel | طراح/توسعه‌دهنده | کامپوننت React | تعداد درخواست محدود |
| Replit Agent | دانش فنی متوسط | پروژه کامل قابل deploy | زمان اجرا محدود |
| Cursor | دانش فنی متوسط به بالا | ویرایش مستقیم کد در IDE | تعداد درخواست AI محدود |
الگوی انتخاب بر اساس سطح فنی#
سه سطح وجود دارد:
- صفر دانش فنی: Lovable یا Bolt.new. همه‌چیز در مرورگر، deploy خودکار، بدون نیاز به IDE.
- دانش مفهومی: Cursor با AI. می‌دانی API چیست، schema چیست، اما نمی‌توانی خودت بنویسی.
- دانش عملی: Cursor + Model Context Protocol (MCP). پروتکلی که ابزارهای خارجی را به هوش مصنوعی وصل میکند و کنترل کامل می‌دهد.
Model Context Protocol (MCP) چیست؟#
MCP یک استاندارد باز است که به مدل هوش مصنوعی اجازه می‌دهد با ابزارها و منابع خارجی (دیتابیس، فایل، API) تعامل کند. اگر در Cursor میخواهی هوش مصنوعی مستقیماً روی فایل‌های پروژهات کار کند، MCP پل ارتباطی است. برای مبتدی لازم نیست؛ برای کسی که scope پروژه‌اش از چند فایل فراتر رفته، ضروری میشود.
ساخت MVP با وایب کدینگ: روایت یک پروژه‌ی واقعی#
ساخت MVP با وایب کدینگ معمولاً 2 تا 4 هفته کاری زمان می‌برد. شرط اصلی، شکستن پرامپت به تغییرات کوچک و بازخوانی خروجی در هر مرحله است. پروژه‌ی زیر یک اپ رزرو وقت با Lovable است.
گام‌به‌گام ساخت — روایت پروژه‌ی اپ رزرو وقت#
یک فریلنسر مشاور، نیاز به اپلیکیشنی داشت که مشتری‌ها وقت رزرو کنند، پرداخت آنلاین انجام دهند، و ایمیل تأیید دریافت کنند. بدون دانش فنی، با Lovable شروع کرد.
- تعریف scope: سه صفحه — لیست خدمات، فرم رزرو، صفحه‌ی پرداخت. دیتابیس: Supabase. احراز هویت: نه (مهمان می‌تواند رزرو کند).
- پرامپت اول: «یک اپلیکیشن رزرو وقت بساز با لیست خدمات، فرم انتخاب تاریخ و ساعت، و اتصال به Stripe برای پرداخت.»
- بازخوانی: خروجی 4 فایل React + schema Supabase داشت. مدل Stripe را اشتباه import کرده بود.
- اصلاح: پرامپت دوم — «import Stripe را اصلاح کن، از @stripe/stripe-js استفاده کن.»
- تکرار: هر تغییر، یک پرامپت کوتاه + یک بازخوانی. نه پرامپت 500 کلمه‌ای.
اشتباه رایج «پرامپت 500 کلمه‌ای»#
در پروژه‌های اعضای کامیونیتی Claude اسکول، الگوی تکرارشونده‌ای دیده میشود: کاربر یک پرامپت طولانی و مفصل می‌نویسد، انتظار محصول کامل می‌گیرد، و وقتی خروجی ناقص یا پر از باگ است، ناامید میشود و ابزار را رها میکند. در مقابل، الگوی موفق «پرامپت کوتاه + بازخوانی + اصلاح» است. یک تغییر در هر پرامپت، و بعد بررسی خروجی.
زمان‌بندی واقع‌بینانه#
هفته اول: ساخت هسته (صفحات، دیتابیس، منطق اولیه). هفته دوم: اصلاح باگ‌های لاجیک و UI. هفته سوم و چهارم: آماده‌سازی برای انتشار (deploy، دامنه، SSL، تست نهایی). این بازه برای اپ سه صفحه‌ای با منطق ساده است.
هزینه‌ی پنهان#
در پروژه‌های واقعی، بخش عمده‌ای از زمان صرف بازخوانی و اصلاح کد تولیدشده میشود، نه نوشتن پرامپت. این الگویی است که در پروژه‌های اعضای کامیونیتی Claude اسکول مکرر دیده شده. اگر فکر می‌کنی پرامپت زدن یعنی کل کار، زمان‌بندی‌ات غلط است.
مشکل بزرگ وایب کدینگ: سه هفته بعد از انتشار#
بحران واقعی وایب کدینگ نه در ساخت، بلکه در نگهداشت است. وقتی باگی در کدی ظاهر شود که خودت ننوشتی و نمی‌فهمی، بدون قضاوت فنی مینیمال گیر می‌کنی. این نقطه‌ای است که اکثر راهنماها سکوت می‌کنند.
سناریوی «باگ ناشناخته»#
کاربر گزارش می‌دهد که «وقتی تاریخ رزرو را عوض می‌کنم، مبلغ پرداخت صفر میشود». تو در کد نمی‌چرخی چون نمی‌دانی چه چیزی کجا است. پرامپت اصلاح می‌زنی: «باگ مبلغ صفر را فیکس کن». مدل تغییر می‌دهد. باگ برمی‌گردد — چون مشکل اصلی در یک useEffect اشتباه بود و مدل آن را ندیده.
این چرخه تکرار میشود تا زمانی که یا قضاوت فنی یاد بگیری، یا کمک فنی بگیری. وایب کدینگ بدون بازخوانی، فقط توهم پیشرفت می‌سازد.
قضاوت فنی مینیمال چیست؟#
قضاوت فنی مینیمال یعنی توانایی فهمیدن سه مفهوم، بدون نیاز به نوشتن کد:
- رابط برنامه‌نویسی کاربردی (API): درخواست و پاسخ بین فرانتاند و بک‌اند. باید بفهمی کدام endpoint چه کاری انجام می‌دهد.
- طرح‌واره پایگاه داده (Database Schema): ساختار جداول و روابط. باید بفهمی داده‌ها کجا ذخیره می‌شوند.
- جریان احراز هویت (Authentication Flow): مسیر ورود کاربر. باید بفهمی token کجا ساخته و کجا چک میشود.
این سه مفهوم، «مهارت نوشتن» نمی‌خواهند. فقط «مهارت خواندن و فهمیدن» می‌خواهند. و همین مقدار، مرز بین گیر کردن و حل کردن است.
استراتژی نگهداشت بدون تیم فنی#
- مستندسازی معماری از روز اول: یک فایل README بنویس که بگوید هر صفحه چه کاری انجام می‌دهد و به کدام endpoint وصل است.
- نگه‌داشتن scope کوچک: هر قابلیت جدید، یک پرامپت کوتاه و یک بازخوانی. نه «همه‌چیز را یکجا اضافه کن».
- پذیرش کمک: بعضی باگ‌ها بدون کمک فنی حل نمی‌شوند. این شکست نیست، مرز ابزار است.
وایب کدینگ برای چه محصولاتی مناسب نیست؟#
وایب کدینگ برای سیستم‌هایی با منطق تجاری پیچیده، همزمانی بالا، یا نیاز به یکپارچگی با سیستم‌های legacy عملاً خارج از توان است. مرز عملی، اپ چند صفحه‌ای با دیتابیس ساده است.
مرز مقیاس‌پذیری#
اپ سه صفحه‌ای با یک دیتابیس ساده و یک payment gateway در محدوده‌ی وایب کدینگ است. اما اپ بیست صفحه‌ای با نقش‌های متعدد (admin، user، vendor)، webhookهای خارجی، و منطق چندلایه، بدهی فنی انباشته میکند. نه به‌خاطر اینکه مدل نمی‌تواند کد بنویسد، بلکه به‌خاطر اینکه هیچ‌کس معماری را درک نمی‌کند.
سه حالتی که وایب کدینگ شکست می‌خورد#
- منطق تجاری چندلایه: مثلاً سیستم قیمت‌گذاری پویا با تخفیف‌های تجمعی، یا approval workflow با شرایط پیچیده.
- نیاز به performance tuning: کوئری‌های بهینه، caching، lazy loading — این‌ها نیاز به فهم ساختار دارند.
- یکپارچگی با ERP یا سیستم legacy: پروتکل‌های قدیمی، مستندات ناقص، و edge caseهای بی‌پایان.
چه زمانی به برنامهنویس واقعی نیاز داری؟#
نه به‌عنوان جایگزین وایب کدینگ، بلکه به‌عنوان مکمل. برای معماری اولیه، code review قبل از انتشار، و حل باگ‌هایی که مدل نمی‌تواند حل کند. وایب کدینگ سرعت را بالا می‌برد؛ برنامهنویس، کیفیت را تضمین میکند.
امنیت، بدهی فنی و هزینه‌های پنهان وایب کدینگ#
محصول ساخته‌شده با وایب کدینگ بدون بررسی امنیتی و code review آماده production نیست. ریسک‌های رایج شامل کلیدهای API در کد، نبود rate limiting، و schema بدون constraint هستند.
چک‌لیست امنیتی قبل از انتشار#
- API Keys: هیچ کلید محرمانه‌ای نباید در کد فرانتاند باشد. بررسی کن که مدل keys را در environment variables گذاشته.
- Authentication Flow: آیا token در storage مرورگر ذخیره شده یا در httpOnly cookie؟
- Input Validation: آیا فرم‌ها اعتبارسنجی سمت سرور دارند یا فقط سمت کلاینت؟
- CORS: آیا originها محدود شده‌اند یا wildcard گذاشته شده؟
- Rate Limiting: آیا endpointها محدودیت تعداد درخواست دارند؟
بدهی فنی انباشته در وایب کدینگ#
نشانه‌های بدهی فنی در پروژه‌های وایب‌کدشده:
- کد تکراری — همان منطق در سه فایل مختلف.
- importهای نامرتبط — کتابخانه‌هایی که هیچ‌جا استفاده نمی‌شوند.
- تابعهای بلند — یک تابع 200 خطی که همه‌چیز انجام می‌دهد.
هزینه بازپرداخت این بدهی، در پروژه‌های اعضای کامیونیتی Claude اسکول، معمولاً بیشتر از هزینه ساخت اولیه است. چون کد را کسی نوشته که تو نمی‌شناسی، و تو باید بفهمی چه نوشته تا اصلاحش کنی.
مقایسه هزینه#
هزینه مستقیم وایب کدینگ شامل اشتراک ابزار و زمان خودت است. هزینه پنهان اصلی، زمانی است که صرف بازخوانی و اصلاح کد تولیدشده میشود. در مقایسه با استخدام فریلنسر، وایب کدینگ برای MVPهای کوچک ارزان‌تر تمام میشود؛ اما برای محصولاتی که قرار است طولانی‌مدت نگهداری شوند، هزینه نگهداشت ممکن است از هزینه ساخت فراتر برود.
وایب کدینگ ابزاری است، نه جادو#
وایب کدینگ واقعاً سرعت ساخت را بالا می‌برد، اما قضاوت فنی مینیمال را حذف نمی‌کند. اگر میخواهی محصولی بسازی که بعد از انتشار هم زنده بماند، باید سه مفهوم را بفهمی — API، schema، authentication — و عادت کنی خروجی مدل را بازخوانی کنی. ابزارها به‌سرعت تغییر می‌کنند؛ این قضاوت فنی است که ماندگار است.
اگر میخواهی این مسیر را با راهنمایی و پروژه‌های واقعی طی کنی، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول دقیقاً همین را پوشش می‌دهد — از پرامپت اول تا نگهداشت محصول.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.