وایب کدینگ چیست و چرا مسیر ساخت محصول را عوض کرد

پرسش «وایب کدینگ چیست؟» این روزها دو جور جواب می‌گیرد: یا «برنامه‌نویسی تمام شد» یا «اسباب‌بازیِ کسانی که کد بلد نیستند». هر دو غلط‌اند و به یک دلیل: چیزی که عوض شده جایگاه کد نیست، هزینه‌ی آن است.

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

وایب کدینگ از کجا آمد

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

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

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

چیزی که واقعاً عوض شد

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

بخش بزرگی از آن مالیات حذف شده. برای ایده‌های معمولِ وب، نسخه‌ی اولی که واقعاً بالا می‌آید و کار می‌کند، کار یک بعدازظهر است. ولی این جمله را با دقت بخوان: نسخه‌ی اول ارزان شد، نه سیستمی که شش ماه بعد هم بشود نگهش داشت و تغییرش داد.

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

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

چه چیزی جایگزین می‌شود و چه چیزی نمی‌شود

این کارها را دستیار امروز خوب انجام می‌دهد و اصرار بر انجام دستی‌شان فقط اتلاف وقت است:

• کد قالبی و تکراری: فرم، جدول، مسیرها، مدل‌های پایه، راه‌اندازی اولیه‌ی پروژه.
• چسباندن سرویس‌ها به هم: اتصال به یک API، ارسال ایمیل، آپلود فایل، درگاه پرداخت در حالت تست.
• کار در زبان یا فریم‌ورکی که بلد نیستی؛ نحو را او می‌داند، منطق را تو.
• اسکریپت‌های یک‌بارمصرف: تمیز کردن یک فایل CSV، تبدیل فرمت، جابه‌جایی داده بین دو سیستم.
• نوشتن تست برای کدی که از قبل هست، و توضیح دادن کدی که نمی‌فهمی.

و این‌ها، دست‌کم امروز، سهم توست:

• تصمیم اینکه اصلاً چه چیزی ارزش ساختن دارد و «درست کار کردن» دقیقاً یعنی چه.
• شکل داده: هر کاربر چه چیزهایی دارد و رابطه‌ی جدول‌ها چیست. اشتباه در این لایه، ماه‌ها بعد گران تمام می‌شود.
• قضاوت درباره‌ی خروجی. مدل با همان لحن مطمئن حرف می‌زند، چه درست بگوید چه غلط.
• مسئولیت. اگر داده‌ای لو برود یا صورت‌حسابی اشتباه صادر شود، هیچ‌کس سراغ مدل نمی‌رود.

کار	دستیار هوش مصنوعی	سهم تو
نسخه‌ی اول یک قابلیت	سریع و معمولاً قابل‌استفاده	تعریف اینکه «درست» یعنی چه
کد قالبی و اتصال سرویس‌ها	نقطه‌ی قوت اصلی‌اش	انتخاب اینکه کدام سرویس و چرا
طراحی مدل داده	پیشنهاد می‌دهد، گاهی سطحی	تصمیم نهایی و پذیرفتن هزینه‌اش
دیباگ یک خطای مشخص	خوب، اگر متن کامل خطا را بدهی	بازتولید خطا و تأیید اینکه واقعاً حل شده
امنیت، پرداخت، داده‌ی کاربر	بدون بازبینی، پرریسک	مسئولیت کامل

حلقه‌ای که در عمل جواب می‌دهد

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

1. کوچک بخواه. «یک شبکه‌ی اجتماعی بساز» خروجی بی‌ربط می‌دهد؛ «فرم ثبت‌نام با ایمیل و رمز، فقط در این پوشه» خروجیِ قابل‌بررسی.
2. شرط قبولی را از اول بگو. تا نگویی نتیجه چه وقت درست است، مدل خودش یک تعریف می‌سازد و معمولاً دست‌ودل‌بازانه‌ترین تعریف را انتخاب می‌کند.
3. بعد از هر قدمِ کارکننده کامیت کن. گیت اینجا دکمه‌ی بازگشت توست؛ بدون آن، هر تلاش ناموفق تو را یک قدم به وضعیتی نزدیک‌تر می‌کند که دیگر نمی‌دانی چه چیزی سالم بود.
4. دیف را بخوان. لازم نیست تک‌تک خط‌ها را بفهمی، ولی باید بدانی چه فایل‌هایی دست خورده و چرا.
5. وقتی دو بار پشت‌سرهم حل نشد، برگرد عقب. دور سوم و چهارم معمولاً کد را بدتر می‌کند، نه بهتر. برگرد به آخرین حالت سالم و مسئله را جور دیگری توصیف کن.

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

یک درخواست خوب، بیشتر شبیه برگه‌ی پذیرش است تا آرزو:

هدف: فرم ثبت‌نام با ایمیل و رمز.
محدوده: فقط app/auth/ — بقیه‌ی فایل‌ها دست نخورند.
قبول وقتی: کاربر جدید ساخته شود، ایمیل تکراری خطای 409 بدهد،
و tests/auth/signup.test.ts سبز باشد.

و کل تور نجاتت همین دو خط است:

git switch -c feature/signup
git add -p && git commit -m "signup: reject duplicate email"

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

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

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

جاهایی که باید عمداً سرعت را کم کنی:

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

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

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

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

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

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

اگر می‌خواهی امروز شروع کنی

ابزارها سریع عوض می‌شوند و هر توصیه‌ی قطعی درباره‌ی «بهترین ابزار» چند ماه بعد کهنه است؛ پس انتخاب را ساده بگیر. برای کار در ترمینال و روی یک پروژه‌ی واقعی، Claude Code و Codex CLI؛ برای ویرایشگر، Cursor و GitHub Copilot؛ و برای وقتی که فقط می‌خواهی شکل یک رابط کاربری را ببینی، ابزارهای مرورگری مثل Lovable و v0 و Bolt. قیمت‌ها و محدودیت‌ها مدام تغییر می‌کنند، پس همیشه صفحه‌ی خود سرویس را نگاه کن.

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

سه کاری که در هفته‌ی اول بیشترین بازده را دارند:

1. یک مسئله‌ی واقعی از زندگی خودت انتخاب کن، نه یک نمونه‌ی آموزشی. انگیزه‌ی دیباگ کردن فقط وقتی می‌آید که نتیجه به دردت بخورد.
2. حداقلِ گیت را یاد بگیر: شاخه، کامیت، برگشت. همین سه دستور بیشترین ریسک را از سرت کم می‌کند.
3. یک فایل قوانین کنار پروژه بگذار — بسته به ابزار، CLAUDE.md یا AGENTS.md — و در آن بنویس پروژه چیست، چه چیزی را نباید دست بزند، و دستور اجرای تست‌ها چیست. این فایل، تکرارِ خودت را حذف می‌کند.

چیزی که این روزها هایپ می‌شود سرعت است؛ چیزی که برنده را مشخص می‌کند داوری است. ابزار نسخه‌ی اول را برایت می‌سازد، اما هنوز این توییی که باید بگوید کدام نسخه ارزش نگه‌داشتن دارد. اگر می‌خواهی این عضله را تمرین بدهی، نوشته‌های دیگر وبلاگ سراغ همین جزئیات عملی می‌روند.

محمدرضا حسینی

مهندس نرم‌افزار و مدرس وایب کدینگ. بیش از ۱۰ سال تجربه ساخت محصولات وب، و سه سال تمرکز روی ساخت محصول با ابزارهای هوش مصنوعی. تا امروز بیش از ۴٬۰۰۰ نفر در دوره‌هایش شرکت کرده‌اند.