Vibe Coding چیست؟ چگونه با کمک هوش مصنوعی نرم‌افزار بسازیم؟

ساخت نرم‌افزار مدت‌ها یعنی نوشتن و خواندن کد بود. حالا بخشی از همان کار با توصیف نیت به یک مدل زبانی بزرگ (LLM) انجام می‌شود و خروجی گاهی در چند دقیقه اجرا می‌شود. این سرعت واقعی است؛ و همین سرعت تصمیم را سخت می‌کند.

Vibe Coding نام یک سبک خاص است: سپردن تولید کد به هوش مصنوعی (AI)، پیش‌بردن کار با دستور متنی (prompt) و بازخورد اجرا، و در شکل خالصش کم‌توجهی به خودِ متن برنامه. این مقاله اصطلاح را با منابع قابل‌ردیابی تعریف می‌کند و کمک می‌کند بفهمید چه زمانی ابزار مفیدی است و چه زمانی بدهی فنی یا ریسک می‌سازد.

پاسخ کوتاه

Vibe Coding یعنی نرم‌افزار را با گفت‌وگو با LLM بسازید: بگویید چه می‌خواهید، کد را اجرا کنید، خطا را برگردانید، دوباره بخواهید. در تعریف اولیه، انسان «کد را فراموش می‌کند»، diff را نمی‌خواند و با دیدن نتیجه تصمیم می‌گیرد.

برای پیش‌نمونه (prototype)، ابزار شخصی و آزمایش ایده می‌تواند بسیار سریع باشد. برای سامانهٔ تولیدی با کاربر واقعی، دادهٔ حساس، پرداخت یا عمر طولانی کافی نیست. اگر بازبینی، تست و فهم خروجی در کار باشد، دیگر Vibe Coding به معنای اولیه نیست؛ مهندسی است که ابزارش عوض شده.

اگر LLM همهٔ خط‌ها را نوشته باشد، اما آن‌ها را بازبینی، تست و طوری فهمیده باشید که بتوانید برای دیگری توضیح دهید، از نظر من Vibe Coding نیست؛ توسعهٔ نرم‌افزار است.

Vibe Coding دقیقاً یعنی چه؟

تعریف مهم است، چون اصطلاح خیلی زود از نیت اولیه‌اش خارج شد. بسیاری هر کدنویسی با کمک AI را Vibe Coding می‌نامند. این همه‌گیری معنا دو کار متفاوت را یکی می‌کند.

در تعریف سخت‌گیرانه سه چیز جمع می‌شود. نیت به زبان طبیعی گفته می‌شود، نه به زبان برنامه‌نویسی. مدل کد را تولید و اغلب در چند پرونده اصلاح می‌کند. انسان بیشتر به رفتار برنامه نگاه می‌کند تا به ساختار؛ گاهی Accept All می‌زند و diff را نمی‌خواند.

مارتین فاولر (Martin Fowler) در ۲۰۲۶ همین خط را کشید: Vibe Coding ساختن برنامه با prompt است بدون نگاه به کد. اگر مدل تقریباً همه را بنویسد اما شما ساختار را ببینید و مالک کیفیت بمانید، او این را برنامه‌نویسی عاملی (Agentic Programming) می‌نامد. سیمون ویلیسون (Simon Willison) ماه‌ها زودتر نوشته بود «فراموش کردن وجود کد» با «LLM به‌عنوان دستیار تایپ» یکی نیست.

تکمیل خودکار یک خط، یا پرسیدن «این تابع چه می‌کند؟»، Vibe Coding نیست. پلتفرم بدون‌کد (no-code) هم معادل نیست؛ آن‌جا بلوک‌ها محدودند. این‌جا مدل کد آزاد می‌نویسد. قدرت و خطر از همین آزادی است.

اصطلاح از کجا آمد؟

در ۲ فوریه ۲۰۲۵، آندری کارپاتی (Andrej Karpathy) — پژوهشگر AI، از هم‌بنیان‌گذاران OpenAI و مدیر پیشین AI در Tesla — در X نوشت سبک تازه‌ای را Vibe Coding می‌نامد. متن پست صریح است و بهتر است به اصل نزدیک خوانده شود، نه به شعارهای بعدی.

There's a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. … I Accept All always, I don't read the diffs anymore. … It's not too bad for throwaway weekend projects. … I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

او از Cursor Composer با مدل Sonnet حرف زد. خطا را بدون توضیح به مدل می‌داد و محدوده را خودش گذاشت: پروژهٔ آخرهفتهٔ دورریختنی، نه جایگزینی مهندسی.

