اگر امروز برای ابزارهای کدنویسی هوش مصنوعی پول میدهید، احتمالاً ۸۰٪ بودجه توکنهای ماهانه شما صرف خروجیهای غلط یا توهمات مدل میشود. این وضعیت یعنی شما به جای خرید یک ابزار بهرهوری، در واقع هزینه یک «بازی حدسزدنی» گرانقیمت را میپردازید. پدیده «Vibe Coding» یا برنامهنویسی بر اساس حس، ابزارهای قدرتمند را به ماشینهای حدسزدنی تبدیل میکند که در آن، کاربر به جای بهرهبردار، به محصولی برای شرکتهای اشتراکی هوش مصنوعی تبدیل میشود.
این اتفاق زمانی رخ میدهد که برنامهنویسان به جای تعیین محدودیتهای فنی، امیدوارند مدل «خودش بفهمد» منظور آنها چیست. این رویکرد که Vibe Coding نامیده شده، در واقع نوعی تله است؛ شبیه به این است که به یک آشپز بگویید «غذایی خوشمزه درست کن» و بعد از هر بشقاب غذا که میآورد، شکایت کنید که «حسش» درست نیست و او را مجبور کنید دوباره از اول بپزد. این تغییر رفتار با حرکت عاملهای کدنویسی به سمت مدلهای قیمتگذاری مبتنی بر اعتبار (Credit-based) همزمان شده است. برای بسیاری از توسعهدهندگان، انتقال از رابطهای ساده چت به محیطهای یکپارچه (IDE)، عادتی خطرناک ایجاد کرده است: امید به اینکه هوش مصنوعی بدون محدودیتهای فنی صریح، قصد کاربر را درک کند. این روند بازتابی از یک جریان گستردهتر در صنعت است که در آن سهولت ورود، باعث کاهش مالکیت بنیادین بر معماری نرمافزار شده است. در همین راستا، تلاشهایی برای مقابله با این رویکرد سطحی آغاز شده است که ابزارهایی برای اثبات درک برنامهنویس از منطق هوش مصنوعی طراحی شدهاند تا پایان عصر Vibe Coding را تسریع کنند.
شکاف بستر متنی (Context Gap)
طبق گزارش یک توسعهدهنده با ۵ سال تجربه، این شکاف بستر متنی در پروژههای واقعی منجر به نتایج فاجعهباری میشود. او مورد مطالعاتی درباره ساخت یک صفحه فرود (Landing Page) مدرن برای یک سرویس SaaS را به اشتراک گذاشت. هدف او این بود که از «ظاهر کلیشهای قالبها» فاصله بگیرد و چیزی واقعاً مدرن بسازد. او برای تولید پرامپتها از Claude استفاده کرد و سپس آنها را به عاملهایی مثل Cursor و Antigravity داد، اما نتایج اولیه بسیار متوسط بود.
گردش کار اولیه این توسعهدهنده شامل بررسی سایتهای Aceternity UI و 21st Dev برای الهام گرفتن بود. در حالی که برخی از کامپوننتها پشت پرداختهای walled بودند و موارد رایگان نیز آنقدر خاص نبودند که بتوان بر اساس آنها یک برند ساخت، او یک کامپوننت «موکاپ موبایل شناور» را در Aceternity UI پیدا کرد. مدل Claude توانست آن بخش واحد را به خوبی بسازد، اما بقیه صفحه ایستا و بدون تغییر باقی ماند.
به مدت دو ساعت، هوش مصنوعی نتوانست «حس» طراحی مدرن را درک کند. حتی زمانی که تصاویر به مدل داده شد، هوش مصنوعی صرفاً چیدمان یا شکل ظاهری طراحی را کپی کرد، بدون اینکه اصول زیربنایی یا دلیل اثرگذاری آن طراحی را بفهمد. توسعهدهنده سعی کرد با ارائه نیازهای پایه (مثلاً اینکه محصول در نهایت باید بخش قیمتگذاری داشته باشد) مدل را هدایت کند، اما خروجیها همچنان کلیشهای باقی ماندند.
فرآیند مشاهده دستی (Manual Observation)
نقطه عطف زمانی رخ داد که برنامهنویس از توصیفات احساسی و صفتهای مبهم دست کشید و جزئیات عینی و قابل توصیف را جایگزین کرد. او به جای تلاش برای «توضیح دادن»، تبهای جدیدی را در سایتهایی مثل Awwwards و Dribbble باز کرد. او به جای نگاه گذرا به طرحها، آنها را مطالعه کرد تا مکانیسمهای بصری خاص را شناسایی کند.
مشاهدات دقیق در یک نوتپد ثبت شد و سپس به مدل تغذیه شد، از جمله:
- متنهایی با گرادینت که شفافیت (Opacity) آنها از یک طرف کم میشود.
- باکسهای اینفوگرافیک شناور که در کنار موکاپهای موبایل قرار میگیرند تا قابلیتهای اپلیکیشن را توضیح دهند.
- یک ساختار خاص دو-بخش برای فوتر سایت.
تنها در این حالت بود که کیفیت خروجی جهش کرد. این ثابت کرد که گلوگاه، توانایی مدل نبود، بلکه کمبود بستر متنی (Context) کاربر بود. پرامپتی که پس از این مشاهده دستی تولید شد، نتیجهای واقعاً متفاوت و با کیفیتتر ایجاد کرد. توسعهدهنده اشاره کرد که در مقایسه با دو ساعت اول که صرف حدس زدن شده بود، یک جهش واقعی در کیفیت رخ داد.
اقتصاد پرامپتهای مبهم
برای quantifying این ضرر، توسعهدهنده از Gemini استفاده کرد تا کارایی یک «Vibe Coder» را در مقابل یک «برنامهنویس ارشد» در ابزارهای Cursor (نسخه Pro) و Google Antigravity (نسخه AI Pro) مقایسه کند.
مقایسه ابزارها: Cursor در مقابل Antigravity
- Cursor (سطح Pro): هزینه ۲۰ دلار در ماه دارد. از یک استخر اعتبار API ۲۰ دلاری استفاده میکند که هزینههای واقعی توکن (ورودی + خروجی) را در لحظه کسر میکند. به صورت پیشفرض از Composer 2.5 / Auto Mode استفاده کرده و از مدلهای Claude Sonnet/Opus، GPT-4o/5 و Gemini پشتیبانی میکند. این ابزار تکمیل خودکار (Tab completion) نامحدود ارائه میدهد و برای کدنویسی روزانه پایدار و جریانهای کاری تک-ویرایشگر بهترین است.
- Google Antigravity (AI Pro): هزینه ۱۹.۹۹ دلار در ماه دارد. از یک سیستم سهمیه چرخان استفاده میکند که روزانه یا هر چند ساعت یکبار بازنشانی میشود و تقریباً ۵ برابر محدودیتهای سطح رایگان را ارائه میدهد. به صورت پیشفرض از Gemini 3.5 Flash / Gemini Pro استفاده میکند و از Claude Sonnet/Opus و GPT-OSS پشتیبانی میکند. این ابزار برای اجرای چند-عاملی (Multi-agent) و وظایف موازی در پسزمینه ایدهآل است.
معیارهای Vibe Coder در مقابل برنامهنویس ارشد
- سبک پرامپت: Vibe Coderها از پرامپتهای تنبل مثل «بکاند را اضافه کن» یا «یک UI خوب بساز» استفاده میکنند. برنامهنویسان ارشد از محدودیتهای فنی دقیق استفاده میکنند، مانند: «یک API احراز هویت Node/Express با استفاده از JWT بساز که با Zod اعتبارسنجی شود و در فایل auth.controller.js قرار گیرد».
- مصرف توکن: Vibe Coderها معمولاً ۴۰ تا ۸۰ هزار توکن برای هر پرامپت مصرف میکنند، زیرا هوش مصنوعی باید برای حدس زدن قصد کاربر، کل پروژه را اسکن کند. برنامهنویسان ارشد با تگ کردن فایلهای خاص و تعیین محدودیتهای روشن، تنها ۵ تا ۱۵ هزار توکن مصرف میکنند.
- نرخ اتلاف: تقریباً ۷۰ تا ۸۰ درصد خروجیهای یک Vibe Coder روی خطاهایی تلف میشود که باید بازگردانی (Revert) شوند. برنامهنویسان ارشد نرخ اتلافی تنها ۵ تا ۱۰ درصد دارند.
- خروجی ماهانه: Vibe Coderها ۲ تا ۳ اپلیکیشن باگدار و نیمهتمام تولید میکنند. برنامهنویسان ارشد ۲ تا ۳ قابلیت کامل و آماده تولید (Production-ready) یا اپلیکیشنهای کامل میسازند.
- ارزش واقعی: در حالی که هر دو حدود ۲۰ دلار پرداخت میکنند، Vibe Coder تنها ۴ یا ۵ دلار خروجی قابل استفاده دریافت میکند. در مقابل، توسعهدهندهای که بستر متنی را شفاف میکند، از طریق صرفهجویی در زمان و کد آماده تولید، بیش از ۵۰ دلار ارزش استخراج میکند.
از آنجایی که توکنهای خروجی گرانتر از توکنهای ورودی هستند، هر «حلقه اصلاح» (Fix-it loop) که برای جبران یک اشتباه لازم است، سریعتر از پرامپت اولیه پول میسوزاند. این منجر میشود که Vibe Coder در حالی که تنها ۲۰٪ از کار واقعی را انجام داده، به سقف محدودیت ماهانه خود برسد.
تله اشتراکی (The Subscription Trap)
این ناکارآمدی یک انگیزه منحرف برای شرکتهای هوش مصنوعی ایجاد میکند. کاربری که به دلیل پرامپتنویسی ضعیف، سهمیه ماهانهاش را سریع تمام میکند، از نظر درآمدی مشتری ارزشمندتری است. این کاربران هر ماه بازمیگردند تا برای همان اشتراک پرداخت کنند، بدون اینکه بپرسند چرا خروجیها همچنان متوسط است. این چرخه وابستگیای را تقویت میکند که برنامهنویسان جدید را از یادگیری مبانی کدنویسی دلسرد میکند. آنها پیش از ساختن یک بنیاد واقعی، «Vibe Coding» را میپذیرند، چرا که تحت تأثیر این روایت هستند که «نباید کدنویسی یاد بگیرند چون هوش مصنوعی همه چیز را میداند».
توهم ابزاری (The Tooling Illusion)
افزودن «مهارتها» به یک عامل — مانند کتابخانههای GSAP یا ShadCN — اغلب به عنوان راهکاری برای افزایش کیفیت بازاریابی میشود. حتی Claude پیشنهاد داد که این مهارتها به تنظیمات عامل اضافه شوند تا به طور خودکار از متدهای بهینه پیروی کند. با این حال، توسعهدهنده دریافت که این اضافات فنی اگر بستر متنی (Context) اصلی غایب باشد، هیچ تاثیری ندارند. کار دستیِ مشاهده طراحیهای واقعی و ترجمه آنها به بستر متنی عینی است که خروجی را اصلاح میکند.
مهارت واقعی در عصر هوش مصنوعی، دسترسی به گرانترین مدل نیست، بلکه دانستن نحوه هدایت آن است. توسعهدهنده اشاره کرد که هرگز برای یک پروژه واقعی، هزینه اشتراک Cursor، Claude یا Antigravity را پرداخت نکرده است. او از عادت تکیه کامل به هوش مصنوعی اجتناب میکند، زیرا این عادت میتواند جمله «هوش مصنوعی انجامش نداد» را به یک بهانه تبدیل کند، به جای اینکه آن را سیگنالی ببیند که ورودی کاربر مشکل داشته است.
در عوض، او از لایه رایگان Claude برای ساخت بستر متنی مناسب استفاده میکند و سپس آن بستر را به هر لایه رایگانی که عامل کدنویسی ارائه میدهد منتقل میکند. این رویکرد اغلب کافی است، زیرا مهارت واقعی در «هدایت» است، نه در «دسترسی».
هزینه وابستگی
این موضوع نشان میدهد که رونق فعلی توسعه «مبتنی بر هوش مصنوعی»، تا حد زیادی ناشی از یک مشکل بستر متنی است که لباس ابزار به تن کرده است. توسعهدهندگانی که موفق میشوند، کسانی هستند که مالکیت تصمیمات را حفظ میکنند، به جای اینکه «حس» (Vibe) پروژه را به یک مدل اشتراکی برونسپاری کنند.
وقتی یک برنامهنویس کاملاً به هوش مصنوعی تکیه میکند تا مسائل را حل کند، دیگر شکست مدل را به عنوان سیگنالی برای بهبود ورودی خود نمیبیند، بلکه آن را یک «مشکل ابزاری» تلقی میکند. این هسته اصلی تله است: پرداخت هزینه برای ابزاری برای حل مشکلی که فقط با مشاهده دقیق و صراحت کاربر حل میشود.
برای اجتناب از این تله، توسعهدهندگان باید تاریخچه پرامپتهای خود را ممیزی کنند تا ببینند چه تعداد از پرامپتهای تکمیلی صرفاً برای بازگرداندن اشتباهات قبلی هوش مصنوعی صرف شده است. اگر این نسبت بالا باشد، مشکل از ورودی است، نه مدل. خرید اشتراک و امید به اینکه هوش مصنوعی خودش بفهمد، همان تله است؛ ارائه صراحت واقعی و پذیرش مالکیت، راه حل است.
گام بعدی شما
- تاریخچه پرامپتهای خود را بررسی کنید؛ اگر تعداد دفعاتی که خواستید مدل «اشتباه قبلیاش را اصلاح کند» زیاد است، مشکل از ورودی شماست نه مدل.
- به جای صفتهای کلی (مثل «مدرن»، «بهتر»، «سریع»)، از توصیفات مکانیکی و عینی استفاده کنید.
- ابتدا در نسخههای رایگان (مثل لایه رایگان Claude) بستر متنی را دقیق بسازید و سپس آن را به عامل کدنویسی منتقل کنید.
اما داستان سختافزاری این تحول و هزینه واقعی هر توکن حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو