«کاملاً با حس‌وحال کد می‌زنم — حرف می‌زنم، نتیجه را می‌بینم، و تقریباً دیگر کد را نمی‌خوانم.» این جمله‌ی کوتاه از کارنجالی پاتارپویان (اوایل ۲۰۲۵) بود که اسمی برای چیزی گذاشت که میلیون‌ها نفر انجامش می‌دادند: پروژه را توصیف می‌کنید، مدل کد را می‌نویسد، اجرا می‌کنید، خطا را همان‌جا به مدل دیکته می‌کنید و صبح، یک محصول کارا دارید. اسمش شد Vibe Coding — و بسته به اینکه چه می‌سازید، می‌تواند بهترین بهره‌وری این دهه باشد یا فاجعه‌ی امنیتی فردا. مرز این دو، موضوع این مطلب است.
Vibe Coding دقیقاً چیست؟
تفاوتش با ابزارهای تکمیل کد (مثل پیشنهاد خط‌به‌خط Copilot) تفاوت سطح انتزاع است: آن‌جا شما می‌نویسید و مدل پیشنهاد می‌دهد؛ این‌جا شما نیت را می‌گویید و عامل کدنویس کل مسیر را اجرا می‌کند — فایل می‌سازد، وابستگی نصب می‌کند، تست اجرا می‌کند، پیام خطا را می‌خواند، خودش اصلاح می‌کند و دوباره می‌آزماید. نقش شما عوض می‌شود: از تایپ‌کننده به معمار و بازبین. کد دیگر محصولِ دست شما نیست؛ محصول قراردادی است که با زبان طبیعی با مدل بسته‌اید.
البته «وایب زدن» دو سطح دارد: نسخه‌ی نابی که خالق اصطلاح توصیف کرد — اعتماد کامل، بدون خواندن کد — و نسخه‌ی مهندسی‌شده که امروز تیم‌های حرفه‌ای با آن کار می‌کنند: توصیف دقیق، بازبینی diff، تست خودکار. اولی برای ساختن سرگرم‌کننده است؛ دومی برای ساختن محصول.
جریان کار درست
Vibe Coding بدون قاعده، سریع به آشوب می‌رسد. این پنج قاعده فرق می‌سازد: اول، قبل از هر چیز خواسته را بنویسید — خروجی دقیق، قیود، پشته‌ی فناوری؛ این همان مهندسی زمینه است که در مهندسی زمینه خواندید، این‌بار با مخاطبِ عامل. دوم، قدم‌های کوچک: به‌جای «کل سیستم را بساز»، گام‌های قابل‌تست؛ هر گام را اجرا کنید و در پرامپت بعدی نتیجه‌ی واقعی را بدهید — نه توصیف مبهمِ «کار نمی‌کند». سوم، تست بخواهید: از عامل بخواهید برای هر قابلیت تست بنویسد؛ تست، حافظه‌ی پروژه است و جلوی شکستن قابلیت قبلی با قابلیت جدید را می‌گیرد.
چهارم، git را جدی بگیرید: بعد از هر گامِ سالم commit کنید تا همیشه راه برگشت باشد — عامل‌ها هم اشتباه می‌کنند و diff قابل‌بازگشت، ارزان‌ترین بیمه‌ی دنیاست. پنجم، خروجی‌های قراردادی: وقتی عامل به API یا دیتابیس وصل می‌شود، شکل داده را با خروجی ساختاریافته قید کنید تا حدس‌زدن مدل جای اعتبارسنجی را نگیرد.
Vibe Coding یعنی بالا رفتن از سطح انتزاع: از سینتکس به نیت. اما نیت شما فقط وقتی به کد درست ترجمه می‌شود که بتوانید نتیجه را بسنجید.
کجا می‌درخشد؟
جایی که بازخورد سریع دارید و ریسک کم است: نمونه‌اولیه و MVP — ایده‌ی ذهنی‌تان تا عصر کارا می‌شود؛ اسکریپت‌های یک‌بارمصرف — تبدیل داده، اتوماسیون شخصی؛ ابزارهای داخلی تیم؛ و ساخت ماکت برای گفتگو با مشتری. برای برنامه‌نویس‌ها یک مزیت پنهان هم دارد: ورود سریع به پشته‌ای که بلد نیستید — با نظارتِ درست، عامل تجربه‌ی آن حوزه را «اجاره می‌دهد».
کجا خطرناک است؟
کدِ تولیدی بدون بازبینی در production — چون مسئولیت همیشه با توسعه‌دهنده است؛ «مدل نوشته» در هیچ دادگاهی دفاع نیست. امنیت: مدل‌ها به‌راحتی اعتبارسنجی ورودی را فراموش می‌کنند، کلید را در کد جا می‌گذارند و پرمیژن‌های باز می‌سازند؛ هر کد Vibe-coded که به اینترنت می‌خورد باید از چک‌لیست امنیتی رد شود — و اگر عامل شما محتوای بیرونی (وب، ایمیل، ریپوی غریبه) را می‌خواند، ریسک تزریق پرامپت را هم در زنجیره دارید. سیستم‌های legacy و دامنه‌های حساس (مالی، سلامت، همزمانی و درست‌کاری) که خطا در آن‌ها گران است — این‌جا Vibe Coding دستیار است، نه جایگزین. و خطر خاموش‌تر: بدهی معماری — ده‌ها قدم مکالمه‌ای بدون طراحی اولیه، کدی می‌سازد که هیچ‌کس — حتی خود عامل — نمی‌فهمدش.
جمع‌بندی
Vibe Coding یک تغییر سطح انتزاع است، نه حذف مهندسی: از نوشتن سینتکس به توصیف نیت و سنجش نتیجه. در نمونه‌اولیه، اسکریپت و ابزار داخلی، سرعتش بی‌رقیب است؛ در محصول حساس، همان قواعد قدیمی حاکم‌اند — بازبینی، تست، امنیت — با این تفاوت که حالا بازبین‌تان باید بلد باشد کدِ «درست به‌نظررسیده» را به چالش بکشد. قاعده‌ی نهایی ساده است: هرچه اثر برگشت‌ناپذیرتر، بازبینی عمیق‌تر. اگر می‌خواهید تفاوت مدل‌ها در کد را ببینید، راهنمای انتخاب مدل چارچوب مقایسه است — و برای شروع با مدل‌های کدنویس روی کار واقعی، با یک حساب اولین نمونه‌اولیه‌تان را همین امروز بسازید.