هزینهٔ پذیرش کد؛ دلیل پنهان شکست بهره‌وری در عامل‌های Kilo Code

یک Diff سریع که توسط هوش مصنوعی تولید شده، اگر بازبینی و اصلاح آن توسط انسان دو برابر زمان عادی طول بکشد، در واقع هیچ بهره‌وری‌ای ایجاد نکرده است. برای تیم‌هایی که از Kilo Code استفاده می‌کنند، معیار واقعی نه سرعت تولید وصله (Patch) توسط عامل، بلکه «هزینهٔ پذیرش» (Cost of Acceptance) پیش از ورود کد به شاخه اصلی است.

Kilo Code قادر است در عرض چند دقیقه یک وصله از نظر ساختاری صحیح ایجاد کند. اما پس از آن، مرحلهٔ دوم و گران‌تر آغاز می‌شود: یک بازبین انسانی باید Diff را در حالت side-by-side باز کند، خطاهای ناقص را بیابد، یک Snapshot را بازگرداند و بخشی از کد را دستی بازنویسی کند. در اینجا عامل سریع عمل کرده، اما در نهایت بازبین است که تکلیف کار را روشن می‌کند. صرفه‌جویی زمانی واقعی است که Diff تولید شده، در مرحلهٔ تایید، هزینه‌ای دو برابری برای انسان ایجاد نکند.

بسیاری از توسعه‌دهندگان در تلهٔ اندازه‌گیری عملکرد مدل به‌جای عملکرد تیم می‌افتند. وقتی یک عامل در چند ثانیه Diff تولید می‌کند، توهمی از کارایی ایجاد می‌شود. اما اگر بازبین ده دقیقه وقت صرف یافتن خطا، بازگرداندن یک Snapshot و بازنویسی منطق کند، عامل فقط حجم کار را جابه‌جا کرده است، نه اینکه آن را حذف کند. در فاصلهٔ «تولید Diff» تا «پذیرش در شاخه اصلی»، یک انسان قرار دارد؛ زمان او، نه زمان مدل، گران‌ترین ردیف هزینه‌ در بودجهٔ یک پروژه آزمایشی است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن دیدیم، سرعت بدون دقت، ریسک عملیاتی را بالا می‌برد. این تنش حتی در معماری داخلی Kilo Code نیز دیده می‌شود. بر اساس مستندات رسمی این پلتفرم که در ۱۸ جولای ۲۰۲۶ بازبینی شده، سیستم برای مدیریت این توازن، سطوح مدل را تفکیک کرده است:

• Frontier: برای کارهای پیچیده و با ریسک بالا (High-stakes).
• Balanced: پیش‌فرض برای هزینه‌های پیش‌بینی‌پذیر.
• Efficient: برای مسیریابی خودکار به ارزان‌ترین مدلی که آستانهٔ دقت مورد نیاز را پاس می‌کند.

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

ردیابی «هزینهٔ پذیرش»

برای عبور از این تله، یک برنامهٔ آزمایشی باید دفترچه ثبت وقایع (Task Log) دقیقی داشته باشد. ثبت سادهٔ «تکلیف انجام شد» کافی نیست. این دفترچه باید جدولی باشد که در آن هر ردیف معادل یک تکلیفی است که توسط عامل به یک Diff تبدیل شده است. یک دفترچه با دقت بالا، مستلزم ثبت پنج فیلد مشخص برای هر Diff تحت هدایت عامل است:

• شناسه تکلیف: ID منحصربه‌فرد تیکت یا ویژگی (Feature).
• زمان اجرای عامل: زمانی که هوش مصنوعی صرف تولید راهکار کرده است.
• زمان بازبینی: مدت‌زمانی که انسان صرف حسابرسی Diff کرده است.
• مدت اصلاحات: زمان صرف شده برای اصلاحات دستی و ثبت اینکه آیا اصلاً اصلاحاتی رخ داده است یا خیر.
• وضعیت بازگشت: آیا نیاز به بازگرداندن Snapshot (برگشت به حالت قبل) بود یا خیر.
• تصمیم نهایی: آیا Diff «پذیرفته شده»، «بازنویسی شده» یا «رد شده» است.

