اگر برای کد خصوصی خود یک استخر رایگان ۱۰ میلیون توکنی دارید اما اجازه ندارید کد را از محیط امن خود خارج کنید، این عدد تنها یک نمایش ویترینی است. برای مدیران مهندسی، تصمیمگیری درباره استفاده از هوش مصنوعی در زمان اوج ارسال کدها (PR Spikes)، یک مسئله قیمتی نیست، بلکه یک چالش مالکیت و نظارت است.
بسیاری از تیمها پذیرش هوش مصنوعی را شبیه به جستوجوی ارزانترین «مسیر» میبینند. آنها گزینههای رایگان ابری را با تامینکنندگان پولی یا سرورهای میزبانی شخصی مقایسه میکنند. اما این رویکرد، واقعیت «مونو-ریپوهای خصوصی» را نادیده میگیرد. اگر ابزاری نیاز داشته باشد تغییرات حساس کد (diffs) را به یک ابر شخص ثالث بفرستد، حجم استخر رایگان توکن تنها یک حواسپرتی از یک شکست امنیتی بنیادین است. تصور کنید در یک پنجشنبه در اوایل اکتبر: دو نگهدارنده ارشد یک مخزن عمومی را مدیریت میکنند که ناگهان جمعیت زیادی را به خود جذب کرده است، در حالی که یک مونو-ریپوی خصوصی باید کاملاً نشتناپذیر بماند. وقتی کسی میپرسد چرا با وجود یک «مسیر رایگان»، ارشدها هنوز هر وصله را دستی میخوانند، در واقع از واحد اندازهگیری اشتباهی استفاده میکند. بحث بر سر حجم استخر نیست؛ بلکه بر سر این است که چه کسی اجازه دارد تغییرات کد را ببیند.
با تکیه بر منطق گیتهای عملیاتی، این چارچوب تمرکز را از قیمت روی برچسب به «سد نظارتی» (Custody Bar) منتقل میکند. در یک محیط عملیاتی، هدف محدود و مشخص است: پیشنویس یک یادداشت بررسی یا پیشنهاد یک وصله کوچک، در حالی که یک نگهدارنده انسانی، اختیار نهایی ادغام (Merge) را در اختیار دارد.
سه مسیر مشارکت
قبل از محاسبه هزینهها، یک تیم باید تشخیص دهد که در واقع در کدام مسیر قرار دارد. این مسیرها به دلایلی کاملاً متفاوت شکست میخورند:
- مسیر ابری رایگان (Free Hosted Lane): این مسیر اغلب با یک سرور رایگان همراه است که شما هنوز هزینهای برای آن نمیپردازید. ریسک اصلی در اینجا، صفحه مجوزها و شرایط خدمات (Terms of Service) است. این چالشها در واقع بخشی از هزینههای پنهان ابزارهای رایگان هستند که میتوانند منجر به نشت ساعتهای مهندسی شوند.
- مسیر تامینکننده پولی (Paid Vendor Lane): جایی که صورتحساب در واقع یک قرارداد است. ریسک در اینجا، اعتبار قیمتهای ارائه شده و قوانین مالکیت است که در قرارداد پردازش داده (DPA) نوشته شده است.
- مسیر میزبانی شخصی (Self-Hosted Lane): جایی که شما مالک فرآیند و مسئول پاسخگویی به خرابیها (Pager) هستید. ریسک در اینجا، سربار عملیاتی و سقف سختافزاری است.
چارچوب نظارتی (Custody Framework)
برای عبور از «تئاتر جلسات»، این چارچوب متغیرهای خاصی را برای سنجش قابلیت اجرای یک مسیر AI معرفی میکند. اگر نمادی مالک نداشته باشد، وارد تصمیمگیری نمیشود. طبق راهنمایی که در ۸ اکتبر ۲۰۲۶ در dev.to منتشر شد، تیمها باید قبل از امتیازدهی به هر ابزار، این نمادها را تعریف کنند:
- V (سهم خصوصی): سهمی از وظایف کمکی که با کد خصوصی، رمزها یا دادههای مشتری در تماس است. اندازهگیری از ۰ تا ۱.
- C (سد نظارتی): عدد ۰ یعنی فقط کد عمومی؛ عدد ۱ یعنی پرامپتها و تغییرات در محیطی (Tenant) میمانند که شما کنترل میکنید.
- A (حجم هفتگی): تعداد تغییرات (diffs) کمکی که در هفته انتظار دارید.
- H (زمان بازبین): دقایقی که یک بازبین نامبرده واقعاً برای هر تغییر کمکی صرف میکند—نه دقایقی که آرزو میکردید صرف میکردند.
- R (ظرفیت بازبین): کل ساعات در دسترس بازبین در هفته برای این مسیر خاص.
- S (طول اوج): مدت زمان افزایش مشارکت (Spike) به هفته.
- T (هزینه توکن): تعداد توکنها برای هر تغییر کمکی، که روی مخازن خودتان اندازهگیری شده باشد، نه عددی که از یک پست تبلیغاتی قرض گرفته شده باشد.
- F (استخر رایگان اعلامشده): حجم توکن رایگان ادعایی. برای MonkeyCode، در برگه معرفی عدد ۱۰,۰۰۰,۰۰۰ ذکر شده است. این عدد باید دوباره خوانده شود و نباید به صورت سختافزاری از یک وبلاگ کپی شود.
- U (قیمت پولی): قیمت هر میلیون توکن بر اساس استعلامی که واقعاً در دست دارید.
- O (هزینه عملیاتی): ساعات عملیاتی میزبانی شخصی در هفته، ضرب در هزینه ساعتی بارگذاری شده.
محاسبه گلوگاهها
این چارچوب دو نقطه شکست اصلی را شناسایی میکند که توکنها نمیتوانند آنها را حل کنند. اول، «مشکل تقویم» است. بار بررسی به صورت A * H / 60 محاسبه میشود. اگر این عدد از ساعات در دسترس بازبین (R) بیشتر شود، مسیر شکست میخورد. شما مشکل مدل ندارید؛ بلکه مشکل نیروی انسانی دارید. اضافه کردن یک مدل سریعتر، کمبود زمان در تقویم را حل نخواهد کرد.
دوم، «سوزاندن در اوج» (Spike Burn) است. برای رویدادهایی مثل Hacktoberfest—که تقویمهای رویدادهای عمومی، ماه اکتبر را شلوغ میکنند—تیمها باید کل توکنهای مصرفی را با فرمول A * S * T حساب کنند. این راهنما یک سیاست «حاشیه امنیت» (Headroom) حداقل ۰.۲۰ (۲۰٪) بالاتر از استخر رایگان اعلامشده (F / burn - 1) را پیشنهاد میکند تا از شکست در میانه اوج مشارکت جلوگیری شود. این عدد ۰.۲۰ یک انتخاب سیاستی است که باید صراحتاً در تیکت ثبت شود. یک کارت امتیازدهی، ابزاری برای گفتگو است، نه یک حقیقت مطلق؛ تغییر دادن این آستانه، برنده را تغییر میدهد.
ایجاد خط پایه
برای پرهیز از حدس زدن مقدار 'A' (حجم هفتگی)، چارچوب اصرار دارد که از دادههای سال گذشته به عنوان خط پایه استفاده شود. اعداد رند جایی هستند که استخرهای رایگان میمیرند. تیمها باید از لاگهای git برای یافتن تعداد واقعی ادغامها در اکتبر گذشته استفاده کنند. برای مثال:
git log origin/main --since="2025-10-01" --until="2025-10-28" --merges --oneline | wc -l
علاوه بر این، چارچوب هشدار میدهد که نمودار سازمانی با ظرفیت بازبین یکی نیست. اگر دو نام در لاگ ادغامها غالب هستند، R کوچکتر از تعداد کل کارکنان رسمی است. این موضوع با دستور زیر قابل تایید است:
git log origin/main --since="2025-10-01" --until="2025-10-28" --merges --pretty=format:'%an' | sort | uniq -c | sort -nr
مقایسه سه مسیر
پروژه MonkeyCode به عنوان نمونهای ذکر شده که دسترسی رایگان به مدل و گزینه سرور با استخر ۱۰ میلیون توکنی (تا ۸ اکتبر ۲۰۲۶) ارائه میدهد. اما چارچوب پنج گیت سختگیرانه را برای تعیین اینکه آیا این مسیر «ابری رایگان» واقعاً قابل استفاده است یا خیر، اعمال میکند:
- نظارت (Custody): اگر یک رمز، یک اعتبارنامه تولید (Production Credential)، یک داده مشتری یا یک مخزن خصوصی در مسیر پرامپت قرار داشته باشد، مسیر ابری رایگان فوراً «رد» میشود.
- ظرفیت بازبین: اگر
A * H / 60 > Rباشد، مسیر شکست میخورد. شما باید محدوده کار را کم کنید یا انسان اضافه کنید؛ اضافه کردن یک مدل، یک برنامه نیست. در این مرحله، بازبین باید مراقب باشد تا دچار خطای False-Done نشود و صرفاً به سبز بودن تستها برای کدهای تولید شده توسط AI اکتفا نکند. - حاشیه استخر: اگر مصرف در اوج، بیش از ۸۰٪ استخر اعلامشده باشد، یا اگر نتوانید همین امروز صفحه مجوزها را باز کنید تا عدد را تایید کنید، طرح کنار گذاشته میشود.
- لایسنس: اگر لایسنس پروژه و شرایط خروجی را در برابر مخزنی که در آن ادغام میکنید نخواندهاید، فرآیند متوقف میشود. متنباز بودن به این معنا است که شما میتوانید لایسنس را بخوانید، نه اینکه لزوماً «برای کد مشتری مناسب» باشد.
- دسترسی ابزار (Tool Reach): اگر دستیار بتواند ابزارهایی خارج از مخزن را فراخوانی کند، این یک مجوز (Grant) است. هر جایگاهی که مالک نامبرده نداشته باشد، مجوز داده نمیشود.
هزینه کنترل
وقتی مسیر رایگان شکست میخورد، انتخاب بین تامینکنندگان پولی و میزبانی شخصی است. چارچوب استدلال میکند که میزبانی شخصی در واقع خرید یک «سقف» است که باید خودتان اندازهگیری کنید. این بخش یک هزینه عملیاتی (O) را معرفی میکند که به صورت ساعات عملیاتی هفتگی ضرب در هزینه ساعتی بارگذاری شده محاسبه میشود. برای مدیریت این هزینهها در مقیاس ماشینبهماشین، راهکارهای جدیدی مانند استفاده از پروتکل HTTP 402 توسط AgentBadge برای اتوماسیون پرداختها در حال ظهور هستند.
در یک سناریوی نمونه، تیمی با ۴۰ تغییر عمومی و ۸ تغییر خصوصی در هفته (H = ۱۲ دقیقه، R = ۱۰ ساعت، S = ۴ هفته، T = ۸,۰۰۰) دریافت که اگرچه استخر ۱۰ میلیون توکنی لوکس به نظر میرسید، اما «سهم خصوصی» فوراً گزینه ابری رایگان را حذف کرد. بار بررسی عمومی ۸ ساعت و بخش خصوصی ۱.۶ ساعت بود که مجموعاً ۹.۶ ساعت در برابر ظرفیت ۱۰ ساعته قرار گرفت. یک روز بیماری، کل این مسیر را به یک خیال تبدیل میکند.
مصرف عمومی ۱,۲۸۰,۰۰۰ توکن و خصوصی ۲۵۶,۰۰۰ توکن بود (جمعاً ۱,۵۳۶,۰۰۰). اگرچه این مقدار در استخر ۱۰ میلیونی جا میشد، اما الزام نظارتی برای تغییرات خصوصی یعنی آنها نباید محیط امن (Tenant) را ترک کنند. هزینه مسیر پولی (با نرخ فرضی ۳ واحد برای هر میلیون) تنها ۴.۶ واحد در ماه بود که در برابر زمان بازبین ناچیز است. در مقابل، میزبانی شخصی ۱,۲۸۰ واحد در چهار هفته هزینه داشت (۳۲۰ واحد در هفته). این یک «مالیات بر کنترل» است که اگر کار صرفاً عمومی باشد، غیرضروری است.
تحلیل حساسیت
قبل از بحث درباره صفتها، چارچوب سه تست حساسیت را پیشنهاد میکند:
۱. حجم توکن: اگر T پنج برابر شود، مصرف عمومی به تنهایی به ۶.۴ میلیون میرسد. در ترکیب با کارهای خصوصی، شما به استخری تکیه میکنید که شاید دوباره نخوانده باشید. قبل از بحث، T را اندازهگیری کنید.
۲. زمان بررسی: اگر H از ۱۲ به ۲۰ دقیقه برسد، بار بررسی عمومی به ۱۳.۳ ساعت میرسد و از R بیشتر میشود. مسیر در هر قیمتی، حتی رایگان، «رد» است.
۳. تغییر حجم کار: اگر کارهای خصوصی نیمی از صف شوند، مسیر ابری رایگان حذف میشود. با این گیت مذاکره نکنید.
استراتژیهای خروج عملیاتی
برای جلوگیری از سندرم «ویکیهای قدیمی»، چارچوب برای هر مجوز AI یک مالک نامبرده میخواهد. یک کانال اسلک مالک نیست؛ بلکه باید یک مدیر مهندسی مشخص در تیکت ذکر شود. این مالک مسئول آرشیو کردن یادداشت مسیریابی است به محض اینکه:
- سهم خصوصی از خط تعریفشده عبور کند.
- صفحه مجوزها تغییر کند.
- بازبینها برای دو هفته هدف زمانی H را از دست بدهند.
اگر مالک تیم را ترک کند، فرضهای مربوط به آن مجوز در همان روز منقضی میشود. این رویکرد، ادغام AI را به جای یک تغییر زیرساختی دائمی، به عنوان یک مجوز موقت میبیند. با اجرای هر دو حالت «جذاب» (عمومی) و «سختگیرانه» (خصوصی) از طریق یک کاربرگ گیت نظارتی، تیمها میتوانند از تله تصمیمگیری بر اساس آرزوها نجات یابند.
چه کسانی باید از این مسیر بروند؟
برخی تیمها باید کلاً این چارچوب را نادیده بگیرند. اگر به دنبال مقایسه کیفیت مدلها (Bake-off) یا امتیازات کیفی هستید، این ابزار برای شما نیست. من امتیازات کیفی را برای پر کردن این خلاء ابداع نخواهم کرد. اگر بخش حقوقی هنوز شرایط پردازش دادهها را باز نکرده، یک جدول جایگزینی برای قرارداد DPA نیست.
اگر قصد دارید از یک سرور رایگان به عنوان وابستگی دائمی تولید استفاده کنید، بدانید که در برگه معرفی تنها یک «گزینه» ذکر شده است، نه مدت زمان، اندازه ماشین یا SLA. من این سکوت را تزیین نخواهم کرد. در نهایت، از قرار دادن عاملها (Agents) در سیستمهای شخص ثالث «فقط برای تست» پرهیز کنید. گفتگوهای اوایل اکتبر شامل گزارشهایی درباره عاملها و اهداف شرکتهای واقعی بود، اما دسترسی به ابزار یک مجوز است و مجوزهای بدون مالک در یک پایلوت مشارکت جایی ندارند.
اگر میدانید ساعات بررسی گلوگاه است، توکنها — حتی ۱۰۰ میلیون عدد — این حقیقت را نمیپوشانند. رهبران مهندسی باید اکنون مسیرهای AI خود را با محاسبه مصرف واقعی توکن در هر تغییر (T) و مقایسه آن با ظرفیت بازبین انسانی (R) پیش از موج بعدی مشارکتها حسابرسی کنند. کدام متغیر در صورت تغییر، تصمیم شما را عوض میکند: نظارت، ساعات بررسی یا مجوزی که امروز دوباره خواندید؟
گام بعدی شما
- محاسبه مقدار T (توکن مصرفی هر تغییر) بر اساس لاگهای واقعی مخزن خود به جای اعداد تبلیغاتی.
- استخراج تعداد ادغامهای سال گذشته در بازه زمانی مشابه برای تعیین خط پایه A (حجم هفتگی).
- تعیین یک مالک نامبرده برای هر ابزار AI در تیکتهای مهندسی جهت نظارت بر تغییرات لایسنس و دسترسی.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.




گفتگو