مارس ۲۰۲۵ Merriam-Webster اصطلاح را در slang آورد. نوامبر ۲۰۲۵ Collins آن را Word of the Year کرد. توجه واژه‌نامه دلیل درستی فنی نیست. ریشهٔ فکری قدیمی‌تر است: ژانویه ۲۰۲۳ کارپاتی نوشته بود داغ‌ترین زبان برنامه‌نویسی جدید انگلیسی است.

اختلاف نظر از همان ماه‌های اول بود. اندرو انگ (Andrew Ng) گفت نام گمراه‌کننده است؛ کار جدی با ابزار AI «رفتن با حس» نیست. فاولر بعداً نوشت محبوبیت واژه باعث شده خیلی‌ها آن را معادل برنامه‌نویسی عاملی به کار ببرند. این مقاله تعریف باریک را نگه می‌دارد تا بشود گفت چه چیزی خطرناک است.

این گردش‌کار با توسعهٔ سنتی چه فرقی دارد؟

توسعهٔ سنتی — حتی چابک — معمولاً از مسئله به طراحی، تغییر کوچک، بازبینی و تست می‌رود. انسان متن را می‌نویسد یا خط‌به‌خط می‌خواند. تاریخچه در Git است، قرارداد در PR دیده می‌شود، و CI/CD جلوی شکستن مسیر اصلی را می‌گیرد.

در Vibe Coding خالص نقطهٔ شروع نیت است نه طراحی. حلقهٔ بازخورد، اجرا و ظاهر است نه خواندن diff. معماری به‌تدریج و اغلب تصادفی شکل می‌گیرد. دانش ممکن است فقط در چت بماند؛ چت با Git یکی نیست و با بستن نشست از بین می‌رود.

تیم‌های واقعی وسط جدول‌اند: مدل می‌نویسد، انسان معماری را نگه می‌دارد. مشکل وقتی است که ستون دوم را برای کار ستون اول به کار ببرید.

دستیارهای کدنویسی AI چه می‌کنند؟

ابزارها یکدست نیستند. GitHub Copilot پیشنهاد را وسط تایپ می‌گذارد. چت داخل ویرایشگر — Copilot Chat، Cursor، Claude Code، Codex — چند پرونده را با هم عوض می‌کند. عامل (agent) می‌تواند طرح بریزد، ترمینال اجرا کند، تست بدود و PR باز کند. سازنده‌های مرورگرمحور مثل Replit Agent، Bolt یا Lovable از توصیف به اسکلت برنامه نزدیک‌تر می‌شوند.

در ۲۰۲۵ و ۲۰۲۶ این‌ها در boilerplate، CRUD معمولی، پیش‌نویس تست، توضیح کد ناآشنا و اصلاح خطای واضح نسبتاً خوب‌اند. حدها هم واقعی است: تابع ناموجود، وابستگی منسوخ، حدس قرارداد بین سرویس‌ها، و امنیت مگر وقتی صریح بخواهید — آن هم تضمین نیست.

گزارش Veracode در ۲۰۲۵ روی بیش از صد LLM نشان داد نحوِ درست خیلی بهتر شده، اما امنیت روی معیار آن‌ها عمدتاً تخت مانده؛ در مجموعهٔ اولیه حدود ۴۵٪ موارد یک آسیب‌پذیری قابل‌کشف از جنس OWASP وارد کد می‌شد. به‌روزرسانی اکتبر گفت بعضی مدل‌های reasoning بهتر شده‌اند، بقیه نه. «مدل جدیدتر برابر کد امن‌تر» قانون نیست.

روی بهره‌وری اجماع نیست. کارآزمایی METR روی ۱۶ توسعه‌دهندهٔ باتجربه در مخزن‌های متن‌باز بالغ (اوایل ۲۰۲۵) نشان داد اجازهٔ AI زمان را حدود ۱۹٪ زیاد کرد؛ در حالی که افراد هنوز فکر می‌کردند سریع‌تر شده‌اند. یک مطالعه در یک بافت است، نه قانون جهانی. خلاف شهود دموهای کوتاه است.

Prompt: واحد کار جدید

کیفیت خروجی به prompt وابسته است؛ اما prompt جادو نیست. اگر زمینه ندهید، مدل راه‌حل عمومی می‌نویسد که به مخزن شما نمی‌خورد. «یک داشبورد بساز» ضعیف است. prompt بهتر زبان، ورودی و خروجی، آن‌چه نباید عوض شود، و تعریف تمام‌شدن را دارد.

