اپلیکیشن رزرو وقت با وایبکدینگ در 3 روز ساخته شد. تا اولین کاربر، همهچیز درست کار میکرد. مشکل از کاربر دوم شروع شد: فیلتر، گزارش و دسترسی نقشمحور که در پرامپت اول دیده نشده بودند. این مقاله همان نقطهی شکست را با روایت یک پروژهی واقعی نشان میدهد و توضیح میدهد کجا وایبکدینگ کار میکند و کجا فرو میریزد.
وایبکدینگ دقیقاً یعنی چه و از کجا آمد؟#
وایبکدینگ (Vibe Coding) روشی است که در آن بهجای نوشتن کد، با پرامپتهای زبان طبیعی به هوش مصنوعی دستور میدهید و خروجی قابلاجرا میگیرید. این اصطلاح را اندرو کارپاتی (Andrej Karpathy) در فوریه 2025 در پست X خود تعریف کرد و بلافاصله در جامعهی توسعهدهندگان جا افتاد.
کارپاتی خودش هم محدودیت گذاشت: «برای کار جدی توصیه نمیکنم». یعنی حتی خالق اصطلاح، مرز استفادهی ایمن را مشخص کرده است. این نکتهای است که اکثر محتوای فارسیزبان دربارهی وایبکدینگ از آن میگذرد.
دو مدل ذهنی متفاوت#
مدل اول: توسعهدهندهای که کد مینویسد و از AI بهعنوان دستیار استفاده میکند. اینجا وایبکدینگ یک سبک کار است، نه جایگزین دانش فنی.
مدل دوم: فردی بدون پیشزمینهی برنامهنویسی که میخواهد محصول بسازد. اینجا وایبکدینگ ابزار است، اما حداقل فهم ساختار داده، API و فرآیند deploy (استقرار) الزامی باقی میماند. بدون این درک، خروجی را نمیتوانید دیباگ یا توسعه دهید.
پیشنیازهای فنی حداقلی#
- فهم ساختار داده: چه جدولهایی لازم است و رابطهشان چیست
- مفهوم API: چطور فرانتاند و بکاند با هم صحبت میکنند
- فرآیند deploy: کد تولیدشده کجا اجرا میشود و چطور آپدیت میشود
تفاوت وایبکدینگ با نودکد و لوکد#
تفاوت بنیادی در مالکیت کد است. نودکد (No-Code) رابط بصری drag-and-drop دارد و کدی تولید نمیکند؛ وایبکدینگ خروجی کد واقعی (معمولاً React، TypeScript یا Python) تولید میکند که قابل ویرایش دستی و توسعهی مستقل است. لوکد (Low-Code) جایی بین این دو قرار دارد.
جدول مقایسهی سه روش#
| معیار | نودکد | لوکد | وایبکدینگ |
|---|---|---|---|
| خروجی | اپ بدون کد، داخل پلتفرم قفلشده | کد محدود + رابط بصری | کد واقعی قابل ویرایش |
| انعطافپذیری | محدود به قابلیتهای پلتفرم | متوسط، با سفارشیسازی محدود | بالا، چون کد دست شماست |
| هزینهی یادگیری | پایین | متوسط | پایین تا متوسط (بسته به پیشزمینه) |
| محدودیت اصلی | قفل روی پلتفرم، lock-in | پیچیدگی منطق کسبوکار بالا | کیفیت خروجی وابسته به پرامپت و بازنگری معماری |
| بهترین کاربرد | فرم، landing page، اتوماسیون داخلی | اپهای داخلی شرکتی | MVP سریع، پروتایپ، وباپ ساده |
چه زمانی نودکد هنوز برتر است؟#
وقتی UI شما drag-and-drop دقیق میخواهد — مثل ویرایشگر بوم یا ابزار طراحی. اینجا نودکد با رابطهای تخصصیاش هنوز جلوتر است. وایبکدینگ خروجی کد میدهد، نه بوم تعاملی.
چرا وایبکدینگ نودکد را منسوخ نمیکند؟#
هر دو در کاربردهای متفاوتی میدرخشند. نودکد برای کسی که اصلاً نمیخواهد کد ببیند. وایبکدینگ برای کسی که کد میخواهد ولی نمیخواهد از صفر بنویسد. این دو رقیب مستقیم هم نیستند؛ مخاطبشان فرق دارد.
بهترین ابزارهای وایبکدینگ کداماند؟#
هیچ ابزاری همهکاره نیست. انتخاب ابزار به نوع محصول بستگی دارد: Cursor برای توسعهدهندهای که کد مینویسد و AI کمک میخواهد، Bolt.new و Lovable برای ساخت سریع وباپ از صفر، و v0 برای تولید UI component. اول مشخص کنید کجای طیف هستید، بعد ابزار انتخاب کنید.
مقایسهی عملیاتی ابزارها#
| ابزار | ورودی | خروجی | Deploy | مناسب برای |
|---|---|---|---|---|
| Cursor | پرامپت + فایلهای موجود | کد داخل IDE | خارجی (Vercel، Netlify و…) | پروژهی کددار با نیاز به دیباگ |
| Bolt.new | پرامپت زبان طبیعی | پروژهی کامل قابل اجرا | داخلی + export | وباپ از صفر، MVP سریع |
| Lovable | پرامپت زبان طبیعی | پروژهی React + Supabase | داخلی | وباپ با backend ساده |
| v0 | توصیف UI | کامپوننت React/Tailwind | خارجی | فقط تولید UI component |
| Replit | پرامپت + کد | پروژهی کامل | داخلی | پروتوتایپ سریع با اجرا در مرورگر |
نقش مدل زبانی بزرگتر در کیفیت خروجی#
یک ابزار با مدل بزرگتر (مثل GPT-4o یا Claude 3.5 Sonnet) خروجی بهتری از همان ابزار با مدل کوچکتر میدهد. دلیلش ساده است: مدل بزرگتر context را بهتر حفظ میکند، edge caseها را بیشتر میبیند و کد تمیزتری تولید میکند. اگر کیفیت خروجی برایتان مهم است، اول مدل زیرمجموعهی ابزار را چک کنید، نه خود ابزار را.
الگوی انتخاب#
- وباپ ساده از صفر → Bolt.new یا Lovable
- پروژهی کددار با نیاز به دیباگ و refactoring → Cursor
- فقط UI component → v0
- پروتوتایپ سریع بدون deploy → Replit
روایت ساخت یک اپلیکیشن واقعی از ایده تا استقرار#
ساخت یک اپ رزرو وقت با Bolt.new در سه روز انجام شد و تا اولین کاربر همهچیز درست کار میکرد. مشکل در هفتهی دوم و با کاربر دوم ظاهر شد، نه در هفتهی اول. ریشهاش فنی نبود؛ معماری داده بود. این روایت پنج گامی نشان میدهد دقیقاً کجا و چرا وایبکدینگ لنگ میزند.

