اگر تا حالا با ابزارهای هوش مصنوعی پروژه‌ای ساخته‌اید و در مرحله‌ی دپلوی همه‌چیز فرو ریخته، مشکل از هوش مصنوعی نبوده. مشکل از تقسیم‌بندی مسئله بوده. وایب کدینگ یک مهارت کدنویسی نیست؛ یک مهارت معماری است. کسی که نداند چطور یک محصول را به واحدهای مستقل بشکند، هر ابزاری هم به‌جای‌اش بگذارد، همان نتیجه‌ی شکست‌خورده را می‌گیرد. این مقاله یک پروژه‌ی واقعی را از پرامپت اول تا دپلوی نهایی روایت می‌کند و دقیقاً نشان میدهد کجا باید مراقب باشید.
وایب کدینگ چیست و از کجا آمد؟#
وایب کدینگ (Vibe Coding) روشی است که در آن سازنده بهجای نوشتن خط‌به‌خط کد، با پرامپت‌های زبانی خروجی قابل‌اجرا تولید می‌کند و کد واقعی، قابل ویرایش و قابل دپلوی تحویل می‌گیرد. اصطلاح را اندريج کارپاتی در فوریه 2025 روی شبکه‌ی X مطرح کرد و آن را تسلیم‌شدن به ویب‌ها، پذیرش رشد نمایی و فراموش‌کردن وجود کد توصیف کرد.
نکته‌ای که اکثر توضیحات فارسی‌زبان از آن رد می‌شوند: وایب کدینگ یک تکنیک نیست، یک شیفت پارادایمی است. مرزبندی‌اش با نود-کد و لو-کد نه در ابزار، بلکه در سطح کنترلی است که روی خروجی دارید. در ادامه دقیق‌تر باز می‌کنم.
تفاوت وایب کدینگ با نود-کد و لو-کد از نظر کنترل و خروجی#
نود-کد (No-Code) یعنی کار در یک جعبه‌ی سیاه: خروجی محدود به قابلیت‌های پلتفرم است و اگر پلتفرم روزی تغییر کند، محصول شما هم تغییر می‌کند. وایب کدینگ خروجی کد واقعی میدهد؛ هر فایل را می‌توانید باز کنید، هر تابع را عوض کنید، هر کتابخانه‌ای اضافه کنید.
لو-کد (Low-Code) بین این دو ایستاده: کد می‌نویسید، ولی در چارچوب محدود یک پلتفرم. وایب کدینگ هیچ چارچوبی ندارد. همین آزادی، هم نقطه‌ی قوتش است و هم نقطه‌ی شکستش. بدون درک معماری، آزادی مطلق یعنی آشوب مطلق.
چه کسی به وایب کدینگ نیاز دارد و چه کسی نه#
اگر ایده‌ی محصولی دارید و می‌خواهید سریع یک نمونهی اولیه (MVP) بسازید تا با کاربر واقعی تست کنید، وایب کدینگ ابزار شماست. اگر می‌خواهید یک داشبورد داخلی برای تیم‌تان بسازید، باز هم مناسب است. اما اگر محصول نهایی‌تان نیاز به auth چندسطحی، تراکنش مالی یا مقیاس بالای هزاران کاربر هم‌زمان دارد، وایب کدینگ به‌تنهایی کافی نیست.
از پرامپت تا معماری: تقسیم مسئله به واحدهای قابل‌ساخت#
در وایب کدینگ، نحوه تقسیم‌بندی پرامپت‌ها عملاً معادل معماری نرم‌افزار است. یک داشبورد SaaS را نمی‌توان با یک پرامپت 500 کلمه‌ای ساخت؛ باید آن را به واحدهای مستقل شکست و هر واحد را جداگانه پرامپت کرد. این بینش در محتوای فارسی‌زبان تقریباً وجود ندارد و همین دلیل اصلی شکست‌های پیدرپی در دپلوی است.
الگوی شکست: وقتی پرامپت یکباره‌ی بزرگ نتیجه نمی‌دهد#
در پروژه‌ی نمونهی این مقاله — یک داشبورد مدیریت پروژه با Next.js و Supabase — اولین پرامپت این بود: «یک داشبورد کامل با لاگین، لیست پروژه‌ها، نمودار پیشرفت و تنظیمات کاربر بساز.» نتیجه؟ کدی که بخش عمده‌ی فایل‌ها با هم conflict داشتند، auth کار نمی‌کرد و نمودارها دادهی اشتباه می‌گرفتند. هوش مصنوعی نمی‌تواند هم‌زمان معماری، منطق و UI را در یک خروجی هماهنگ بسازد.
این الگو را در کلاس‌ها و گفتگوهای اعضای کامیونیتی بارها دیده‌ایم: هر بار که پرامپت یک‌جا بزرگ است، خروجی ناپایدار است. انگار کسی از یک آدم بخواهد هم‌زمان معماری کند، کد بزند و تست بنویسد.
چگونه یک داشبورد را به 12 پرامپت مستقل تقسیم کردیم#
پس از شکست پرامپت اول، پروژه را به این واحدها شکستیم:
- پرامپت 1: setup پروژه با Next.js و Tailwind
- پرامپت 2: schema دیتابیس در Supabase (جداول projects، tasks، users)
- پرامپت 3: صفحه‌ی login با Supabase Auth
- پرامپت 4: layout اصلی داشبورد (sidebar + header)
- پرامپت 5: لیست پروژه‌ها با CRUD
- پرامپت 6: صفحه‌ی جزئیات یک پروژه
- پرامپت 7: لیست taskها با drag-and-drop
- پرامپت 8: نمودار پیشرفت با Recharts
- پرامپت 9: صفحه‌ی تنظیمات کاربر
- پرامپت 10: اتصال بین صفحات و navigation
- پرامپت 11: responsive behavior برای موبایل
- پرامپت 12: دپلوی روی Vercel
هر پرامپت فقط یک مسئولیت داشت. نتیجه؟ هر واحد در اولین یا دومین تلاش درست کار کرد. تفاوت، نه در هوش مصنوعی، در نحوه‌ی تفکر سازنده بود.
قانون «هر پرامپت یک تصمیم معماری»#
این قانون را می‌توان این‌طور تعریف کرد: اگر در یک پرامپت بیشتر از یک تصمیم معماری وجود دارد، آن پرامپت را بشکنید. تصمیم معماری یعنی انتخابی که اگر عوض شود، بخش‌های دیگر هم باید عوض شوند. مثلاً «از Supabase استفاده کن» یک تصمیم معماری است. «رنگ دکمه‌ها آبی باشد» نیست. پرامپت‌ها را بر اساس تصمیمات معماری تقسیم کنید، نه بر اساس صفحات ظاهری.
مراحل عملی ساخت یک SaaS Dashboard با Cursor و Supabase#
پروژه‌ی نمونهی این مقاله یک داشبورد مدیریت پروژه با Next.js و Supabase است که با Cursor ساخته شد. از setup اولیه تا دپلوی، 7 مرحله‌ی مشخص وجود داشت. در مرحله‌ی ششم، پروژه با dependency hell مواجه شد — همان‌جایی که وایب کدینگ بدون درک معماری فرو می‌ریزد و معمولاً سازنده تسلیم میشود.
گام‌به‌گام: از setup تا دپلوی#
- Setup: با پرامپت «npx create-next-app بساز با TypeScript و Tailwind» پروژه ایجاد شد. بدون مشکل.
- دیتابیس: schema در Supabase Dashboard ساخته شد. پرامپت فقط برای نوشتن typeهای TypeScript استفاده شد.
- Auth: Supabase Auth با پرامپت جداگانه اضافه شد. یک بار خطای environment variable داد، اصلاح شد.
- UI: layout و صفحات با پرامپت‌های مرحله‌ای ساخته شدند. هر صفحه یک پرامپت.
- منطق: CRUD operations و نمودارها اضافه شدند. اینجا اولین بار کد تولیدشده با AI با کد قبلی conflict کرد.
- دپلوی: روی Vercel deploy شد. Build fail داد. خطا: two versions of React در node_modules.
- رفع: package.json دستی ویرایش شد و lock file حذف و بازتولید گردید.
جایی که پروژه شکست: breaking changes در کد تولیدشده با AI#
در مرحله‌ی پنجم، پرامپت برای اضافه‌کردن نمودارها کدی تولید کرد که از نسخه‌ی قدیمی‌تر Recharts استفاده می‌کرد. اما در setup اولیه، نسخه‌ی جدید نصب شده بود. نتیجه: build fail در دپلوی. هوش مصنوعی نمی‌داند چه نسخه‌هایی در پروژه‌ی شما نصب‌اند، مگر اینکه در پرامپت صریح بگویید. این یکی از پرهزینه‌ترین اشتباهات رایج است؛ چون معمولاً سازنده فقط در مرحله‌ی دپلوی متوجه میشود و ساعت‌ها وقت برای کشف علت می‌سوزد.
بازگشت و اصلاح: چگونه dependency hell را حل کردیم#
راه‌حل سه قدم داشت: اول، در پرامپت بعدی صریح بنویسید «از نسخه‌ی X کتابخانه Y استفاده کن». دوم، package.json را بعد از هر پرامپت چک کنید. سوم، اگر دو dependency با هم conflict دارند، lock file را حذف و npm install دوباره اجرا کنید. این سه کار بدون دانش برنامه‌نویسی هم قابل‌انجام است، به شرطی که بدانید package.json چیست.
کدام ابزار وایب کدینگ برای چه نوع محصولی مناسب است؟#
انتخاب ابزار وایب کدینگ قبل از مشخص‌کردن نوع محصول، اشتباه رایجی است که به سرخوردگی منجر میشود. Cursor برای پروژه‌های کدنویسی‌محور مناسب است، Bolt.new و Lovable برای ساخت سریع وب‌اپ از صفر، و v0 by Vercel برای UIهای React. هر ابزار نقطه‌ی قوت و ضعف مشخصی دارد و هیچ‌کدام «بهترین ابزار» مطلق نیست.
جدول مقایسه ابزارها#
| ابزار | نوع خروجی | مناسب برای | محدودیت اصلی |
|---|---|---|---|
| Cursor | کد واقعی در IDE | پروژه‌های چندفایلی، Next.js، React | نیاز به درک ساختار پروژه |
| Windsurf | کد واقعی در IDE | مشابه Cursor، با تمرکز بر flow | اکوسیستم کوچک‌تر از Cursor |
| Bolt.new | پروژه‌ی کامل قابل‌دانلود | ساخت سریع از صفر بدون setup | کنترل محدود روی dependencyها |
| Lovable | پروژه‌ی React + Supabase | وب‌اپ با auth و دیتابیس | lock-in به Supabase |
| v0 by Vercel | کامپوننت React | UI و landing page | فقط UI، نه منطق کامل |
| Replit | پروژه‌ی کامل آنلاین | یادگیری و prototyping سریع | عملکرد محدود در پروژه‌های سنگین |
معیار انتخاب: نوع محصول را اول مشخص کن، بعد ابزار#
اگر محصول شما یک داشبورد با auth و CRUD است، Cursor + Supabase بهترین ترکیب است. اگر فقط یک landing page می‌خواهید، v0 یا Lovable کافی‌اند. اگر می‌خواهید بدون setup از صفر شروع کنید، Bolt.new مناسب‌تر است. اما اگر اپ موبایل با push notification می‌خواهید، هیچ‌کدام از این ابزارها به‌تنهایی کافی نیستند.
سقف وایب کدینگ: کجا دقیقاً شکست می‌خورد؟#
سقف وایب کدینگ در سه نقطه ظاهر میشود: auth چندسطحی (RBAC)، منطق پیچیده‌ی کسب‌وکار با شاخه‌های متعدد، و مقیاس‌پذیری بالای هزاران کاربر هم‌زمان. برای داشبورد، landing page و ابزار داخلی، خروجی وایب کدینگ مستقیماً قابلاستفاده است؛ برای این سه مورد، نه.
محدودیت‌های امنیتی و آسیب‌پذیری‌های شناخته‌شده در کد AI-generated#
کدهای تولیدشده با هوش مصنوعی آسیب‌پذیری‌هایی دارند که در کدهای دستی کمتر دیده میشود: injection در queryهای دیتابیس، عدم اعتبارسنجی ورودی‌ها، یا قرار‌دادن secretها در کد کلاینت. برای MVP با ترافیک پایین، ریسک قابل‌قبول است. اما قبل از ورود دادهی حساس یا درگاه پرداخت، یک review امنیتی توسط توسعه‌دهنده ضروری است. این یک توصیه‌ی محتاطانه است، نه یک هشدار اغراق‌آمیز.
مشکل AI Slop در UX: UIهای generic و راه‌حل شکستن الگو#
اگر بدون دستورالعمل مشخص پرامپت کنید، خروجی UI یک الگوی تکراری دارد: رنگ‌های آبی-سفید، فونت‌های پیش‌فرض، spacingهای generic. به این می‌گویند AI Slop. راه‌حل: در پرامپت‌ها reference بدهید. «مشابه layout این صفحه از Linear»، «با palette این سایت». یا کلاً یک design system مشخص را در پرامپت تعریف کنید و بگویید همه‌ی صفحات از همان پیروی کنند. بدون این کار، محصول شما بوی «ساخته‌ی هوش مصنوعی» میدهد و کاربر واقعی اعتماد نمیکند.
نقشه تصمیم‌گیری: وایب کدینگ، hybrid یا تیم فنی#
- وایب کدینگ خالص: داشبورد داخلی، landing page، MVP برای تست فرضیه، ابزار اتوماسیون ساده
- Hybrid (وایب کدینگ + یک توسعه‌دهنده پاره‌وقت): محصول با auth چندسطحی، پرداخت آنلاین، نیاز به API integration
- تیم فنی: مقیاس بالای کاربر، compliance، منطق پیچیده‌ی کسب‌وکار، اپ موبایل native
وقتی کد خراب شد: دیباگ بدون دانش برنامه‌نویسی#
دیباگ در وایب کدینگ با دیباگ سنتی متفاوت است. وقتی کد تولیدشده با هوش مصنوعی خراب میشود، الگوی مؤثر «بازگشت به پرامپت قبلی و اصلاح ورودی» است، نه خیره‌شدن به stack trace. اگر این الگو را بلد نباشید، یک باگ ساده میتواند کل پروژه را متوقف کند.
الگوی بازگشت به پرامپت: چرا اصلاح ورودی بهتر از اصلاح خروجی است#
وقتی باگ می‌بینید، بهجای اینکه در کد بگردید و خط را عوض کنید، بروید به همان پرامپتی که آن کد را تولید کرد. یک جمله اضافه کنید: «دقت کن که import Recharts از نسخه‌ی جدید باشد» یا «validations را قبل از ارسال به دیتابیس انجام بده». خروجی جدید معمولاً باگ را حل می‌کند. اصلاح مستقیم کد بدون فهم معماری، در بلندمدت مشکل‌سازتر است — چون هر تغییر دستی، سازگاری با پرامپت‌های بعدی را به خطر می‌اندازد.
چه زمانی باید از ابزار یا فرد دیگری کمک گرفت#
سه نشانه دارد: اول، اگر بعد از سه بار اصلاح پرامپت، باگ حل نشد. دوم، اگر خطا در dependencyهاست و نمیفهمید کدام package conflict دارد. سوم، اگر باگ امنیتی است (مثلاً دادهی کاربر در URL ظاهر شده). در این سه حالت، یک توسعه‌دهنده‌ی پاره‌وقت یا یک community فنی میتواند در چند دقیقه کاری کند که شما چند ساعت وقت می‌گذارید.
از MVP تا محصول: چه زمانی تیم فنی لازم میشود؟#
فاصله‌ی بین MVP ساخته‌شده با وایب کدینگ و محصول قابل‌نگهداری، مرحله‌ای است که بسیاری نادیده می‌گیرند. وقتی خودتان MVP ساخته‌اید، قدرت چانه‌زنی‌تان در مذاکره با توسعه‌دهنده‌های استخدامی تغییر می‌کند — چون دیگر نمی‌توانند بگویند «این کار سه ماه طول می‌کشد» وقتی شما سه هفته ساختید.
اثر وایب کدینگ بر مذاکره با توسعه‌دهنده و استخدام تیم فنی#
وقتی یک MVP کار می‌کند و شما می‌توانید بگویید «auth را با Supabase ساختم، نمودارها با Recharts، و در این نقطه build fail میدهد»، مذاکره‌ی شما با توسعه‌دهنده کاملاً عوض میشود. دیگر فرض نمی‌کنند شما هیچ‌چیز نمی‌دانید. scope کار مشخص میشود و قیمت‌گذاری منطقی‌تر میشود.
مسیر نگهداری و تکرار (Iteration) بدون دانش فنی#
نگهداری MVP ساخته‌شده با وایب کدینگ ممکن است، به شرطی که پرامپت‌های اولیه را مستند کنید. هر بار که یک باگ پیدا میشود، بهجای اصلاح کد، پرامپت مربوطه را اصلاح کنید. این یعنی یک «دفترچه‌ی پرامپت» داشته باشید که نقش changelog را بازی می‌کند. بدون این دفترچه، بعد از دو هفته هیچ‌کس — حتی خودتان — نمی‌فهمد کدام پرامپت کدام کد را تولید کرده.
تفکیک وایب کدینگ برای کسب‌وکار از وایب کدینگ برای یادگیری#
اگر هدف‌تان یادگیری است، وایب کدینگ عالی است. اگر هدف‌تان ساختن محصولی است که به کاربر واقعی سرویس میدهد، وایب کدینگ فقط فاز اول است. فاز دوم — نگهداری، مقیاس‌دهی و امنیت — نیاز به تصمیمات معماری دارد که بدون درک فنی، هر روز هزینه‌ی بیشتری تحمیل می‌کند.
وایب کدینگ ابزار قدرتمندی برای نمونه‌سازی و کشف محصول است، اما جایگزین مهندسی نرم‌افزار نیست. کلید موفقیت نه در انتخاب ابزار، بلکه در توانایی شکستن مسئله به واحدهای قابل‌مدیریت است. اگر می‌خواهید این مهارت را با پروژه‌ی واقعی و در کنار کسانی که همان مسیر را رفته‌اند تمرین کنید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول دقیقاً روی همین نقطه کار می‌کند: از پرامپتنویسی ساختارمند تا دپلوی واقعی.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.