وایب کدینگ (Vibe Coding) کد واقعی تولید می‌کند، نه دمو. اما بین اولین دیپلوی موفق و ماه ششم نگهداشت، شکافی وجود دارد که بیشتر سازندگان مستقل از آن غافل‌اند: بدون درک مفهومی معماری، همان کدی که در دو روز ساخته‌اید، در سه هفته به قبری تبدیل می‌شود که هر پرامپت جدید، سنگین‌تر از قبلی دفن‌اش می‌کند.

وایب کدینگ چیست و چرا با نوکد فرق دارد؟#

وایب کدینگ روشی است که در آن با زبان طبیعی به مدل زبانی پرامپت می‌دهید و کد قابل‌اجرا تولید می‌شود. اصطلاح را Andrej Karpathy در فوریه 2025 معرفی کرد و آن را «کاملاً تسلیم شدن در برابر ویب، پذیرش رشد نمایی و فراموش کردن وجود کد» توصیف کرد. تفاوت بنیادی با نوکد (No-Code) در خروجی است: ابزارهای نوکد شما را در اکوسیستم خودشان قفل می‌کنند، ولی وایب کدینگ فایل‌های واقعی می‌سازد که در هر IDE باز می‌شوند.

لوکد (Low-Code) دقیقاً بین این دو ایستاده: آزادی نسبی دارد ولی همچنان محدود به پلتفرم است. اگر خروجی را به توسعه‌دهنده بعدی تحویل بدهید، نوکد قفل پلتفرم دارد ولی وایب کدینگ کد واقعی و مهاجرت‌پذیر است.

مثال ملموس: خروجی Bubble یک پروژه درون‌پلتفرمی است که فقط با اکانت فعال آن ابزار قابل ویرایش است. خروجی وایب کدینگ یک پوشه فایل است — HTML، TypeScript، SQL — که می‌توانید در VS Code باز کنید، به گیت بگذارید و به هر کسی بدهید.

پیش‌نیاز واقعی: نه صفر دانش، بلکه درک مفهومی معماری#

پیش‌نیاز واقعی وایب کدینگ، درک مفهومی از ساختار داده، جریان داده (Data Flow) و مرزهای سرویس است. برخلاف ادعای «بدون هیچ دانشی بسازید»، شما سینتکس نمی‌نویسید، ولی باید بدانید فرانت‌اند (Frontend) و بک‌اند (Backend) چه چیزی را جدا نگه می‌دارند. بدون این درک، پرامپت اولتان ساختارمند نخواهد بود.

نقش شما در وایب کدینگ «مترجم فنی» است: کسی که معماری را به پرامپت ساختاریافته تبدیل می‌کند و خروجی را اعتبارسنجی می‌کند. نه کد می‌نویسد، نه ناکد می‌کند.

یک مثال که در کلاس‌ها مکرر تکرار می‌شود: سازنده‌ای با Lovable یک اپ مدیریت وظایف ساخت. پرامپت اولش این بود: «یک اپ بساز که کاربر لاگین کند، تسک اضافه کند و لیست ببیند.» خروجی یک فایل تک‌صفحه‌ای بود که auth، UI و منطق کسب‌وکار همه در یک کامپوننت React ادغام شده بودند. دو هفته بعد خواست دیتابیس را از Firebase به Supabase تغییر دهد و فهمید تفکیک ممکن نیست.

چک‌لیست دانش مفهومی قبل از شروع#

  • آیا می‌دانید frontend (رابط کاربری) و backend (منطق و دیتابیس) چه چیزی را جدا نگه می‌دارد؟
  • آیا می‌دانید API چیست و چرا بین دو سرویس قرار می‌گیرد؟
  • آیا می‌توانید بگویید داده از کجا می‌آید، کجا ذخیره می‌شود و کجا مصرف می‌شود؟
  • آیا می‌دانید auth (احراز هویت) باید در لایه‌ای جدا از منطق کسب‌وکار باشد؟

منابع یادگیری سریع معماری برای غیربرنامه‌نویس‌ها#

نیاز به مطالعه عمیق نیست. یک ویدیوی ۲۰ دقیقه‌ای درباره «معماری سه‌لایه» (Three-Tier Architecture) و یک پست وبلاگ درباره تفاوت client و server کافی است. هدف این است که پرامپت اولتان ساختارمند باشد، نه «یک اپ بساز».