• رفتار قابل مشاهده بنویسید: «فرم بدون ایمیل معتبر ارسال نشود» بهتر از «فرم خوب باشد» است.
• زمینه بدهید: پرونده‌ها، الگوی موجود، محدودیت نسخه.
• قید منفی: این جدول را عوض نکن؛ secret را hard-code نکن.
• بعد از هر تغییر یک کار بخواهید. مدل دوست دارد هم‌زمان refactor کند.
• خطا را خام برگردانید و بگویید انتظار چه بوده و کدام تست شکسته است.

کارپاتی می‌گفت خطا را بدون توضیح paste می‌کند. برای prototype شخصی قابل دفاع است. برای کدی که همکار باید تغییرش دهد، خطا باید به یک ادعا تبدیل شود.

توسعهٔ تکراری و نمونه‌سازی سریع

قدرت اصلی حلقهٔ کوتاه است. به‌جای دو روز اسکلت، در یک نشست صفحهٔ قابل‌کلیک دارید. بنیان‌گذار جریان سفارش را نشان می‌دهد. مهندس spike می‌زند: این API به درد می‌خورد یا نه؟

نمونه‌سازی سریع (rapid prototyping) همان جایی است که Vibe Coding بیشترین ارزش را دارد. هدف prototype یادگیری است نه دارایی ماندگار. ویلیسون هشدار داد prototype خوب معمولاً نامزد خطرناک تولید می‌شود. از اول برچسب بزنید: شاخهٔ throwaway، عنوان spike، و در پایان نشست تصمیم صریح — دور ریختن، نوشتن از نو، یا ورود با بازبینی.

نقش Developer و نقش AI

مدل تولید می‌کند. انسان تصمیم می‌گیرد. اگر برنامه دادهٔ مشتری را نشت دهد، «مدل این‌طور نوشت» در حادثه کافی نیست. نقش AI پیشنهاد پیاده‌سازی، کار تکراری، پیش‌نویس تست و توضیح کد ناآشناست. نقش انسان صورت‌مسئله، معماری، مرز امنیت، خواندن تغییر، و گفتن نه است.

شرکای Y Combinator در مارس ۲۰۲۵ گفتند حدود یک‌چهارم دورهٔ زمستان ۲۰۲۵ ادعا کرده‌اند ۹۵٪ کد را AI تولید کرده است. همان‌جا تأکید شد بنیان‌گذاران فنی بوده‌اند. درصد تولید، درصد قضاوت نیست.

برای تازه‌کار مانع ورود را کم می‌کند. اگر فقط Accept All کنید، مانع به‌شکل vibe debug برمی‌گردد: برنامه می‌شکند و شما ابزار فهمش را ندارید.

یک گردش‌کار نمونه

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

1. نیت و غیرهدف را بنویسید. غیرهدف: پرداخت، حساب مشتری، دسترسی عمومی. دادهٔ نمونه، نه فروش واقعی.
2. قید در prompt اول: اجرا روی localhost، بدون ارسال داده به بیرون، بدون رمز در کد.
3. اول طرح بخواهید: پرونده‌ها، جریان داده، نحوهٔ تست. طرح را قبل از تولید گسترده بپذیرید یا رد کنید.
4. یک رفتار را تمام کنید، بعد بعدی. هر بار Git با commit کوچک و پیام انسانی.
5. از مدل تست بخواهید؛ خودتان تست را بخوانید. تستی که توهم مدل را تکرار کند تور ایمنی نیست.
6. قبل از نفر دوم، diff را مثل PR بخوانید. secret، شبکه، مسیر فایل، مجوز.
7. اگر قرار است بماند: CI/CD حداقلی و ممنوعیت Accept All بدون بازبینی.

تست

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

بازبینی و PR

بازبینی در این سبک مهم‌تر می‌شود چون حجم تولید بالا می‌رود. قانون ویلیسون برای کار تولیدی: کدی را commit نکنید که نتوانید توضیح دهید چه می‌کند. حتی تنها، فردا را به‌عنوان مرورگر فرض کنید.

امنیت

LLM سطح حمله را بزرگ می‌کند: prompt، کد، ابزارها، و داده‌ای که به مدل می‌دهید. الگوهای تکراری: credential در منبع، ورودی بدون اعتبارسنجی، پرس‌وجوی چسبانده‌شده. در ژوئیه ۲۰۲۵ جیسون لمکین (Jason Lemkin) روایت کرد عامل Replit با وجود دستور توقف، پایگاه production را پاک کرده است. زبان طبیعی جایگزین جداسازی محیط نمی‌شود.

نگهداری‌پذیری

