ویدیوهای آموزشی وایب کدینگ یک خط می‌فروشند: پرامپت بنویس، اپ بگیر. این تصویر واقعی نیست. در یک پروژه‌ی عملی، پرامپت اول فرمی می‌سازد که به هیچ بک‌اندی وصل نیست، پرامپت دوم خطای CORS می‌دهد، و پرامپت سوم گیر متغیر محیطی (Environment Variable) می‌افتد. این چرخهی تکراری هزینه‌ی پنهانی دارد که در هیچ ویدیوی تبلیغاتی گفته نمی‌شود.
وایب کدینگ چیست و چرا پرامپت اول تو را ناامید می‌کند#
وایب کدینگ (Vibe Coding) روش توسعه‌ی نرم‌افزاری است که در آن با زبان طبیعی به هوش مصنوعی کد می‌دهی و خروجی را تکرار و اصلاح میکنی، بدون اینکه کد را بخوانی. پرامپت اول ناامیدکننده است چون مدل بدون بافت کامل پروژه تصمیم‌های معماری می‌گیرد که در لحظه منطقی‌اند ولی با افزودن هر قابلیت جدید متناقض می‌شوند.
منشأ اصطلاح و تعریف کارپاتی#
آندری کارپاتی در فوریه 2025 در توییتی نوشت که روی پروژه‌ای با وایب کدینگ کار می‌کند و منظورش این بود: کد را نمی‌خواند، فقط پرامپت می‌نویسد و خروجی را تست می‌کند. این تعریف دو نکته‌ی تعیین‌کننده دارد. اول: وایب کدینگ یک فرآیند توسعه است، نه تکنیک نوشتن پرامپت. دوم: حالت ایده‌آل آن «نخواندن کد» است، ولی در عمل هر کسی که چند چرخهی اصلاح از سر بگذراند مجبور میشود حداقل ساختار پروژه را بفهمد.
الگوی تکرارشونده در پروژه‌های اعضای کامیونیتی اسکول: سازندگان غیرفنی بعد از دو تا چهار هفته کار با ابزارهای وایب کدینگ، ناخودآگاه مفاهیمی مثل Git، وابستگی (Dependency) و متغیر محیطی را یاد می‌گیرند. این یادگیری اجباری است، نه انتخابی. کسی که از آن فرار کند، در چرخهی اصلاح سوم گیر می‌کند.
چرا پرامپت اول شکست می‌خورد#
مدل هوش مصنوعی بدون بافت پروژه تصمیم‌های معماری می‌گیرد. وقتی می‌گویی «یک صفحهی فرود با فرم ایمیل بساز»، مدل خودش تصمیم می‌گیرد state را کجا نگه دارد، فرم را چطور اعتبارسنجی کند و داده را چطور ذخیره کند. این تصمیم‌ها در لحظه‌ی تولید منطقی‌اند، ولی وقتی بخواهی چیزی اضافه کنی، متناقض می‌شوند.
تفاوت وایب کدینگ با مهندسی پرامپت (Prompt Engineering) دقیقاً همین‌جاست. مهندسی پرامپت یک تکنیک نوشتن است. وایب کدینگ یک فرآیند توسعه‌ی نرم‌افزار است که در آن نوشتن پرامپت فقط یکی از مراحل است — و نه حتی مهم‌ترین مرحله‌اش.
فرق وایب کدینگ با نو-کد و لو-کد چیست؟#
نو-کد (No-code) و لو-کد (Low-code) خروجی‌شان محدود به بلوک‌های ازپیش‌ساخته یا ترکیب محدود بلوک و کد است. وایب کدینگ کد واقعی تولید می‌کند که قابل export، قابل ویرایش دستی و قابل اتصال به هر سرویسی است. این تفاوت بنیادین تعیین می‌کند محصولت بعداً قابل توسعه هست یا نه — و اگر قابل توسعه نباشد، هر چیزی که ساخته‌ای دور ریختنی است.
نو-کد مثل Webflow یا Bubble است: کشیدن و رها کردن، بدون دسترسی به کد. مناسب فرم‌ها و صفحات ساده. لو-کد مثل Retool است: ترکیب بلوک و کد سفارشی، نیاز به حداقل دانش فنی. وایب کدینگ از هر دو متفاوت است چون خروجی‌اش کد واقعی است، نه بلوک قفل‌شده.
| معیار | نو-کد | لو-کد | وایب کدینگ | توسعه‌ی سنتی |
|---|---|---|---|---|
| نوع خروجی | بلوک‌های ازپیش‌ساخته | ترکیب بلوک و کد | کد واقعی قابل export | کد واقعی نوشته‌شده توسط انسان |
| سطح کنترل | محدود به پلتفرم | متوسط | بالا (بعد از export) | کامل |
| قابلیت export | معمولاً خیر | محدود | بله | بله |
| نیاز به دانش فنی | صفر | کم | کم تا متوسط (در دیباگ) | زیاد |
| مناسب‌ترین نوع پروژه | صفحهی ساده، فرم | داشبورد داخلی، اتوماسیون | MVP و اعتبارسنجی ایده | محصول بلندمدت، سیستم پیچیده |
ابزارهای وایب کدینگ: کدام برای چه محصولی ساخته شده#
هر ابزار وایب کدینگ برای نوع خاصی از خروجی بهینه شده و انتخاب ابزار بر اساس نوع محصول — وبسایت استاتیک، اپ با backend، اپ موبایل، داشبورد — مهم‌تر از انتخاب بر اساس محبوبیت است. Bolt.new برای MVP وب عالی است ولی برای داشبورد داخلی بی‌فایده. اشتباه رایج در کامیونیتی اسکول: انتخاب ابزار بر اساس «چه کسی بیشتر در توییتر درباره‌اش حرف می‌زند»، نه بر اساس خروجی موردنیازت.
ابزارهای ساخت از صفر#
Bolt.new و Lovable بهترین گزینه‌ها برای MVPهای سریع وب با backend ساده‌اند. خروجی قابل export دارند ولی محدود به فریمورک خاص خودشان. Cursor و Windsurf کنترل کامل‌تر روی ساختار پروژه می‌دهند و نیاز به آشنایی حداقلی با فایل‌ساختار دارند. v0 by Vercel تخصصی برای UI و کامپوننت React است، نه برای منطق بکاند. Replit محیط ابری کامل با deploy سریع است و مناسب کسانی است که نمی‌خواهند local setup کنند.
ابزارهای مکمل در چرخهی اصلاح#
GitHub Copilot و Claude نقش مکمل دارند، نه ابزار اصلی ساخت پروژه از صفر. وقتی در Cursor گیر میکنی و خطا را نمی‌فهمی، کپی کردن error message در Claude و پرسیدن «این خطا یعنی چه و چطور حلش کنم» مؤثرتر از نوشتن پرامپت جدید در ابزار اصلی است. این الگو در گفتگوهای اعضای کامیونیتی اسکول بارها تکرار شده: کسی که پرامپت جدید می‌نویسد، معمولاً مشکل را بدتر می‌کند.
| ابزار | نوع خروجی | سطح کنترل | قابلیت export | نیاز به دانش فنی |
|---|---|---|---|---|
| Bolt.new | وب‌اپ با backend | متوسط | محدود به فریمورک | کم |
| Cursor | هر نوع پروژه | بالا | کامل | متوسط |
| v0 by Vercel | UI و کامپوننت | پایین | کامل (React) | کم |
| Replit | وب‌اپ کامل | متوسط | کامل | کم |
| Lovable | وب‌اپ با backend | متوسط | محدود | کم |
ساخت MVP با وایب کدینگ: روایت یک پروژه‌ی واقعی از پرامپت تا دیپلوی#
ساخت یک صفحهی فرود با فرم ثبتنام و بکاند ساده با وایب کدینگ، از پرامپت اول تا محصول قابل‌استفاده، شامل 5 مرحله و حداقل 4 چرخهی اصلاح است. این روایت یک پروژه‌ی واقعی است که در کامیونیتی اسکول مستند شده و محدودیت‌هایش پنهان نشده‌اند.
- تعریف دامنه‌ی MVP: «یک صفحهی فرود + فرم ایمیل + ذخیره در دیتابیس» نه «یک SaaS کامل». اگر دامنه را مشخص نکنی، AI خودش دامنه تعیین می‌کند و معمولاً بیش از حد پیچیده میشود. این مهم‌ترین مرحله است و اکثر شکست‌ها از اینجا شروع می‌شوند.
- پرامپت اولیه در Bolt.new: خروجی یک صفحهی زیبا بود که فرم — بگذار دقیق بگویم — به هیچ backend متصل نبود. دکمه‌ی submit کار می‌کرد ولی هیچ داده‌ای ذخیره نمی‌شد.
- چرخهی اصلاح اول: افزودن Supabase برای ذخیره‌ی ایمیل‌ها. اتصال شکست چون پرامپت دوم بدون ذکر schema دقیق دیتابیس نوشته شده بود. اصلاح پرامپت با ذکر فیلدها و نوع داده‌ها.
- چرخهی اصلاح دوم و سوم: خطای CORS در مرورگر. مشکل متغیر محیطی در production build. اینجا مجبور شدی console error را بخوانی — اولین بار.
- Export کد و deploy روی Vercel: ساختار پوشهها را دیدی. فهمیدی که بدون درک این ساختار، هر تغییر بعدی پرهزینه است.
نکته‌ی کلیدی این روایت: هر بار که خروجی اشتباه بود، پرامپت را دقیق‌تر نوشتی. این خودش نوعی یادگیری فنی غیررسمی است. وایب کدینگ تو را تبدیل به برنامه‌نویس نمی‌کند، ولی شهود فنی حداقلی می‌سازد — و این شهود حداقلی، مرز بین کسی است که پروژه‌اش زنده می‌ماند و کسی که در چرخهی اصلاح پنجم رها می‌کند.
اگر می‌خواهی این چرخه را در یک پروژه‌ی واقعی و مستندشده از ایده تا لانچ ببینی، مستند 10 قسمتی ساخت یک پلتفرم با ثبتنام رایگان قابل مشاهده است.
چه زمانی وایب کدینگ شکست می‌خورد و باید توسعه‌دهنده استخدام کنی؟#
وقتی پروژه از MVP فراتر می‌رود و نیاز به یکپارچه‌سازی با سیستم‌های موجود، مقیاس‌پذیری یا امنیت سطح‌بالا دارد، وایب کدینگ بدون حضور یک نفر که کد را بخواند و دیباگ کند به بدهی فنی (Technical Debt) فرو می‌رود. مرزها مشخص‌اند و باید قبل از رسیدن به آن‌ها تصمیم بگیری، نه بعد از آنکه محصول در پروداکشن شکست.
مرزهای شکست#
مرز اول: تغییر معماری. وقتی باید ساختار داده یا auth را عوض کنی، AI بدون بافت کامل تصمیم‌های متناقض می‌گیرد. هر پرامپت جدید بخشی از کد قبلی را می‌شکند.
مرز دوم: یکپارچه‌سازی legacy. اتصال به ERP، CRM یا APIهای داخلی که مستندات ناقص دارند. AI نمی‌تواند چیزی را که مستند نشده بفهمد.
مرز سوم: مقیاس. ترافیک بالا، نیاز به کشینگ، load balancing، بهینه‌سازی query. این‌ها تصمیم‌های معماری‌اند که نیاز به درک سیستم دارند، نه نوشتن پرامپت.
مرز چهارم: امنیت. پرداخت، داده‌ی حساس، احراز هویت چندعاملی. یک خطای امنیتی در کد تولیدشده می‌تواند محصول را نابود کند و اعتماد کاربر را برگشت‌ناپذیر از دست بدهی.
الگوی تصمیم‌گیری#
اگر محصولت قرار است بیش از 3 ماه زنده بماند و کاربر واقعی داشته باشد، یک نفر که کد را review کند لازم است. این به‌معنای استخدام یک تیم کامل نیست — این توصیف رایج در مقالات، نیاز واقعی را بزرگ‌نمایی می‌کند. حتی یک نفر پاره‌وقت که ماهی یک‌بار کد را بخواند، از انباشت بدهی فنی جلوگیری می‌کند. برای شروع، راهنمای code review برای تیم‌های کوچک را بخوان.
هزینه‌ی پنهان وایب کدینگ: زمان دیباگ که کسی بهت نمی‌گوید#
اشتراک ابزارها ارزان است، ولی اگر هیچ شهود فنی نداشته باشی، زمان spent روی debugging خروجی AI و بازسازی ساختار پروژه می‌تواند از زمان توسعه‌ی سنتی بیشتر باشد. هزینه‌ی واقعی وایب کدینگ را باید در سه لایه ببینی: مستقیم، زمانی، و پنهان.
هزینه‌ی مستقیم: اشتراک ابزارها. Cursor، Replit، Bolt و غیره اشتراک ماهانه دارند. قیمت‌ها مرتب تغییر می‌کنند و ذکر عدد دقیق گمراه‌کننده است. مقایسه‌ی کیفی: ابزارهایی که local هستند (Cursor) اشتراک‌شان پایین‌تر است ولی نیاز به hardware دارند. ابزارهای ابری (Bolt.new) بدون setup کار می‌کنند ولی محدودیت session دارند.
هزینه‌ی زمانی: هر چرخهی refine بین چند دقیقه تا چند ساعت طول میکشد، بسته به پیچیدگی خطا. خطای CORS ساده چند دقیقه حل میشود. مشکل متغیر محیطی در production build ممکن است یک بعدازظهر کامل ببرد.
هزینه‌ی پنهان: وقتی کد AI را نمی‌خوانی و فقط پرامپت بعدی را می‌نویسی، بدهی فنی انباشته میشود. کد کار می‌کند تا یک‌بار نیاز به تغییر ساختاری پیدا کنی و آن‌جا متوجه می‌شوی کسی کد را نمی‌فهمد — نه تو، نه AI.
ریسک ownership و راه‌حل عملی#
اگر از ابزارهایی مثل Bolt.new استفاده میکنی و کد را export نمی‌کنی، محصولت در گرو زنده‌بودن آن سرویس است. این ریسک در اکثر مقالات ذکر نمی‌شود. راه‌حل: از همان روز اول کد را export کن، روی GitHub خودت بگذار و ساختار پوشهها را بشناس. حتی اگر نمی‌فهمی، حداقل نسخهی قابل‌بازگردانی داری.
آیا کد تولیدشده توسط هوش مصنوعی امن و قابل‌توسعه است؟#
کد تولیدشده توسط AI از نظر عملکردی کار می‌کند، ولی بدون بازبینی انسانی معمولاً آسیب‌پذیری‌های امنیتی ساده دارد. عدم اعتبارسنجی ورودی (Input Validation)، کلیدهای API در کد، و وابستگی‌های بدون بررسی نسخه، سه مشکل تکرارشونده‌اند که در هر پروژه‌ی بررسی‌شده در کامیونیتی اسکول حداقل یکی از آن‌ها پیدا شده است.
سه مشکل امنیتی تکرارشونده#
مشکل اول: کلیدهای API و secrets داخل کد hard-code می‌شوند. AI برای سادگی، کلید را مستقیم در فایل می‌نویسد. باید به متغیر محیطی منتقل شوند.
مشکل دوم: اعتبارسنجی ورودی معمولاً ناقص است. فرم ایمیل فقط از نظر ظاهری validate میشود، نه از نظر امنیتی. SQL injection یا XSS در کد تولیدشده رایج است.
مشکل سوم: وابستگی‌ها بدون بررسی نسخه نصب می‌شوند. AI آخرین نسخه را نصب می‌کند بدون اینکه بداند آیا آن نسخه آسیبپذیری شناخته‌شده دارد یا نه.
چک‌لیست امنیتی قبل از deploy#
- آیا هیچ کلید API یا secret در کد نیست؟ همه در متغیر محیطی‌اند؟
- آیا ورودیهای فرم از سمت server هم validate می‌شوند، نه فقط client؟
- آیا وابستگی‌ها از نظر آسیبپذیری بررسی شده‌اند؟
- آیا endpointهای API احراز هویت دارند؟
- آیا داده‌ی حساس (ایمیل، رمز) رمزنگاری‌شده ذخیره میشود؟
برای جزئیات بیشتر، راهنمای امنیت API برای سازندگان غیرفنی را بخوان.
نقش ایجنت هوش مصنوعی (AI Agent) در آینده: ابزارهایی که خودشان کد را review و fix می‌کنند، هنوز در مرحله‌ی اولیه‌اند. در حال حاضر هیچ ابزاری به‌طور کامل جایگزین بازبینی انسانی نشده است. اگر کسی ادعای متفاوتی دارد، یا در حال فروش چیزی است یا هنوز یک پروژه‌ی واقعی از سر نگذرانده.
وایب کدینگ کجا جواب می‌دهد و کجا جواب نمی‌دهد#
وایب کدینگ برای MVP و اعتبارسنجی ایده عالی است. برای محصولی که قرار است ماه‌ها رشد کند، به یک نفر که کد را بخواند و دیباگ کند نیاز داری. این نتیجه‌ی عملی کل مقاله است: وایب کدینگ جایگزین نوشتن کد میشود، نه جایگزین فهمیدن کد.
اگر می‌خواهی این چرخهی شکست و اصلاح را در محیطی یاد بگیری که بقیه‌ی سازندگان هم از همان مسیر رد شده‌اند، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی اسکول دقیقاً روی همین فرآیند کار می‌کند: ساخت محصول با AI بدون کدنویسی، از پرامپت اول تا دیباگ بیستم.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.