مقایسه ابزارها: Cursor، Bolt.new، Lovable و v0#

مقایسه ابزارهای وایب کدینگ بر اساس نوع خروجی، سطح کنترل و مناسب بودن برای هر مرحله از چرخه ساخت انجام می‌شود. انتخاب اشتباه ابزار، وقت را در حلقه پرامپت بی‌پایان می‌سوزاند. این جدول بر اساس تجربه‌ی میدانی پروژه‌های واقعی در کامیونیتی اسکول تنظیم شده است.

ابزارنوع خروجیسطح کنترلمناسب برایمحدودیت اصلی
Cursorکد واقعی در IDEبالاکسی که حداقل سینتکس را می‌فهمدنیاز به دانش پایه‌ی برنامه‌نویسی
Bolt.newپروژه کامل قابل‌ویرایش در مرورگرمتوسطMVP سریع با فریم‌ورک مشخصمحدودیت در اتصال سرویس‌های خارجی
Lovableپروژه React + Supabaseمتوسطاپ‌های CRUD با auth و دیتابیسخروجی محدود به الگوی خود پلتفرم
v0 by Vercelکامپوننت React + Tailwindمتوسططراحی UI و رابط کاربریمنطق بک‌اند تولید نمی‌کند

کدام ابزار برای کدام نوع پروژه؟#

اگر یک صفحه لندینگ با فرم ثبت‌نام می‌خواهید: v0 یا Lovable. اگر یک اپ با auth، دیتابیس و چند endpoint: Bolt.new یا Lovable. اگر پروژه‌ای دارید که قرار است بعداً توسعه‌دهنده واقعی تحویل بگیرید: Cursor.

اشتباه رایج: شروع با ابزار اشتباه و مهاجرت پرهزینه#

انتخاب Lovable برای پروژه‌ای که قرار است به Next.js مهاجرت کند، اشتباه استراتژیک است، نه فنی. سازنده‌ای که با Lovable شروع کرده و بعداً فهمیده باید مهاجرت کند، عملاً از صفر شروع می‌کند. قبل از انتخاب ابزار، بپرسید: «خروجی این ابزار ۶ ماه بعد قابل تغییر است یا نه؟»

از ایده تا دیپلوی: گام‌های ساخت یک MVP با وایب کدینگ#

ساخت یک MVP با وایب کدینگ از تعریف معماری در پرامپت اول تا اولین دیپلوی، پنج گام مشخص دارد. این مراحل از چند پروژه‌ی مستقل در کامیونیتی اسکول استخراج شده‌اند و ترتیبشان اهمیت دارد: پرش از هر گام، بازگشت اجباری به گام قبل را در پی دارد.

  1. تعریف معماری قبل از پرامپت: به‌جای «یک اپ بساز»، بگویید «یک اپ با این ساختار بساز: frontend در React، backend در Supabase، auth در لایه جدا». پرامپت ساختاریافته خروجی ساختاریافته می‌دهد.
  2. پرامپت اولیه و بازبینی ساختار فایل‌ها: بعد از تولید، فقط ساختار پوشه‌ها و نام فایل‌ها را چک کنید. اگر همه در یک فایل است، از اول پرامپت بدهید.
  3. اتصال به سرویس‌های خارجی: auth، دیتابیس، درگاه پرداخت. هر کدام را جدا و با پرامپت مستقل اضافه کنید. ترکیب همه در یک پرامپت = فاجعه.
  4. تست با داده واقعی، نه دمو: با یک کاربر واقعی و داده واقعی وارد شوید. اگر با دو رکورد کار می‌کند ولی با دویست رکورد کند است، مشکل مقیاس دارید.
  5. دیپلوی و پایش اولیه: Vercel، Netlify یا Render. بعد از دیپلوی، لاگ‌ها را چک کنید. در پروژه‌های کامیونیتی اسکول، اولین خطای production اغلب مربوط به authentication یا CORS بوده.

پرامپت ساختاریافته vs پرامپت آزاد — چرا اولی جواب می‌دهد#