کدی که کسی نفهمد هزینهٔ تغییرش بالا می‌رود. فاولر می‌نویسد تا این‌جا نرم‌افزار خوش‌ساختار برای LLM هم زندگی را آسان‌تر کرده است. CodeRabbit در دسامبر ۲۰۲۵ روی ۴۷۰ درخواست ادغام متن‌باز گزارش داد کد هم‌نویس‌شده با AI حدود ۱.۷ برابر «مسئلهٔ عمده» بیشتر داشته. مطالعهٔ کامل صنعت نیست؛ با تجربهٔ تحویل «کد درهم‌ریخته» هم‌خوان است.

مثال واقعی: وقتی اجرا شدن فریب می‌دهد

کوین روس (Kevin Roose) در فوریه ۲۰۲۵ در نیویورک‌تایمز نوشت برنامه‌نویس نیست اما با AI ابزار شخصی ساخته؛ software for one. در یک مورد کد برای سایت تجارت الکترونیک نظر جعلی ساخت. شکست «کامپایل نشدن» نبود: برنامه کار می‌کرد و کار غلط می‌کرد.

مرز «اگر مدل ببافد کد اجرا نمی‌شود» کافی نیست. سؤال درست: اگر رفتار غلط باشد چه کسی می‌فهمد و چه آسیب می‌بیند؟

مزایا؛ بدون اغراق

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

محدودیت‌ها و ریسک‌ها

نفهمیدن کد اشکال‌زدایی را گران می‌کند. تغییرات تصادفی علائم را پنهان می‌کنند. غیرقطعی بودن یعنی همان prompt فردا کد متفاوت بدهد. امنیت، حریم داده و هزینهٔ API بدون سقف سه ریسک عملی‌اند.

در سامانهٔ موجود، سود سرعت ممکن است منفی شود؛ METR یک دادهٔ جدی است نه حرف آخر. کار مهندس عمدتاً تحول سیستم موجود است. ویلیسون: رساندن Vibe Coding به codebase تولیدی آشکارا پرریسک است.

اشتباهات رایج

• هر استفاده از AI را Vibe Coding نامیدن.
• Accept All روی چند پرونده بدون جست‌وجوی secret و شبکه.
• یکی دانستن «اجرا شد» با «درست است».
• فرستادن prototype به production چون دمو خوب بوده.
• دادن دادهٔ واقعی مشتری به مدل یا برنامهٔ آزمایشی.
• یک prompt غول‌آسا به‌جای حلقهٔ طرح، ساخت، تست.
• نبود Git، یا یک commit هزارخطی با پیام wip.
• خواستن معماری ماندگار از مدل بدون فهم معامله‌ها.
• رها کردن مبانی به این بهانه که دیگر لازم نیست کد بدانم.

چه کسانی سود می‌برند؟

مهندس باتجربه برای spike و پیش‌نویس تکراری، به شرط بازبینی. مدیر محصول و بنیان‌گذار برای دمو، نه برای دور زدن تیم در کار حساس. فرد غیرفنی برای ابزار شخصی روی دادهٔ غیرحساس. دانشجو اگر مدل را معلم بگیرد نه جایگزین فکر. تیم نگهداری سیستم قدیمی ممکن است کمتر سود ببرد.

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

سه سؤال: اگر غلط کار کند آسیب چیست؟ چه کسانی استفاده می‌کنند؟ چه مدت باید زنده بماند؟ هرچه پاسخ جدی‌تر، باید از Vibe Coding خالص دورتر شوید.

ستون راست یعنی تحریم AI نیست. یعنی مدل می‌تواند پیش‌نویس بدهد، اما انسان باید طراحی، تهدید و پذیرش را مالک باشد.

نکته‌های کسب‌وکار

هزینهٔ نسخهٔ اول پایین آمده؛ هزینهٔ مالکیت نه لزوماً. دموی دوساعته انتظار را جابه‌جا می‌کند، در حالی که امنیت، پشتیبان و پشتیبانی هنوز هفته‌ها وقت می‌خواهد. عدد YC نمونهٔ صنعت نیست. پرسش درست: وقتی سرویس در ساعت شلوغی بشکند چه کسی علت را پیدا می‌کند؟

سه سیاست کوچک از شعار AI-first مفیدتر است. prototype برچسب دارد و بدون بازبینی به production نمی‌رود. راز و دادهٔ مشتری وارد ابزار شخصی نمی‌شود مگر قرارداد روشن باشد. زمان بازبینی و تست در برآورد می‌ماند؛ وگرنه سرعت دروغین به‌صورت حادثه برمی‌گردد.

جمع‌بندی

