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

پاسخ کوتاه: وایب کدینگ یعنی ساختن نرم‌افزار با توصیف چیزی که می‌خواهید به زبان ساده و سپردن نوشتن، اجرا و رفع اشکال کد به یک عامل هوش مصنوعی؛ شما با نتیجه هدایت می‌کنید، نه با تایپ. این اصطلاح از Andrej Karpathy (اوایل ۲۰۲۵) آمده که از «تسلیم کامل شدن به حس‌وحال» و تقریباً نگاه نکردن به کد گفت. برای یک نمونه دورریختنی اشکالی ندارد. برای هر چیز واقعی، نسخه‌ای جواب می‌دهد که سرعت را نگه می‌دارد و یک مهندس را مسئول بخش‌هایی می‌کند که هوش مصنوعی در آن‌ها ضعیف است: معماری، قواعد ثابت، تست، امنیت و استقرار.

یک مثال واقعی: سایت یک کسب‌وکار کوچک و اینکه زمان واقعاً کجا می‌رود

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

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

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

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

وایب کدینگ در چه چیزی خوب است

• کارهای تکراری در مقیاس. صفحه‌های CRUD، فرم‌ها، DTOها، نگاشت‌ها، migrationها، پیکربندی.
• رسیدن از صفر به اجرا. راه‌اندازی پروژه، اتصال اجزا، اولین استقرار؛ کارهایی که بلدید ولی ساعت‌ها وقت می‌گیرند.
• خواندن خطا و تکرار. عاملی که بتواند dotnet build و dotnet test اجرا کند، بیشتر خطاهای کامپایل و تست را خودش رفع می‌کند.
• کاوش در کد ناآشنا. «کال‌بک پرداخت کجا مدیریت می‌شود و چه چیزی را بررسی می‌کند؟» یک پرامپت عالی است.

کجا می‌شکند

• قواعدی که نمی‌بیند. «پول هیچ‌وقت double نیست»، «جمع یک انتقال همیشه صفر است»، «مقاله‌های seed پیش‌نویس‌اند». تا وقتی نوشته و تست نشده باشند، هوش مصنوعی با خیال راحت می‌شکندشان.
• باورپذیر ولی غلط. کدی که کامپایل می‌شود، خوانا است و به‌شکلی ظریف نادرست است: یک خطای یکی‌کم در صفحه‌بندی، یک await جاافتاده، یک race در به‌روزرسانی موجودی.
• پیش‌فرض‌های امنیتی. نبود authorization روی یک endpoint، ورودی کاربر داخل یک رشته SQL خام، secret در فایل پیکربندی.
• گسترش بی‌رویه محدوده. یک چیز می‌خواهید، پنج refactor تحویل می‌گیرید. diffهای بزرگ همان‌جایی‌اند که بازبینی از کار می‌افتد.

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

1. مشخصات را بنویسید. یک CLAUDE.md (یا مشابه) با stack، قواعدی که هرگز نباید بشکنند و دستورهای build و تست. عامل آن را در هر جلسه می‌خواند.
2. قواعد ثابت را به تست تبدیل کنید. قاعده‌ای که در تست است اجرا می‌شود؛ قاعده‌ای که در پرامپت است یک پیشنهاد است.
3. گام‌های کوچک، diffهای کوچک. در هر تغییر یک قابلیت یا یک اصلاح، بازبینی‌شده قبل از شروع بعدی.
4. هر diff را بخوانید. بازبین شمایید. اگر از یک همکار تأییدش نمی‌کردید، از هوش مصنوعی هم تأیید نکنید.
5. استقرار واقعی، زود. اولین صفحه را مستقر کنید، نه آخرین را. غافلگیری‌های استقرار در هفته اول ارزان‌ترند.

کد قابل اجرا: یک گاردریل معماری

تستی مثل این، «پول هرگز نباید اعشاری شناور باشد» را از یک امید به یک شکست build تبدیل می‌کند؛ هر کسی (یا هر چیزی) که ویژگی بعدی را بنویسد:

using System.Reflection;

namespace Shop.Tests;

public sealed class Order
{
    public long TotalRials { get; set; }
    public decimal DiscountRate { get; set; }
}

public class ArchitectureGuardrails
{
    private static readonly string[] MoneyWords = ["Amount", "Price", "Balance", "Total", "Fee"];

    /// <summary>
    /// AI assistants reach for double when they see a number with a decimal point.
    /// This test fails the build the moment money becomes floating-point anywhere in the domain.
    /// </summary>
    [Fact]
    public void Money_is_never_a_floating_point_number()
    {
        var offenders = typeof(Order).Assembly.GetTypes()
            .SelectMany(t => t.GetProperties(BindingFlags.Public | BindingFlags.Instance))
            .Where(p => p.PropertyType == typeof(double) || p.PropertyType == typeof(float))
            .Where(p => MoneyWords.Any(word => p.Name.Contains(word, StringComparison.Ordinal)))
            .Select(p => $"{p.DeclaringType!.Name}.{p.Name}")
            .ToList();

        Assert.Empty(offenders);
    }
}

در پروژه واقعی، typeof(Order).Assembly را به اسمبلی دامنه خودتان اشاره دهید. همین الگو برای قواعد دیگر هم کار می‌کند: هیچ controllerی بدون [Authorize]، هیچ DateTime.Now در کد دامنه، هیچ عبارت ممنوعی در محتوا. مجموعه تست همین سایت با یکی از این‌ها جلوی ادعاهایی را می‌گیرد که هرگز نباید در مقاله‌هایش بیایند.

مزایا و معایب

مزایا

• هفته‌ها کار تکراری به چند روز تبدیل می‌شود؛ پروژه‌های کوچک مقرون‌به‌صرفه می‌شوند.
• وقت مهندس به تصمیم‌ها، بازبینی‌ها و ۱۰ درصد سخت منتقل می‌شود.
• وقتی حلقه بازخورد (build، تست، اجرا) فشرده باشد، خطاهای عامل دیده و رفع می‌شوند.

معایب

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

نسخه مهندس ارشد

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

---

یک MVP می‌خواهید که این‌طور ساخته شود و یک مهندس ارشد هر خطش را بازبینی کند؟ ببینید چطور می‌توانم کمک کنم.