«توهم بهره‌وری»؛ خطر اتکای عامل‌های کدنویس به توکن‌های رایگان

یک برنامه‌نویس می‌تواند در یک بعدازظهر ۱۰ میلیون توکن را مصرف کند و در پایان روز، مخزنی از کد داشته باشد که حتی یک تست ساده را هم پاس نمی‌کند. این شکاف عمیق بین مصرف منابع و کاربرد واقعی، هزینه پنهان دستیارهای مدرن کدنویسی است. این موضوع در گزارشی که در ۲۱ اوت ۲۰۲۶ از طریق وب‌سایت dev.to منتشر شد، مورد بررسی قرار گرفته است.

برای بسیاری از توسعه‌دهندگان، طرح‌های رایگان به‌عنوان معیاری برای پیشرفت عمل می‌کنند. وقتی یک ارائه‌دهنده حجم عظیمی از توکن را رایگان می‌بخشد، وسوسه این است که رشد شمارنده توکن‌ها را نشانه فعالیت و پیشرفت بدانیم. اما این وضعیت یک حلقه بازخورد خطرناک می‌سازد؛ جایی که صرف توکن‌ها شبیه به ارسال اصلاحات (Shipping Fixes) به نظر می‌رسد، در حالی که بدنه کد به‌دلیل تغییرات تأییدنشده (Unverified Diffs) در سکوت در حال تخریب است. این موضوع دقیقاً شبیه به بحث‌های اخیر در جامعه DEV درباره «بج‌های هوش مصنوعی» است؛ برچسبی که توصیف می‌کند چیزی چگونه تولید شده است، اما نمی‌گوید آیا آن خروجی کیفیت لازم را دارد یا خیر. یک بج روی یک پست، درست مانند تعداد توکن‌ها در یک داشبورد، صرفاً یک جایگزین (Proxy) است که مردم آن را با خودِ هدف اشتباه می‌گیرند. این چالش‌ها نشان می‌دهد که چرا لایه‌های رایگان AI بدون حسابرسی دقیق توکن اغلب در محیط‌های عملیاتی با شکست مواجه می‌شوند.

تصور کنید عضویت رایگان یک باشگاه ورزشی را داشته باشید که به‌جای اندازه‌گیری میزان رشد عضلات شما، فقط تعداد ساعت‌های حضور شما در ساختمان را ثبت می‌کند. شما ممکن است احساس بهره‌وری کنید چون «در حال استفاده از سرویس هستید»، اما سلامتی شما در واقع بهبود نیافته است. اعطای توکن‌های رایگان هوش مصنوعی هم بر اساس همین منطق غلط عمل می‌کند: آن‌ها آنچه را که ارائه‌دهنده می‌بخشد اندازه می‌گیرند، نه آنچه را که برنامه‌نویس به دست می‌آورد. دسترسی رایگان به مدل‌ها و گزینه‌های سرور رایگان دقیقاً به این دلیل ارزشمند هستند که بهانه مالی برای نادیده گرفتن اندازه‌گیری را حذف می‌کنند. اشتباه اصلی اینجاست که خودِ این اعتبار (Grant) را به‌عنوان پیشرفت تلقی کنیم. این رویکرد در واقع تداوم همان مدل‌های قیمت‌گذاری است که در آن هزینه‌های توکنی می‌توانند بودجه‌های توسعه را به شکلی گمراه‌کننده مدیریت کنند.

همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدل بدون لایه تأیید، ریسک‌های سیستمی ایجاد می‌کند. برای حل این مشکل، پروژه MonkeyCode — که در زمان نگارش این متن، ۱۰ میلیون توکن رایگان در طرح رایگان خود و یک گزینه سرور رایگان ارائه می‌دهد — سیستمی به نام «دفتر کل وصله‌ها» (Patch Ledger) را پیشنهاد می‌کند. (افشا: این مطلب به‌عنوان بخشی از معرفی محصول MonkeyCode تهیه شده است). در این سیستم، به‌جای ردیابی کل توکن‌ها، توسعه‌دهندگان باید تعداد توکن‌های مصرف‌شده به‌ازای هر «وصله تأییدشده» (Verified Patch) را ردیابی کنند.

سازوکار دفتر کل وصله‌ها

یک دفتر کل وصله، ادعاهای عامل (Agent) درباره موفقیت را کاملاً نادیده می‌گیرد و صرفاً به مجموعه تست‌ها (Test Suite) اعتماد می‌کند. این فرآیند از یک خط لوله سخت‌گیرانه پیروی می‌کند:

• جداسازی (Isolation): عامل روی یک مشکل خاص در یک محیط کاری موقت (Disposable Worktree) اجرا می‌شود. اسکریپت برای هر مشکل یک بار مخزن را کلون می‌کند تا از وضعیت پاک و بدون تغییرات قبلی اطمینان حاصل شود.
• استخراج (Extraction): سیستم با استفاده از ابزار jq مقدار دقیق توکن‌های مصرف‌شده را از پاسخ JSON استخراج می‌کند. این ابزار به‌طور خاص به دنبال کلید .usage.total_tokens می‌گردد.
• تأیید (Verification): اگر تغییرات در دستور git diff --check شکست بخورند یا تست‌های خودکار پروژه (مثلاً npm test --silent) را پاس نکنند، وصله رد می‌شود.
• محاسبه (Calculation): معیار نهایی، تقسیم کل توکن‌های مصرف‌شده بر تعداد وصله‌های تأییدشده است.

این رویکرد، یک عدد تبلیغاتی را به یک عدد مهندسی تبدیل می‌کند. برای یک مخزن کد کوچک و سالم، هدف باید به‌شدت زیر ۱۰۰,۰۰۰ توکن به‌ازای هر وصله تأییدشده باشد. اگر این عدد از ۲۰۰,۰۰۰ توکن فراتر رود، احتمالاً عامل در حال سوزاندن اعتبار رایگان روی نویز است، نه سیگنال‌های مفید. این آستانه‌ها نقاط شروعی برای مخازن کوچک هستند و بسته به اندازه مخزن و میزان پوشش تست‌ها (Test Coverage) تغییر خواهند کرد. در واقع، این اتلاف منابع می‌تواند مشابه اثر مخرب طول جلسات بر مصرف توکن باشد که منجر به رشد درجه دوم هزینه‌ها می‌شود.

پیاده‌سازی فنی

راهکار پیشنهادی یک اسکریپت Bash است که مستقل از ارائه‌دهنده (Provider-agnostic) عمل کرده و از متغیر محیطی AGENT_CMD استفاده می‌کند. این ساختار اجازه می‌دهد ابزار با MonkeyCode، مدل‌های محلی یا هر رابط خط فرمان (CLI) که اشیاء مصرف توکن به سبک OpenAI را صادر می‌کند، کار کند. با کلون کردن مخزن برای هر مشکل و اعمال تغییرات روی یک Worktree، دفتر کل تضمین می‌کند که فقط کدهایی که تست‌ها را پاس کرده‌اند، به‌عنوان «برد» ثبت شوند.

مثال استفاده از این ابزار به این صورت است:
export AGENT_CMD="your-agent-cli --model free-tier" printf 'fix the flaky login test\nupdate the cache invalidation logic\n' > issues.txt ./patch-ledger.sh https://github.com/example/repo.git issues.txt

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

زمینه و محدودیت‌ها

برای شما به‌عنوان توسعه‌دهنده، این یعنی «رایگان بودن» یک ابزار بی‌معنی است اگر زمان صرف‌شده برای دیباگ کردن تغییرات تأییدنشده هوش مصنوعی، بیشتر از هزینه خرید یک مدل پولی و دقیق‌تر باشد. طرح رایگانی که کد تأییدنشده تولید می‌کند، هدیه نیست؛ بلکه مالیاتی بر تمرکز و توجه برنامه‌نویس است. برای مثال، اجرای برنامه‌ای که از ۹ تلاش، ۳ وصله تأییدشده با مصرف ۶۰,۰۰۰ توکن برای هر تلاش دارد، یعنی نیم میلیون توکن برای ۳ اصلاح واقعی هزینه شده است.

با این حال، این روش محدودیت‌هایی دارد:

• شکاف‌های تأیید: این سیستم نمی‌تواند تغییرات مستندات، جابجایی‌های معماری یا مهاجرت‌های پیکربندی (Configuration Migrations) را که فاقد تست‌های خودکار هستند، تأیید کند.
• زیرساخت: این روش پیش‌فرض را بر وجود یک مجموعه تست قدرتمند می‌گذارد؛ بدون وجود تست، اسکریپت ساکت می‌ماند و خروجی نمی‌دهد.
• تفاوت ارائه‌دهندگان: نحوه حسابداری توکن‌ها بین ارائه‌دهندگان متفاوت است و برخی از CLIهای عامل، داده‌های مصرف را به‌طور کامل پنهان می‌کنند.
• تست‌های ناپایدار: تست‌های Flaky ممکن است یک وصله خوب را به‌راحتی مانند یک وصله بد جریمه کنند.

علاوه بر این، عدد ۱۰ میلیون توکن مربوط به اوت ۲۰۲۶ است. از آنجایی که طرح‌های رایگان بدون هیچ تشریفاتی تغییر می‌کنند، اسکریپت باید هر زمان که اعتبار جدیدی دریافت شد، دوباره اجرا شود. توسعه‌دهندگانی که در حال ساخت نمونه‌های اولیه (Greenfield Prototypes) هستند — جایی که مسیرهای اشتباه بخشی از فرآیند اکتشاف است — یا کسانی که به دنبال مقایسه‌های در سطح بنچ‌مارک با Seedهای کنترل‌شده هستند، ممکن است به این دفتر کل نیاز نداشته باشند.

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

منتظر ظهور داشبوردهای یکپارچه «هزینه به‌ازای هر اصلاح» (Cost-per-fix) در IDEها باشید که در نهایت می‌توانند جایگزین شمارنده‌های ساده توکن به‌عنوان معیار اصلی بهره‌وری عامل‌ها شوند.

گام بعدی شما

• بررسی کنید آیا پروژه فعلی شما تست‌های خودکار کافی برای تأیید خروجی‌های هوش مصنوعی را دارد یا خیر.
• به‌جای تکیه بر داشبورد مصرف توکن، یک معیار داخلی برای «تعداد توکن به‌ازای هر Merge Request موفق» تعریف کنید.
• در صورت استفاده از مدل‌های رایگان، زمان صرف‌شده برای بازبینی (Review) کدها را ثبت کنید تا هزینه واقعی «رایگان بودن» را بسنجید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.