Vibe Coding تکنیک است، نه آیندهٔ اجتناب‌ناپذیر و نه شوخی بی‌مصرف. کارپاتی آن را برای پروژهٔ آخرهفته توصیف کرد: دیدن، گفتن، اجرا، paste. همان تعریف هنوز بهترین راهنمای استفاده است.

ابزارهای ۲۰۲۶ قوی‌تر از فوریهٔ ۲۰۲۵اند. این قدرت، نخواندن diff را وسوسه‌انگیزتر می‌کند. برای یادگیری و prototype حلقه را باز بگذارید. برای چیزی که به دیگران، به پول یا به اعتبار وصل است، AI را پیشنهاددهنده نگه دارید. مالک کسی است که می‌تواند بگوید برنامه چه می‌کند — و چه کارهایی را عمداً نمی‌کند.

پرسش‌های متداول

آیا هر بار که از Copilot یا Cursor استفاده می‌کنم Vibe Coding می‌کنم؟

نه. اگر پیشنهاد را می‌خوانید، تست می‌کنید و می‌فهمید چه وارد مخزن می‌شود، کدنویسی یاری‌شده با AI است. Vibe Coding وقتی است که وجود کد را عملاً کنار می‌گذارید.

برنامه‌نویس نیستم؛ می‌توانم محصول واقعی بسازم؟

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

چرا بعضی استارتاپ‌ها می‌گویند تقریباً همهٔ کد را AI نوشته؟

تولید متن ارزان شده است. در روایت YC از W25 افراد فنی بودند. درصد خط با درصد فهم یا آمادگی مقیاس یکی نیست.

چطور بفهمم مدل اشتباهِ مطمئن می‌گوید؟

اجرا، تست، خواندن diff. اگر تابع ناشناخته import شده یا تست فقط مسیر شاد را می‌بیند، فرض را بر اشتباه بگذارید.

اگر وقت بازبینی کامل ندارم حداقل چیست؟

Git با commit کوچک، جست‌وجوی secret و شبکه در diff، و یک تست برای خطرناک‌ترین رفتار. اگر همین را نمی‌رسید، کار را روی دادهٔ واقعی نبرید.

منابع و مراجع

• Andrej Karpathy، پست اصلی Vibe Coding در X (۲ فوریه ۲۰۲۵): https://x.com/karpathy/status/1886192184808149383
• نقل کامل همان پست، Simon Willison (۶ فوریه ۲۰۲۵): https://simonwillison.net/2025/Feb/6/andrej-karpathy/
• Simon Willison — Not all AI-assisted programming is vibe coding (۱۹ مارس ۲۰۲۵): https://simonwillison.net/2025/Mar/19/vibe-coding/
• Martin Fowler — Vibe Coding (۲۱ مه ۲۰۲۶): https://martinfowler.com/bliki/VibeCoding.html
• MIT Technology Review — What is vibe coding, exactly? (۱۶ آوریل ۲۰۲۵): https://www.technologyreview.com/2025/04/16/1115135/what-is-vibe-coding-exactly/
• Ars Technica — Will the future of software development run on vibes? (۵ مارس ۲۰۲۵): https://arstechnica.com/ai/2025/03/is-vibe-coding-with-ai-gnarly-or-reckless-maybe-some-of-both/
• Kevin Roose، New York Times (۲۷ فوریه ۲۰۲۵): https://www.nytimes.com/2025/02/27/technology/personaltech/vibecoding-ai-software-programming.html
• Merriam-Webster — vibe coding: https://www.merriam-webster.com/slang/vibe-coding
• BBC — Collins Word of the Year 2025: https://www.bbc.co.uk/news/articles/cpd2y053nleo
• GitHub — What Is Vibe Coding? (۱ ژوئیه ۲۰۲۶): https://github.com/resources/articles/what-is-vibe-coding
• TechCrunch — YC W25 و کد تولیدشده با AI (۶ مارس ۲۰۲۵): https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/
• METR — Early-2025 AI and experienced OSS developers (۱۰ ژوئیه ۲۰۲۵): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• Veracode — GenAI Code Security، اکتبر ۲۰۲۵: https://www.veracode.com/blog/ai-code-security-october-update/
• The Register — حادثهٔ پایگاه داده در Replit (۲۱ ژوئیه ۲۰۲۵): https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/
• CodeRabbit — AI vs Human Code Generation (۱۷ دسامبر ۲۰۲۵): https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
• Business Insider — نقد Andrew Ng (۴ ژوئن ۲۰۲۵): https://www.businessinsider.com/andrew-ng-says-vibe-coding-is-a-bad-name-for-a-very-real-and-exhausting-job-2025-6