گام 1 — تعریف دامنه و مدل داده قبل از نوشتن پرامپت#
اشتباه رایج: شروع با پرامپت «اپلیکیشن رزرو بساز». این پرامپت happy path را میسازد و هیچچیز دیگر. کاری که باید کرد: قبل از هر پرامپت، موجودیتها و روابطشان را روی کاغذ بنویسید. کاربر، وقت، سرویس، وضعیت رزرو، نقش. اگر این را ننویسید، مدل زبانی خودش حدس میزند و حدسش معمولاً ناقص است.
گام 2 — ساخت صفحهبهصفحه با پرامپت و تست فوری#
الگوی موفق: یک صفحه بسازید، در مرورگر تست کنید، خطا را بگویید اصلاح کند، بعد بروید سراغ صفحهی بعدی. پرامپت «کل اپلیکیشن را بساز» خروجیی چند هزار خطی میدهد که هیچکدامش تست نشده.
گام 3 — اتصال API و مدیریت state بین صفحات#
اینجا اولین جایی است که وایبکدینگ لنگ میزند. مدل زبانی state management بین صفحات را معمولاً سادهسازی بیشازحد میکند. برای اپ رزرو، state یعنی: کاربر لاگین → سرویس انتخاب → وقت آزاد → تأیید. اگر این chain را در پرامپت نفرستید، خروجی هر صفحه مستقل عمل میکند و بین صفحات ارتباطی نیست.
گام 4 — Deploy و اولین کاربر واقعی#
با Bolt.new deploy داخلی وجود دارد. اولین کاربر تست کرد، فرم رزرو کار کرد، ایمیل تأیید رفت. همهچیز عالی بود. دقیقاً اینجا است که اعتمادبهنفس کاذب شکل میگیرد.
گام 5 — نقطهی شکست: کاربر دوم#
کاربر دوم آمد و خواست رزروهایش را فیلتر کند. کاربر سوم خواست گزارش ماهانه ببیند. ادمین خواست دسترسی نقشمحور داشته باشد. هیچکدام از اینها در پرامپت اول نبود. مدل دادهای که AI ساخته بود فقط «ساخت رزرو» را میفهمید، نه «مدیریت رزروها». بازنگری معماری لازم شد و این بازنگری تقریباً بهاندازهی ساخت اولیه زمان برد.
چطور پرامپت بنویسیم که کد درستتری تولید شود؟#
الگوی «یک صفحه، تست، بعد صفحه بعدی» واقعاً تفاوت ایجاد میکند. اما یک نکتهی مهمتر: در پرامپت اول، مدل داده را صریح بفرستید. نه «اپ رزرو بساز»، بلکه «جدول users با فیلدهای name، email، role بساز. جدول appointments با فیلدهای user_id، service_id، date، status بساز. رابطه: هر user چند appointment دارد.»
چرا MVPهای وایبکدینگ در کاربر دوم شکست میخورند؟#
مشکل فنی نیست؛ مشکل معماری داده است. مدلهای زبانی در پرامپت اول فقط happy path را میسازند و edge caseها، روابط بین موجودیتها و الگوهای دسترسی را نمیبینند. نتیجه: کدی که برای یک کاربر و یک سناریو کار میکند و با ورود کاربر دوم فرو میپاشد.
الگوی شکست#
پرامپت اول → happy path → MVP کار میکند → کاربر دوم نیاز جدید میآورد → معماری فعلی پاسخ نمیدهد → بازنگری لازم میشود. این چرخه در پروژههای اعضای کامیونیتی بارها تکرار شده و الگوی مکرری است.
مقیاسپذیری و امنیت#
محصولات وایبکدینگ بدون بازنگری معماری قابلاتکا نیستند. دلیلش این است که مدل زبانی «امنیت» را در پرامپت نمیبیند مگر صریح بخواهید. rate limiting، input validation، role-based access control — اینها در happy path نیستند. اگر پرامپت ننویسید، وجود ندارند.
قاعدهی سهسؤالی#
قبل از شروع با وایبکدینگ، سه سؤال بپرسید:
- دادهی حساس درگیر است؟ (مالی، بهداشتی، هویتی)
- بیش از 15 قاعدهی کسبوکار دارد؟
- نیاز به SLA (Service Level Agreement) بالای uptime دارد؟
هرچه تعداد «بله» کمتر، وایبکدینگ مناسبتر. هرچه بیشتر، توسعهدهندهی انسانی ضروریتر.
راهحل عملی#
قبل از جذب کاربر سوم، مدل داده را بازنگری کنید و لایهی abstraction اضافه کنید. یعنی جدا کنید منطق business را از UI. اگر این کار را نکنید، هر کاربر جدید یک باگ معماری جدید ظاهر میکند.
وایبکدینگ برای چه پروژههایی اصلاً مناسب نیست؟#
پروژههایی با منطق کسبوکار بیش از 15 شرط، تراکنش مالی، نیاز به compliance، یا SLA بالای uptime هنوز به توسعهدهندهی انسانی نیاز دارند. وایبکدینگ در این حوزهها نه فقط ناکارآمد، بلکه خطرناک است.
لیست پروژههای نامناسب#
- Fintech: تراکنش مالی، محاسبات بهدقت اعشاری، ضدکلاهبرداری
- Healthcare: HIPAA یا معادلهای محلی، دادهی حساس بیماران
- ERP: صدها قاعدهی کسبوکار، یکپارچگی با سیستمهای موجود
- سیستمهای با compliance: حسابرسی، لاگهای قانونی، دسترسیهای سلسلهمراتبی
آیا وایبکدینگ جایگزین استخدام برنامهنویس میشود؟#
نه. نقش برنامهنویس از «ساز کد» به «بازبین، معمار و دیباگر» تغییر میکند. برای پروژههای حیاتی، مالی یا با compliance، توسعهدهندهی انسانی هنوز ضروری است. وایبکدینگ سرعت اولیه را بالا میبرد، اما عمق فنی را نه.
مقایسهی واقعی هزینه#
مقایسهی وایبکدینگ + زمان شما در برابر فریلنسر، از نظر ریالی گمراهکننده است. مقایسهی درست: تعداد دور بازگشت. با فریلنسر، یک بار brief میدهید و یک بار review میکنید. با وایبکدینگ، هر بار که edge case جدیدی ظاهر شود، باید پرامپت اصلاحی بنویسید و دوباره تست کنید. برای MVPهای ساده، وایبکدینگ سریعتر است. برای پروژههای پیچیده، فریلنسر با تجربه در تعداد دور بازگشت برنده است.
هزینه و زمانبندی واقعبینانه برای ساخت MVP با وایبکدینگ#
یک وباپ ساده با Bolt.new یا Lovable در بازهی چند روز تا دو هفته قابلساخت است. هزینه شامل اشتراک ابزار و زمان خودتان میشود. اما زمان دیباگ و بازنگری — که اکثر مقالات از آن میگذرند — به این بازه اضافه میشود و در عمل نزدیک به دو برابر زمان ساخت اولیه است.
جدول زمانبندی واقعبینانه#
| سطح پیچیدگی | ساخت اولیه | بازنگری معماری | جمع |
|---|---|---|---|
| ساده (landing page، فرم، رزرو) | 2 تا 5 روز | 1 تا 3 روز | حدود 1 هفته |
| متوسط (چند صفحه، API، auth) | 1 تا 2 هفته | 3 تا 7 روز | حدود 2 تا 3 هفته |
| پیچیده (منطق کسبوکار، چند نقش، گزارش) | 2 تا 4 هفته | 1 تا 2 هفته | حدود 1 تا 1.5 ماه |
هزینهی پنهان: زمان دیباگ و بازنگری#
این چیزی است که اکثر محتوای وایبکدینگ نمیگوید. ساخت اولیه سریع است. اما وقتی کاربر دوم یک نیاز جدید میآورد و مدل داده پاسخ نمیدهد، بازنگری معمولاً بهاندازهی ساخت اولیه زمان میبرد. این هزینه را در برنامهریزیتان لحاظ کنید.
اشتباهات رایج مبتدیها#
- شروع با پرامپت بزرگ «کل اپلیکیشن را بساز» بهجای ساخت تدریجی
- نادیدهگرفتن مدل داده — فکر کردن که AI خودش جدولها را درست میسازد
- Deploy بدون تست edge case — ورودی خالی، همزمانی، خطای شبکه
- باور اینکه خروجی اولیه نهایی است — در عمل، خروجی اولیه فقط یک پروتوتایپ است
جمعبندی عملی#
وایبکدینگ ابزاری قدرتمند برای MVPهای ساده و سریع است. اما نقطهی شکستاش از کاربر دوم شروع میشود و ریشهاش معماری داده است، نه کد. اگر مدل داده را قبل از پرامپت اول طراحی کنید و بازنگری را در برنامهریزی لحاظ کنید، وایبکدینگ میتواند واقعاً سرعتتان را چند برابر کند.
اگر میخواهید این مسیر را با راهنمایی و تمرین عملی طی کنید، دورهی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی اسکول دقیقاً همین کار را میکند: ساخت محصول با وایبکدینگ و ایجنتها، از پرامپت تا deploy، با بازنگری معماری در هر مرحله.







دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.