ساخت اپ فروشگاهی با وایب کدینگ در چهار ساعت تمام شد، اما سه بار کد سالم خراب شد. یک خطای CORS نصفه‌کاره ماند و دو بار مجبور به بازنویسی دستی شدیم. این تجربه‌ی مشترک بسیاری از اعضای کامیونیتی است؛ چیزی که آموزش‌های تبلیغاتی درباره‌ی وایب کدینگ نمی‌گویند.
وایب کدینگ چیست و چرا با no-code فرق دارد؟#
وایب کدینگ (Vibe Coding) روشی است که در آن کاربر بدون خواندن کد، فقط با پرامپت انگلیسی کد را هدایت میکند. برخلاف no-code که محدود به قالب‌های پیش‌ساخته است، وایب کدینگ کد واقعی تولید میکند و حتماً به بازنگری انسانی نیاز دارد.
آندری کارپاتی (Andrej Karpathy) این اصطلاح را در فوریه ۲۰۲۵ ابداع کرد و تعریفش را در یک توییت خلاصه کرد: «کد را هدایت می‌کنی با پرامپت و وایب، بدون اینکه واقعاً بخوانی‌اش.» این تعریف، مرز وایب کدینگ را از AI-assisted coding مشخص میکند. در AI-assisted coding، برنامهنویس کد را می‌خواند، اصلاح میکند و مدل را به‌عنوان دستیار استفاده میکند. در وایب کدینگ، کد خروجی مدل است و کاربر فقط پرامپت میدهد.
وایب کدینگ در برابر no-code: کد واقعی در برابر قالب پیش‌ساخته#
در no-code، شما یک UI بصری می‌چینید و پلتفرم زیرساخت را مدیریت میکند. خروجی، یک اپ روی پلتفرم است که اگر بخواهید از آن خارج شوید، عملاً چیزی ندارید. در وایب کدینگ، خروجی یک ریپوی واقعی با package.json، فایل‌های source و build config است. یعنی اگر مدل را قطع کنید، کد همچنان اجرا میشود.
این تمایز برای مخاطب غیرفنی حیاتی است: no-code یعنی «قالب را پر کن»، وایب کدینگ یعنی «کد واقعی تولید شد و تو باید بفهمی چه چیزی تولید شده». اگر اصلاً ندانید چه چیزی ساخته شده، در اولین خطا فلج می‌شوید.
چرا این تمایز برای مخاطب غیرفنی مهم است؟#
چون انتظار «صفر دانش فنی» در وایب کدینگ، همان انتظاری است که باعث شکست پروژه‌ها میشود. no-code واقعاً صفر دانش فنی می‌خواهد. وایب کدینگ، حداقل فهم ساختار پروژه، مفهوم dependency و تفاوت frontend با backend را می‌طلبد. بدون این فهم، پرامپت اصلاحی مؤثر نمی‌نویسید.
ابزارهای وایب کدینگ: کدام برای چه کاری مناسب است؟#
انتخاب ابزار وایب کدینگ به سطح تعامل شما با کد بستگی دارد، نه به نوع پروژه. Cursor و Windsurf برای کسانی است که حداقل کد را می‌خوانند؛ Bolt.new، Lovable و v0 برای کسانی که فقط پرامپت می‌دهند و خروجی را در مرورگر اجرا میکنند.
جدول مقایسه‌ای ابزارها#
| ابزار | سطح تعامل با کد | مناسب برای | محدودیت اصلی |
|---|---|---|---|
| Cursor | کد را می‌خوانید و ویرایش می‌کنید | پروژه‌ی چندفایلی با auth و دیتابیس | نیاز به IDE و دانش پایه‌ی terminal |
| Windsurf | کد را میبینید و اصلاح می‌کنید | پروژه‌ی متوسط با context طولانی | هنوز در فاز early access، پایداری کم |
| Bolt.new | فقط پرامپت، خروجی در مرورگر | پروتوتایپ سریع، یک صفحه، demo | state پیچیده و auth چندلایه را نمی‌سازد |
| Lovable | فقط پرامپت + ویرایش بصری محدود | سایت‌های informational، landing page | منطق business-side را نمی‌فهمد |
| v0 | فقط پرامپت، خروجی React component | UI-only، بدون backend | فقط frontend، بدون دیتابیس و auth |
| Replit | کد را میبینید، اجرا می‌کنید | پروژه‌ی کامل با deploy داخلی | context window محدود، بازنویسی مکرر |
چه زمانی Bolt.new گیر میکند#
در روایت پروژه‌ی فروشگاهی‌مان، Bolt.new تا ساخت لیست محصول و فرم سفارش خوب کار کرد. به محض اینکه auth اضافه شد، مدل شروع به بازنویسی بخشهای سالم کرد. خطای CORS در پرامپت دوم ظاهر شد و پرامپت سوم برای رفع CORS، ساختار routing را شکست. الگوی تکرارشونده: هرچه state پیچیده‌تر، احتمال بازنویسی خراب‌کار بیشتر.
ترکیب ابزارها: چرا یک ابزار کافی نیست#
هیچ ابزاری بهتنهایی کل چرخهی MVP را پوشش نمیدهد. الگوی عملی که در پروژه‌های اعضای کامیونیتی اسکول مکرر دیده شده: با Bolt.new یا Lovable شروع کنید، UI را بسازید، سپس کد را به Cursor منتقل کنید و auth و دیتابیس را دستی اضافه کنید. این ترکیب، هزینهی بازنویسی خراب‌کار را کاهش میدهد.
مراحل ساخت یک اپ فروشگاهی با وایب کدینگ: از پرامپت تا deploy#
یک اپ فروشگاهی ساده با Bolt.new شروع شد، در پرامپت اول UI تولید شد، در پرامپت دوم خطای CORS خورد، در پرامپت سوم مدل بخشهای سالم را بازنویسی و خراب کرد، و در نهایت پس از چهار ساعت و سه بازنگری دستی deploy شد. این روایت، الگوی شکست و موفقیت وایب کدینگ را نشان میدهد.
پرامپت اول: آنچه مدل در ۹۰ ثانیه تولید کرد#
پرامپت: «یک اپ فروشگاهی با React و Tailwind بساز که لیست محصول، صفحهی جزئیات و سبد خرید داشته باشد.» خروجی: سه صفحهی کارکردی با mock data، navigation ساده و UI قابل‌قبول. در این مرحله، وایب کدینگ واقعاً درخشید. اگر فقط برای demo به سرمایهگذار می‌خواستید، اینجا کافی بود.
اولین دیوار: خطای dependency و CORS#
پرامپت دوم: «یک API واقعی اضافه کن که محصولات را از backend بگیرد.» مدل یک fetch ساده نوشت ولی endpoint محلی را بدون proxy تنظیم کرد. نتیجه: خطای CORS. پرامپت سوم برای رفع CORS، vite.config را تغییر داد و در همان تغییر، importهای بخش UI را حذف کرد. این نقطه‌ای است که وایب کدینگ از «معجزه» به «معضل» تبدیل میشود.
بازنویسی خراب‌کار: وقتی پرامپت اصلاحی بخش سالم را می‌شکند#
مدل در پاسخ به پرامپت سوم، کل فایل App.tsx را بازنویسی کرد. بخش سبد خرید که سالم بود، از بین رفت. این یک اشتباه کاربر نیست؛ یک مشکل ساختاری در نحوه‌ی کار LLM با context است. مدل فایل را کامل بازنویسی میکند، نه patch می‌زند. هرچه پروژه بزرگ‌تر، احتمال این بازنویسی بیشتر.
deploy و اولین کاربر واقعی#
پس از سه بازنگری دستی در Cursor — اضافه‌کردن proxy، بازگرداندن بخش سبد خرید و اصلاح auth — پروژه روی Vercel deploy شد. اولین کاربر واقعی: یک دوست که با موبایل وارد شد و form سفارش کار نکرد چون validation سمت کلاینت نبود. در demo با ۱۰ کاربر این باگ دیده نمیشود چون خودتان می‌دانید باید چه وارد کنید.
فهرست گام‌به‌گام کل فرآیند#
- پرامپت اول در Bolt.new: ساخت UI با mock data (۹۰ ثانیه)
- پرامپت دوم: اضافه‌کردن API واقعی → خطای CORS
- پرامپت سوم: رفع CORS → بازنویسی خراب‌کار بخش سبد خرید
- انتقال کد به Cursor: بازگرداندن بخشهای خراب‌شده
- اضافه‌کردن auth دستی با Supabase
- بازنگری امنیتی: حذف لاگ‌کردن token، اضافه‌کردن rate limit
- deploy روی Vercel
- تست با کاربر واقعی → کشف باگ validation
- اصلاح نهایی و deploy مجدد
هزینهی واقعی ساخت MVP با وایب کدینگ چقدر است؟#
هزینهی وایب کدینگ فقط اشتراک ماهانه‌ی ابزار نیست؛ زمان بازنگری انسانی، هزینهی بازنویسی و در نهایت هزینهی مهاجرت به کد تمیز در مقیاس، همه جزو هزینهی واقعی‌اند. کسی که فقط قیمت اشتراک را می‌بیند، هزینهی پنهان را محاسبه نکرده است.
اشتراک ابزارها#
Bolt.new و Lovable اشتراک ماهانه دارند. Cursor هم یک tier رایگان محدود و یک tier پرداختی دارد. اما عدد اشتراک، بخش کوچکی از هزینهی کل است. در پروژه‌ی فروشگاهی ما، هزینهی اشتراک حدود دو ساعت زمان بازنگری دستی در Cursor بود که اگر فریلنسر استخدام می‌کردیم، هزینهی آن ساعتها را باید جداگانه محاسبه می‌کردیم.
هزینهی پنهان بازنگری انسانی#
ادعای «صفر بازنگری لازم است» یک myth است. الگوی تکرارشونده در پروژه‌های واقعی: هر ۳ تا ۴ پرامپت یک بازنویسی خراب‌کار. هر بازنویسی خراب‌کار، یک بازنگری انسانی می‌طلبد. این بازنگری، همان کاری است که وایب کدینگ وعده‌ی حذفش را میدهد ولی عملاً حذف نمی‌کند.
مقایسه با استخدام فریلنسر#
وایب کدینگ ارزان‌تر از فریلنسر است وقتی: ایده را نمی‌دانید و فقط میخواهید سریع تست کنید. وایب کدینگ گران‌تر است وقتی: محصول را به کاربر واقعی رسانده‌اید و حالا باید مقیاس دهید. در آن نقطه، کد وایبکدینگشده باید بازنویسی شود و هزینهی بازنویسی از هزینهی اولیه‌ی فریلنسر بیشتر میشود.
پیش‌نیازهایی که هیچ‌کس نمی‌گوید: بدون این‌ها وایب کدینگ به بن‌بست می‌خورد#
ادعای «صفر دانش فنی لازم است» در وایب کدینگ گمراه‌کننده است. حداقل فهم متغیر، API، دیتابیس و مفهوم deploy ضروری است؛ بدون این‌ها در اولین خطای واقعی گیر می‌کنید و نمی‌توانید پرامپت اصلاحی مؤثر بنویسید. پرامپت «CORS را درست کن» مؤثر است فقط اگر بدانید CORS چیست.
مفاهیم پایه‌ای که واقعاً لازم است#
- تفاوت frontend و backend: نمی‌دانید، پرامپت اصلاحی نمی‌نویسید
- مفهوم API و endpoint: بدون این، خطای fetch را نمی‌فهمید
- مفهوم dependency و package.json: بدون این، با خطای نصب گیر می‌کنید
- مفهوم deploy و hosting: بدون این، پروژه روی localhost می‌ماند
- مفهوم متغیر و شرط: بدون این، منطق business را نمی‌توانید توضیح دهید
آنچه لازم نیست: بلد بودن syntax زبان، درک الگوریتم، یا توانایی نوشتن کد از صفر. وایب کدینگ این‌ها را حذف میکند، ولی «فهم» را نه.
نقش Git و snapshot#
بدون version control، یک بازنویسی خراب‌کار یعنی از دست دادن چند ساعت کار. لازم نیست branch و merge بلد باشید، ولی باید بتوانید قبل از هر پرامپت بزرگ یک snapshot بگیرید. الگوی عملی: هر پرامپت بزرگ، یک commit. اگر مدل خراب کرد، revert می‌کنید. بدون این، در چرخهی بازنویسی گیر می‌افتید و هر بار از صفر شروع می‌کنید.
مهارت پرامپت‌نویسی به‌عنوان پیش‌نیاز فنی#
پرامپت‌نویسی در وایب کدینگ، جایگزین نوشتن کد نیست؛ جایگزین debug کردن کد است. پرامپت خوب، مشکل را در scope مشخص تعریف میکند. پرامپت بد، «همه‌چیز را درست کن» است و نتیجه‌اش بازنویسی خراب‌کار. پرامپت مؤثر: «فقط فایل ProductCard.tsx را طوری تغییر بده که قیمت با دو رقم اعشار نمایش داده شود. بقیه‌ی فایل‌ها دست نخورند.»
چه پروژه‌هایی اصلاً نباید با وایب کدینگ ساخته شوند؟#
وایب کدینگ برای MVP، پروتوتایپ و اعتبارسنجی ایده مناسب است، اما برای محصولی با هزاران کاربر فعال، دادهی حساس، تراکنش مالی یا منطق تجاری پیچیده خطرناک است و بدهی فنی (Technical Debt) پنهان می‌سازد. تمایز MVP و محصول نهایی، مرز وایب کدینگ است.
تمایز MVP و محصول نهایی#
کد برای ۱۰ کاربر با کد برای ۱۰۰۰ کاربر فرق دارد. در ۱۰ کاربر، race condition، load testing و monitoring لازم نیست. در ۱۰۰۰ کاربر، این‌ها اجباری‌اند و وایب کدینگ نمی‌تواند آن‌ها را مدیریت کند چون مدل، context پروژه را نمی‌فهمد و فقط فایلی که پرامپت داده‌اید را تغییر میدهد.
پروژه‌هایی که وایب‌کدینگ‌پذیر نیستند#
- Fintech و پرداخت: یک باگ امنیتی = از دست رفتن پول کاربر
- Healthtech: دادهی حساس با الزامات قانونی که مدل نمی‌شناسد
- Enterprise با SSO و RBAC: منطق دسترسی چندلایه در context window مدل جا نمیشود
- هر پروژه‌ای با compliance: مدل، الزامات قانونی را نمی‌داند
بدهی فنی پنهان#
کد وایبکدینگشده، بدهی فنی‌اش را پنهان میکند. ظاهراً کار میکند، ولی بدون test، بدون error handling صحیح، بدون logging و بدون security headers. وقتی مقیاس میدهید، این بدهی‌ها با بهره‌ی چندبرابری برمی‌گردند. هزینهی بازنویسی در مقیاس، معمولاً بیشتر از هزینهی ساخت اولیه‌ی درست است.
امنیت و کیفیت کد: خطراتی که در demo نمی‌بینید#
مدل‌های زبانی در تولید کد دچار توهم (Hallucination) می‌شوند: کدی تولید میکنند که ظاهراً کار میکند ولی حفره‌ی امنیتی دارد، داده را لاگ میکند، یا احراز هویت را دور می‌زند. این خطرات در demo با ۱۰ کاربر دیده نمی‌شوند چون خودتان مهاجم نیستید.
توهم مدل در کد#
توهم در کد یعنی: مدل یک API را صدا می‌زند که وجود ندارد، یک dependency را import میکند که نصب نیست، یا یک الگوی امنیتی را «شبیه‌سازی» میکند بدون اینکه واقعاً پیاده‌سازی کند. نشانه‌ی عملی: کد اجرا میشود، تست‌های happy path رد می‌شوند، ولی edge caseها فرو می‌ریزند.
حفرههای امنیتی رایج#
- احراز هویت ناقص: token در localStorage ذخیره میشود، نه httpOnly cookie
- لاگ‌کردن دادهی حساس: مدل password یا token را در console.log چاپ میکند
- وابستگی‌های آسیب‌پذیر: مدل packageهایی import میکند که CVE دارند
- بدون rate limiting: form سفارش بدون محدودیت درخواست، قابل spam
- CORS باز: مدل cors: '*' می‌نویسد چون در demo کار میکند
چک‌لیست بازنگری امنیتی قبل از deploy#
- بررسی کنید هیچ secret در کد client-side نیست
- auth token در httpOnly cookie ذخیره میشود
- CORS فقط برای domain خودتان باز است
- rate limiting روی endpoints حساس فعال است
- input validation سمت server هم هست، نه فقط client
- هیچ console.log شامل دادهی کاربر نیست
اشتباهات رایج وایب کدینگ و هزینهی هر کدام#
پنج اشتباه ساختاری وایب کدینگ عبارت‌اند از: پرامپت بزرگ و یکجا، عدم snapshot گرفتن، نادیده‌گرفتن خطاهای dependency، بازنویسی کامل به‌جای اصلاح موضعی، و deploy بدون بازنگری انسانی. هر کدام از این‌ها، هزینه‌ای مشخص دارد.
پرامپت بزرگ: چرا یک پرامپت ۲۰۰ کلمه‌ای بدتر از ۵ پرامپت ۴۰ کلمه‌ای است#
مدل، پرامپت بزرگ را به‌عنوان یک task واحد می‌بیند و همه‌چیز را یکجا تغییر میدهد. اگر یک بخش خراب شد، کل خروجی خراب است. پرامپت‌های کوچک و متمرکز، scope تغییر را محدود نگه می‌دارند و احتمال بازنویسی خراب‌کار را کاهش می‌دهند. الگوی عملی: هر پرامپت فقط یک فایل یا یک تغییر.
چرخهی بازنویسی خراب‌کار#
این یک مشکل ساختاری است، نه اشتباه کاربر. LLM فایل را کامل بازنویسی میکند، نه patch. هرچه پروژه بزرگ‌تر، احتمال اینکه پرامپت اصلاحی بخش سالم را خراب کند بیشتر است. راه‌حل: scope پرامپت را محدود کنید، قبل از هر پرامپت commit بگیرید، و بعد از هر پرامپت فقط بخش تغییر‌یافته را تست کنید.
deploy بدون بازنگری: فاجعه‌ی هفته‌ی دوم#
الگوی تکرارشونده از پروژه‌های واقعی: هفته‌ی اول همه‌چیز عالی است، MVP deploy میشود، ۱۰ کاربر اول راضی‌اند. هفته‌ی دوم، اولین کاربر واقعی با رفتار غیرمنتظره وارد میشود و باگ‌های امنیتی و logic آشکار می‌شوند. deploy بدون بازنگری انسانی، یعنی این باگ‌ها را به کاربر واقعی تحویل داده‌اید.
نتیجه‌ی عملی: وایب کدینگ ابزاری قدرتمند برای اعتبارسنجی سریع ایده است، نه جایگزین برنامهنویس و نه راه‌حل مقیاس. اگر میخواهید ایدهتان را در چند ساعت به demo تبدیل کنید، عالی است. اگر میخواهید محصولی بسازید که با هزاران کاربر کار کند، وایب کدینگ فقط نقطه‌ی شروع است، نه مقصد.
اگر میخواهید این مسیر را از پرامپت اول تا deploy با یک پروژه‌ی واقعی و بدون حاشیه طی کنید، دورهٔ آموزش جامع Claude و ابزارهای مشابه در کامیونیتی Claude اسکول دقیقاً همین کار را میکند — با روایت پروژه‌محور و نشاندادن شکست‌ها، نه فقط demoهای موفق.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.