بدون ثبت زمان بازبینی، داده‌ها فقط سرعت عامل را نشان می‌دهند که معیاری فریبنده است. همچنین نادیده گرفتن بازگشت‌ها (Reverts)، گران‌ترین دسته از شکست‌ها را از محاسبات حذف می‌کند. اگر زمان بازبینی و بازگشت را اصلاح نکنید، در واقع بهره‌وری مدل را می‌سنجید، نه بهره‌وری تیم را.

هر چرخهٔ عاملی (Agent Turn) که فایل‌ها را تغییر می‌دهد، یک خلاصهٔ جمع‌شونده از Diff (شامل فایل‌ها، موارد اضافه شده و حذف شده) و یک نشان (Badge) در پیام ارائه می‌دهد. طبق مستندات Kilo Code در مورد نقاط بازرسی (۱۸ جولای ۲۰۲۶)، این نشان یک نمایشگر side-by-side را در VS Code باز می‌کند. این ابزار، یک واحد کاری عینی و زمان‌بندی شده برای ثبت در دفترچه فراهم می‌کند: یک چرخهٔ عاملی با خلاصهٔ Diff مشخص.

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

بهره‌گیری از معیارهای داخلی Kilo Code

اندازه‌گیری زمان عامل نیازی به کرونومتر دستی ندارد. Kilo Gateway هزینه و توکن‌های هر درخواست را با دقت میکرو-دلار ثبت می‌کند (به گونه‌ای که هر ۱ دلار برابر با ۱,۰۰۰,۰۰۰ میکرو-دلار است). فیلد usage در پاسخ‌ها — یا آخرین تکه SSE در زمان استریم — توکن‌های ورودی، توکن‌های خروجی، توکن‌های کش، هزینه و زمان تا نخستین توکن (Time-to-first-token) را برمی‌گرداند، همان‌طور که در مستندات صورت‌حساب گیت‌وی در ۱۸ جولای ۲۰۲۶ آمده است.

یک استثنای حیاتی وجود دارد: مدل Bring Your Own Key (BYOK). اگر توسعه‌دهنده از کلیدهای شخصی Anthropic، OpenAI، Google، Azure، AWS Bedrock یا سایر تامین‌کنندگان استفاده کند، Kilo Code هزینهٔ ثبت شده برای خودش را ۰ دلار می‌زند. در این حالت، توسعه‌دهنده مستقیماً به تامین‌کننده بالادستی پرداخت می‌کند. بنابراین، ستون «زمان عامل» در یک دفترچه دستی زیر مدل BYOK، هزینه‌ها را به‌طور سیستماتیک کمتر از مقدار واقعی تخمین می‌زند، مگر اینکه صورت‌حساب‌های خارجی به‌طور صریح تطبیق داده شوند.

دو ابزار فنی دیگر به ردیابی صحت و بازیابی کمک می‌کنند:

مکانیزم‌های Snapshot

• ثبت خودکار: Kilo Code در ابتدا و انتهای هر فراخوانی مدل در یک چرخهٔ عاملی، Snapshotهای git را به‌طور خودکار ایجاد می‌کند.
• بازگشت به اینجا (Revert to Here): این تابع فضای کاری را بازمی‌گرداند. با این حال، دقت این بازگشت بر اساس پیام کاربر است، نه هر فایل یا گام مجزا.
• ریسک داده: هر ویرایش دستی خارج از تکلیف که ذخیره نشده باشد، هنگام بازگشت بازنویسی می‌شود (مستندات Kilo Code، ۱۸ جولای ۲۰۲۶).

ابزارهای بازبینی

• دستور /review: این دستور یک بررسی محلی توسط هوش مصنوعی روی تغییرات commit نشده، شاخه‌ها، commitها یا PRها را قبل از Push فعال می‌کند. همچنین از حالت ابری برای رویدادهای PR/MR پشتیبانی می‌کند.
• دامنه: بازبینی دقیقاً محدود به فایل‌های تغییریافته است.
• هزینه بتا: در بتای محدود فعلی، زمان صرف شده برای بازبینی رایگان است، اگرچه فرآیند استدلال مدل همچنان اعتبار Kilo Code را مصرف می‌کند.

ریاضیات بهره‌وری هوش مصنوعی

محاسبه ارزش واقعی یک عامل نیازمند فرمول خاصی است (روش نویسنده، نه مستند رسمی Kilo): هزینه پذیرش = زمان بازبینی + زمان اصلاح + زمان بازگشت.

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