پرامپت آزاد: «یک اپ فروشگاه بساز». خروجی: یک فایل با ۴۰۰ خط کد که هیچ‌کس نمی‌فهمد. پرامپت ساختاریافته: «یک اپ فروشگاه با ساختار زیر بساز: صفحه لیست محصولات، صفحه جزئیات، سبد خرید، checkout. هر صفحه یک کامپوننت جدا. state در یک store مرکزی.» خروجی: فایل‌های تفکیک‌شده، قابل‌فهم، قابل‌ویرایش.

چرخه بازخورد: وقتی AI کد را خراب می‌کند، چه‌کار کنید#

وقتی AI با یک پرامپت جدید، کدی را که قبلاً درست کار می‌کرد می‌شکند: اول از version control برگردید (git checkout). اگر version control ندارید، پرامپت بعدی را increment بدهید، نه rewrite. «فقط این تابع را تغییر بده» به‌جای «کل فایل را دوباره بنویس».

چرا پروژه‌های وایب‌کدینگ در هفته سوم می‌میرند؟#

دلیل مرگ پروژه‌های وایب‌کدینگ در هفته سوم، «حلقه پرامپت بی‌پایان» است: سازنده بدون درک معماری، AI را وادار به بازنویسی کامل می‌کند تا کد به نقطه‌ای برگردد که قبلاً کار می‌کرد. هر بازنویسی، تصمیمات قبلی را از بین می‌برد و پروژه عملاً به عقب می‌رود. این الگو در پروژه‌های واقعی بارها دیده شده است.

مکانیزم دقیق: شما یک پرامپت برای «افزودن فیلتر به لیست» می‌دهید. AI کل فایل را بازنویسی می‌کند. فیلتر اضافه می‌شود ولی دکمه‌ی «حذف» که قبلاً کار می‌کرد، از بین می‌رود. پرامپت بعدی: «دکمه حذف را برگردان». حالا فیلتر شکسته. این چرخه ادامه دارد تا پروژه رها شود.

نشانه‌های زودهنگام: فایل‌های تکراری با نام‌های copy یا backup، import های شکسته در console مرورگر، رفتار غیرقابل‌تکرار (امروز کار می‌کند، فردا نه).

راه‌حل اول: version control از روز اول. حتی اگر git بلد نیستید، GitHub Desktop یا VS Code را باز کنید و commit بزنید. این تنها کاری است که بدون دانش فنی، پروژه را نجات می‌دهد.

راه‌حل دوم: پرامپت‌های increment به‌جای rewrite. به‌جای «کل این صفحه را دوباره بساز»، بگویید «فقط تابع X را طوری تغییر بده که Y اتفاق بیفتد، بقیه کد دست نخورد».

بازبینی بدون کدنویسی: چک‌لیست عملی#

  • آیا کلیدهای API در کد hardcode شده‌اند؟ (Ctrl+F بزنید: «sk-»، «pk_»، «secret»)
  • آیا ورودی کاربر اعتبارسنجی (validation) می‌شود؟
  • آیا خطاها به‌صورت raw در UI نمایش داده می‌شوند؟
  • آیا package.json وابستگی‌های تکراری یا منسوخ دارد؟

استفاده از AI برای بازبینی AI (Code Review Loop)#

بعد از تولید کد، یک پرامپت بازبینی بدهید: «این کد را از نظر امنیتی، معماری و حالت‌های مرزی بررسی کن و مشکلات را لیست کن». این روش در پروژه‌های کامیونیتی اسکول بارها کشف آسیب‌پذیری‌هایی را داشته که سازنده اصلاً نمی‌دانست باید بگردد.

بدهی فنی پنهان و هزینه نگهداشت بدون تیم فنی#

بدهی فنی پنهان در وایب کدینگ از آنجا شروع می‌شود که کد تولیدشده توسط LLM بدون بازبینی انسانی، الگوهای آسیب‌پذیری تکراری دارد. در بچ W25 Y Combinator، بخش قابل‌توجهی از استارتاپ‌ها کدبیس عمدتاً AI-generated داشتند؛ یعنی پذیرش اولیه وجود دارد، اما کیفیت نگهداشت همچنان فیلتر می‌شود.

آسیب‌پذیری‌های رایج در کد AI-generated: کلیدهای API در source code، نبود input validation، SQL injection در query های مستقیم، نبود rate limiting. این‌ها در دمو دیده نمی‌شوند چون دمو با داده تمیز اجرا می‌شود. در محیط واقعی، اولین کاربر مخرب فعال‌شان می‌کند.

