Vibe Coding واقعاً چیست؟

اصطلاح "vibe coding" در سال‌های 2024-2025 به سرعت پخش شد چون چیزی را نام‌گذاری کرد که بسیاری از توسعه‌دهندگان قبلاً به آرامی انجام می‌دادند: توصیف آنچه می‌خواهند به زبان انگلیسی ساده به یک مدل مثل GPT-4، Claude یا ابزاری مثل Cursor یا GitHub Copilot، و اجازه دادن به آن تا بیشتر کد واقعی را تولید کند. برنامه‌نویس در حلقه باقی می‌ماند، اما حلقه از برنامه‌نویسی سنتی متفاوت به نظر می‌رسد.

تعریف واقعی

Andrej Karpathy این عبارت را ابداع کرد و جریانی کاری را توصیف کرد که در آن شما "به طور کامل به احساسات تسلیم می‌شوید" — شما prompt می‌دهید، پیشنهادات را می‌پذیرید، کد را اجرا می‌کنید، می‌بینید چه چیز خراب می‌شود و دوباره prompt می‌دهید. شما هر خط diff را خط به خط نمی‌خوانید. شما با نتیجه سکان می‌اندازید: آیا برنامه کار می‌کند، آیا تست پاس می‌شود، آیا صفحه به درستی رندر می‌شود. مهارت از نوشتن syntax به توصیف واضح قصد و شناخت زمانی که خروجی غلط است تغییر می‌کند.

این متفاوت از صرف استفاده از autocomplete است. پیشنهادات درون‌خطی سبک Copilot هنوز فرض می‌کنند که شما خود تابع را می‌نویسید و کمک برای تکمیل خطوط دارید. Vibe coding فرض می‌کند که مدل تابع، فایل، گاهی کل ویژگی را می‌نویسد و شما در حال بررسی و تغییر جهت هستید نه نوشتن از ابتدا.

یک جلسه واقعی چگونه به نظر می‌رسد

یک حلقه vibe-coding معمولی با ابزاری مثل Cursor یا Agent mode Replit کم و بیش به این شکل است:

1. Prompt: "یک rate limiter به این Express API اضافه کن، 100 درخواست در 15 دقیقه در هر IP، 429 را با یک body خطای JSON برگردان."
2. مدل middleware/rateLimit.js را ویرایش می‌کند، آن را به app.js وصل می‌کند، شاید express-rate-limit را می‌کشد.
3. شما npm test را اجرا می‌کنید یا endpoint را با curl در یک حلقه ضربه می‌زنید تا بررسی کنید 429 واقعاً فعال شود.
4. چیزی اشتباه است — limiter در هر deploy ریست می‌شود چون در메모ری است. شما این را می‌گویید.
5. مدل یک Redis-backed store را جایگزین می‌کند، ioredis dependency را اضافه می‌کند، فایل docker-compose را به‌روز می‌کند.
6. شما دوباره تست می‌کنید، کار می‌کند، commit می‌کنید.

هیچ خطی از آن middleware دستی تایپ نشد. اما شش یا هفت تصمیم قضاوتی توسط یک انسان انجام شد: آنچه حد می‌تواند باشد، اینکه ذخیره‌سازی در‌حافظه برای production اشتباه بود، اینکه فایل docker-compose نیاز به به‌روزرسانی داشت.

جایی که خوب کار می‌کند

Vibe coding برای کار boilerplate-سنگین قوی است: CRUD endpoints، form validation، test scaffolding، فایل‌های config، glue code بین دو API که قبلاً درک می‌کنید. همچنین برای prototyping خوب است — چرخش یک demo کاری از یک ایده در یک ساعت به جای یک روز، سپس تصمیم‌گیری اینکه آیا ارزش ساختن مناسب دارد.

واقعاً سریع برای devهای solo و تیم‌های کوچک است که ابزارهای internal یا MVPهایی را می‌فروشند جایی که هزینه یک bug پایین است و سرعت تکرار بیش‌تر از purity معماری اهمیت دارد.

جایی که شکست می‌خورد

mode شکستی که مردم به اندازه کافی درمورد آن صحبت نمی‌کنند: مدل‌ها کدی را تولید می‌کنند که اجرا می‌شود اما به طریقی ظریف اشتباه است که تا بعدها ظاهر نمی‌شود. یک SQL query تولید شده ممکن است برای happy path کار کند اما برای injection آسیب‌پذیر باشد چون string concatenation برای مدل خوب به نظر می‌رسید. یک auth check تولید شده ممکن است تست را پاس کند اما یک role check را در یک route پخش کند. اگر شما کد را نمی‌خوانید، این را گرفتار نخواهید — شما فقط می‌بینید که تست‌ها پاس می‌شوند و آن را می‌فروشید.

این در کد حساس به امنیت بیش‌تر از تقریباً هر جای دیگری اهمیت دارد. Simon Willison و دیگران اشاره کرده‌اند که پروژه‌های vibe-coded با داده‌های واقعی کاربر نیاز به همان rigour بررسی دارند مثل هر کد دیگری، احتمالاً بیش‌تر، چون شخصی که آن را "نوشت" ممکن است نتواند توضیح دهد که خط به خط چه کاری می‌کند.

سیستم‌های پیچیده با بسیاری state implicit — concurrency، distributed transactions، هر چیزی با subtle timing bugs — نیز یک fit بد است. مدل‌ها تمایل دارند کد plausible-looking را برای این موارد تولید کنند که به روش‌هایی شکست می‌خورد که debugging آن سخت است دقیقاً چون کسی، انسان یا مدل، به طور کامل edge cases را در ابتدا modeling نکرده است.

مهارتی که واقعاً اهمیت دارد

اگر شما vibe coding می‌کنید، مهارت با ارزش typing speed نیست، specification است. Prompts مبهم، کد مبهم و buggy می‌کنند. Prompts مشخص — با نام‌های دقیق library، انتظارات error-handling و edge cases مطرح شده — خروجی بسیار بهتری می‌دهند. دومین مهارت با ارزش خواندن کد به اندازه‌ای سریع برای گرفتار کردن چه چیز اشتباه است، که به معنای اینکه شما هنوز باید زبان و domain را درک کنید حتی اگر هر کاراکتر را تایپ نمی‌کنید.

با کد تولید شده توسط AI مثل یک pull request از یک junior dev که سریع است اما گاهی بیش از حد اعتماد دارد رفتار کنید: مفید، اغلب صحیح، اما قبل از اینکه production را لمس کند ارزش بررسی واقعی دارد.

می‌خواهید عمیق‌تر برویید در نوشتن کد با ابزارهای AI بدون از دست دادن کنترل کیفیت؟ بخش‌های AI و Python Korra Studio را برای walkthroughهای hands-on بررسی کنید.