برای تجسم این موضوع، جدول ردیابی زیر را (با مقادیر نمونه برای نمایش) در نظر بگیرید:

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

مدیریت زیرساخت

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

برای تیم‌های روسی، تهیهٔ سرویس یک چالش جداگانه است. ابزارهایی مانند provod.ai یک API واحد و سازگار با SDKهای OpenAI و Anthropic ارائه می‌دهند. با تغییر base_url به https://api.provod.ai/v1، تیم‌ها می‌توانند بدون نیاز به کارت‌های خارجی یا VPN، پرداخت‌ها را از طریق SBP یا انتقال بانکی به روبل انجام دهند. مدل‌ها با قیمت رسمی ۱:۱ تامین‌کننده و بدون اضافات provod.ai در دسترس هستند.

from openai import OpenAI
client = OpenAI(
    api_key="YOUR_KEY",
    base_url="https://api.provod.ai/v1",
)

تغییر روش دسترسی، کیفیت Diff را تضمین نمی‌کند، اما با حذف متغیر «دسترسی» از دفترچه ثبت، حسابداری هزینه‌ها را شفاف می‌کند.

قیمت‌گذاری و مقیاس‌دهی

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

طبق قیمت‌گذاری Kilo در ۱۸ جولای ۲۰۲۶، تیم‌ها چندین گزینه دارند:

• سطح رایگان: پلاگین VS Code متن‌باز و رایگان است برای افراد. Kilo Gateway به ۲۰۰ درخواست در ساعت برای هر IP محدود است.
• Kilo Pass: سه سطح Starter (۱۹ دلار)، Pro (۴۹ دلار) و Expert (۱۹۹ دلار) ماهانه، هر کدام با اعتبارهای جایزه.
• پلان Teams: ۱۵ دلار برای هر کاربر در ماه (با ۱۴ روز تست رایگان). این پلان صورت‌حساب متمرکز، امتیاز پذیرش (Adoption Scoring) و تحلیل‌های استفاده را اضافه می‌کند.

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

محدودیت‌های حفاظ‌ها

اشتباه است که مجوزها (Permissions) را با بهره‌وری اشتباه بگیریم. Kilo Code اجازه می‌دهد کاربران وضعیت‌های allow (اجازه)، ask (پرسش) یا deny (رد) را برای ابزارهای مختلف، شامل دستورات shell، ویرایش فایل، ابزارهای MCP، درخواست‌های وب و زیر-عامل‌ها (Sub-agents) تنظیم کنند. اگر قاعده‌ای مطابقت نیابد، پیش‌فرض روی ask است.

در حالی که این تنظیمات از تغییرات مخرب و خاموش جلوگیری می‌کنند، اما هیچ تاثیری بر ارزان‌تر شدن بازبینی Diff ندارند. در واقع، مستندات رسمی هشدار می‌دهند که تنظیمات auto-approve (تأیید خودکار) باعث حذف اعلان‌های تأیید شده و می‌تواند منجر به «از دست رفتن داده‌ها، خرابی فایل یا بدتر» شود؛ به‌ویژه دستورات shell به عنوان پرریسک‌ترین دسته معرفی شده‌اند. این ریسک‌ها در موارد شدیدتر می‌تواند به تولید توهماتی منجر شود که بدافزارهای خارجی را اجرا می‌کنند و امنیت سیستم را به کلی به خطر اندازد.

مجوزها خسارت احتمالی را محدود می‌کنند، اما دفترچه ثبت تکالیف تنها ابزاری است که اندازه‌گیری می‌کند آیا عامل واقعاً به سرعت تیم کمک می‌کند یا خیر. پرسش درست این نیست که «عامل چقدر سریع‌تر است؟»، بلکه این است که «چقدر زمان لازم است تا یک تغییر پذیرفته شود؟»

گام بعدی شما

• برای تمامی Diffهای تولید شده توسط Agent، یک ستون «زمان بازبینی» و «وضعیت بازگشت» به لاگ‌های خود اضافه کنید.
• اگر از مدل BYOK استفاده می‌کنید، هزینه‌های مستقیم تامین‌کننده (OpenAI/Anthropic) را با زمان اجرای Agent در Kilo Gateway تطبیق دهید.
• در تنظیمات Kilo Code، دسترسی به دستورات Shell را هرگز روی auto-approve قرار ندهید و از وضعیت ask استفاده کنید.

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