هزینه پنهان اصلی: هر باگ در کد وایب‌کدشده، چون شما خودتان نمی‌فهمید، پرامپت‌های بیشتری می‌طلبد. پرامپت بیشتر یعنی ریسک بیشتر شکستن چیزهای دیگر. این حلقه معیوب، هزینه نگهداشت را در ماه ششم از استخدام یک توسعه‌دهنده پاره‌وقت بیشتر می‌کند.

Dependency Audit: اولین کاری که بعد از دیپلوی باید بکنید#

ابزارهایی مثل npm audit یا Snyk را روی پروژه اجرا کنید. خروجی‌شان لیست آسیب‌پذیری‌های شناخته‌شده در وابستگی‌هاست. این کار ۵ دقیقه وقت می‌برد و می‌تواند جلوی اولین هک را بگیرد.

چه زمانی بدهی فنی وایب‌کدینگ از بدهی فنی کدنویسی سنتی بیشتر است#

وقتی سه شرط همزمان برقرار باشد: (۱) هیچ توسعه‌دهنده‌ای کد را نخوانده، (۲) تست خودکار وجود ندارد، (۳) معماری از اول ساختارمند نبوده. در این حالت، هر تغییر کوچک به rewrite منجر می‌شود و rewrite به بازنشستن. کدنویسی سنتی هم بدهی دارد، ولی حداقل کسی که نوشته می‌تواند توضیح دهد چرا.

چه زمانی وایب کدینگ انتخاب اشتباه است؟#

وایب کدینگ انتخاب اشتباه است وقتی محصول نهایی با داده حساس، مقیاس بالای همزمان یا عمر طولانی مورد نظر باشد. این روش ابزار تولید است، نه ابزار مهندسی. برای MVP و اعتبارسنجی ایده عالی است، اما در چهار موقعیت مشخص ریسکش غیرقابل‌قبول می‌شود.

  • داده مالی یا پزشکی: امنیت غیرقابل‌مذاکره است. کد AI-generated بدون بازبینی امنیتی انسانی، در این حوزه‌ها قابل‌قبول نیست.
  • مقیاس بالای همزمان: معماری AI-generated برای بهینه‌سازی latency و load balancing طراحی نشده.
  • عمر طولانی پروژه: محصولی که قرار است سال‌ها زنده بماند، نگهداشت بدون تیم فنی پایدار نیست.
  • تحویل به توسعه‌دهنده بعدی: کیفیت کد AI متغیر است. توسعه‌دهنده‌ای که بعداً وارد می‌شود، ممکن است ترجیح دهد از صفر بنویسد.

چه زمانی وایب کدینگ دقیقاً ابزار درست است#

وقتی هدف اعتبارسنجی ایده است، نه ساخت محصول نهایی. وقتی کاربر هدف فقط ۱۰۰ نفر است و می‌خواهید بفهمید آیا اصلاً کسی پول می‌دهد. وقتی می‌خواهید در یک هفته یک demo قابل‌استفاده برای جلسه با سرمایه‌گذار بسازید.

مرز MVP و محصول نهایی: کجا خط را بکشید#

خط را آنجا بکشید که سه چیز همزمان اتفاق بیفتد: کاربر واقعی پول می‌دهد، شکایت‌های باگ شروع می‌شود، و شما نمی‌فهمید کد کجا خراب شده. در آن نقطه، یا توسعه‌دهنده وارد کنید یا بدهی فنی را بپذیرید و رها کنید.

وایب کدینگ کد واقعی تولید می‌کند و برای ساخت MVP قدرتمند است. اما بدون درک مفهومی معماری، بدون version control و بدون بازبینی امنیتی، همان کد در ماه سوم به بدهی‌ای تبدیل می‌شود که هزینه‌اش از استخدام یک توسعه‌دهنده بیشتر است. اگر می‌خواهید این مسیر را با راهنمای عملی و بدون حدس‌زدن طی کنید، دوره آموزش جامع Claude و ابزارهای مشابه در اسکول دقیقاً همین چرخه — از پرامپت ساختاریافته تا بازبینی خروجی — را گام‌به‌گام پوشش می‌دهد.