اگر امروز به تیک سبز در خط لوله CI خود اعتماد میکنید، احتمالاً بخشی از کدهای شما هرگز واقعاً اجرا نشدهاند. طبق گزارشی که در ۱۹ سپتامبر ۲۰۲۶ در dev.to منتشر شد، یک دیدگاه مهندسی ارشد روندی خطرناک را برجسته میکند: درخواستهای ادغام (PR) که تمام تستهای موجود را پاس میکنند، اما منطقی را ارسال میکنند که هیچ تستی در واقعیت آن را اجرا نکرده است. این موضوع در واقع تداوم بحثی است که پیشتر در مورد عدم تضمین صحت کد توسط تستهای سبز در عاملهای هوش مصنوعی مطرح شده بود.
تصور کنید در یک تیم، ۹ مورد از ۱۲ درخواست ادغام اخیر که توسط هوش مصنوعی تغییر یافتهاند، سبز هستند. در ظاهر، این یک موفقیت است. اما اگر ۲ مورد از آنها مسیرهایی را ارسال کرده باشند که هیچ تستی آنها را اجرا نکرده، این نسبت میتواند تصمیمات بودجهای شما را سریعتر از هر صورتحسابی برای توکنها تغییر دهد. این یک داستان تخیلی یا یک مورد تکگیر نیست، بلکه تحلیل ترکیبی از چندین تیم مهندسی است. حتی اگر اعداد در تیم شما متفاوت باشد، منطق این تحلیل همچنان کاربرد دارد.
این پدیده که «کاذب-تکمیلشده» (False-Done) نامیده میشود، زمانی رخ میدهد که هوش مصنوعی یک مسیر جدید از کد تولید میکند که کامپایلر و مجموعههای تست موجود را راضی میکند، اما از نظر عملکردی تأیید نشده است. این یک شکاف در شواهد است، نه یک مشکل در وضعیت گیت (Git). تصور کنید مالک یک سرویس، یک Diff را میبیند که کامل به نظر میرسد و CI سبز است. بازبین تنها یک سوال میپرسد: «کدام تست به این شاخه جدید میرسد؟» سکوتی حکمفرما میشود. سپس یک کامیت اصلاحی میآید و بعد یکی دیگر. PR اصلی از نظر گیت ناقص نبود، بلکه از نظر شواهد ناقص بود. این چالش نشان میدهد که چگونه تستهای داخلی مخزن کد میتوانند مانعی ناکارآمد برای اعتبارسنجی وصلههای AI باشند.
برای بسیاری از تیمها، این وضعیت یک بدهی پنهان ایجاد میکند؛ جایی که نرخ خروجی (Throughput) بالا به نظر میرسد و نظرات بازبینها مودبانه است، اما تیم همچنان نمیتواند ادعای عملکرد کد را بدون حضور نویسنده در اتاق بازتولید کند. اکثر تیمها هنگام تهیه ابزارهای AI، بر سر مسیرهای رایگان در مقابل پولی یا زیرساختهای میزبانی شخصی (Self-hosted) بحث میکنند. آنها این تصمیم را به عنوان یک مشکل ظرفیت یا هزینه میبینند. اما مشکل واقعی، حاکمیت (Governance) است. خرید یک مسیر گرانتر و ایزوله، نبودِ تست را حل نمیکند؛ بلکه صرفاً تولید کدهای «کاذب-تکمیلشده» را ارزانتر و سریعتر میکند.
چارچوب دروازه کاذب-تکمیلشده
برای مقابله با این وضعیت، نویسنده یک کارت امتیاز (Scorecard) خاص پیشنهاد میدهد تا تیمها تعیین کنند آیا باید مسیر رایگان AI را حفظ کنند، جریان کاری خود را تقسیم کنند، تولید کد را کاملاً متوقف کنند یا تصمیم را به تعویق بیندازند. این یک ابزار گفتگو است که طراحی شده تا تیمها را از «حس و حال» (Vibes) به «متغیرها» منتقل کند. نویسنده از امتیازدهی به مسیری که مفاهیم آن تعریف نشدهاند خودداری میکند؛ این متغیرها باید ابتدا در ویکی تیم نوشته شوند.
این چارچوب بر اساس چندین معیار کلیدی است که در یک بازه نمونه ۱۴ روزه اندازهگیری میشوند. بازههای کوتاهتر دروغ میگویند و بازههای بلندتر، آتش را پنهان میکنند:
- نرخ کاذب-تکمیلشده (FDR): سهم PRهای تغییریافته توسط AI در نمونه که ادغام شدند یا آماده علامتگذاری شدند، اما سپس به دلیل اینکه یک مسیر تولیدشده تست نشده، غیرقابل بازتولید یا توضیحناپذیر بود، نیاز به کامیتهای اصلاحی داشتند. در اینجا تعداد PRها شمرده میشود، نه تعداد کامیتهای پراکنده.
- تأخیر شواهد (EL): تعداد ساعتهایی که از لحظه «به نظر تکمیلشده» تا زمانی که یک مالک نامبرده بتواند ادعای کد را بدون حضور نویسنده بازتولید کند، میگذرد. اگر مالک به عنوان «تیم» تعریف شود، EL بینهایت در نظر گرفته میشود.
- محدودیت (Boundedness): سهم شاخهها، هندلرها یا جابهای تولیدشده که واقعاً توسط یک تست، یک بازتولید دستی ثبتشده یا یک Fixture شکستخورده لمس شدهاند.
- نیاز به ایزولاسیون (I): یک بررسی دوگانه (Binary) برای سطح دسترسی: آیا سیاستهای سازمان، ارسال پرامپتها، کدها یا خروجی ابزار را روی یک سرور رایگان مشترک ممنوع میکند؟ اگر بله، گزینه «حفظ» (Keep) از همین ابتدا غیرقانونی است.
- هزینه جابهجایی (SC): ساعتهای مورد نیاز برای راهاندازی یک مسیر ایزوله (توسط فروشنده یا میزبانی شخصی) و انتقال قالب شواهد به همراه آن. این مورد شامل گشتوگذار در کاتالوگ فروشندگان نیست، اما شامل بازبینی، مدیریت Secrets و یادداشتهای بازگشت (Rollback) میشود. در این راستا، باید به ضعف مدلهای زبانی در تولید اسکریپتهای بازگشتی کد توجه داشت تا ریسکهای مربوط به Rollback به درستی ارزیابی شوند.
اعمال دروازهها
تصمیمگیری طبق یک سلسلهمراتب سختگیرانه است. نویسنده هشدار میدهد که از میانگینگیری فیلدها اجتناب کنید؛ ترتیب خواندن دروازهها قطعی است.
دروازه ایزولاسیون: اگر نیاز به ایزولاسیون (I) درست باشد، حفظ مسیر رایگان ممنوع است. تیم باید بین «تقسیم» (Split) یا «خروج» (Exit) یکی را انتخاب کند. تیمها نباید از امتیازدهی FDR به عنوان راهی برای دور زدن سیاستهای امنیتی و ایجاد استثنا استفاده کنند.
دروازه FDR: اگر FDR بالاتر از حد مجاز (مثلاً ۲۰٪) باشد، تیم مشکل ظرفیت ندارد، بلکه مشکل شواهد دارد. پاسخ این است که تولید کد در آن سطح متوقف شود (Exit)، یا جریان کاری تقسیم شود (Split) تا کارهای نامنظم نتوانند در همان صفِ کدهای تولیدی (Production) پنهان شوند.
دروازه محدودیت و تأخیر: اگر محدودیت (B) زیر کف (مثلاً ۷۰٪) باشد یا تأخیر شواهد (EL) از سقف (مثلاً ۸ ساعت) فراتر رود، تیم تنها در صورتی میتواند مسیر را حفظ کند که مالک بتواند یک برنامه اصلاحی دو هفتهای نام ببرد. در غیر این صورت، تصمیم به حالت «متوقف» (Parked) با یک تاریخ انقضای سختگیرانه میرود.
دروازه هزینه جابهجایی: خرید یا میزبانی شخصی تنها زمانی انجام شود که دروازههای ۱ تا ۳ پیش از آن ایزولاسیون را demanded کرده باشند و هزینه جابهجایی (SC) کمتر از بدهی شواهدی باشد که در حال حاضر پرداخت میشود.
محاسبه بدهی شواهد
برای توجیه هزینه انتقال به یک مسیر پولی یا میزبانی شخصی، تیمها باید «بدهی شواهد» خود را محاسبه کنند. این مقدار تقریباً برابر است با: تعداد PRهای کاذب-تکمیلشده * (ساعات EL + ساعات بازبینی مجدد).
یک مثال عملی را در نظر بگیرید: تیمی در بخش payments-webhooks با یک بازه ۱۴ روزه و ۱۲ PR تغییریافته توسط AI. دو مورد از آنها کاذب-تکمیلشده هستند که منجر به FDR ۱۶.۷٪ میشود. مقدار p50 تأخیر شواهد ۶ ساعت و محدودیت ۷۵٪ است. نیاز به ایزولاسیون وجود ندارد (False). هزینه جابهجایی به یک مسیر ایزوله ۱۶ ساعت است و بازبینی مجدد برای هر PR کاذب-تکمیلشده تقریباً ۳ ساعت زمان میبرد.
بدهی شواهد در این بازه برابر است با: 2 * (6 + 3) = 18 hours. در حالی که هزینه جابهجایی (۱۶ ساعت) به این عدد نزدیک است، اما نتیجه همچنان «حفظ» (Keep) است، زیرا نیاز به ایزولاسیون وجود ندارد، FDR زیر ۲۰٪ است، تأخیر زیر ۸ ساعت است و محدودیت بالای ۷۰٪ است. مهاجرت ۱۶ ساعته در اینجا فقط یک «حس خوب» میخرد، نه یک دروازه فنی.
اما اگر تنها یک فیلد تغییر کند، نتیجه فوراً عوض میشود. اگر نیاز به ایزولاسیون به دلیل اینکه Payloadهای وبهوک شامل شناسههای مشتری هستند (که نباید روی سرور رایگان مشترک باشند) مثبت شود، نتیجه در همان بعدازظهر به «تقسیم» (Split) تغییر میکند. اگر ایزولاسیون همچنان False بماند اما PRهای کاذب-تکمیلشده به ۴ مورد از ۱۲ برسد (FDR = ۳۳٪)، بدهی شواهد به ۳۶ ساعت میپرد و تیم باید تولید کد در آن سطح را متوقف کند تا محدودیت (Boundedness) بهبود یابد.
عملیاتی کردن فرآیند
برای اینکه این مدل کار کند، تیمها باید PRهای تغییریافته توسط AI را در توضیحات یا برچسبها مشخص کنند. بدون داشتن مخرج کسر، FDR قابل محاسبه نیست. این یک باگ فرآیندی است، نه یک باگ مدل. نویسنده پیشنهاد میکند از GitHub CLI برای لیست کردن PRهای ادغامشده با برچسبهای خاص استفاده شود تا به حافظه یا داشبوردهای ناقص تکیه نکنید:
gh pr list --state merged --search "label:ai-touched merged:>=2026-09-05" --json number,title,mergedAt,url,labels > /tmp/ai-prs.json
کامیتهای اصلاحی روی همان مسیرها در بازه ۷۲ ساعت اول، اغلب سیگنالی از کد کاذب-تکمیلشده هستند. این یک روش اکتشافی (Heuristic) است؛ اما کار اصلی در طبقهبندی دستی PRها باقی میماند. اگر تیمی از طبقهبندی دستی PRها برای دو هفته امتناع ورزد، نباید اجازه داشته باشد از یک مسیر رایگان در محیطی با شعاع اثر (Blast Radius) تولیدی استفاده کند.
علاوه بر این، خودِ قالب PR باید تغییر کند تا محدودیت (Boundedness) قابل مشاهده باشد. هر PR تغییریافته توسط AI باید شامل یک چکلیست باشد که موارد زیر را در بر گیرد:
- لیست مسیرهای تولیدشده: (نام فایل + تابع / نام جاب).
- تأییدیه: تست یا Fixture ای که هر مسیر را لمس میکند، یا یک بازتولید ثبتشده.
- مالکیت: یک مالک نامبرده که بتواند بدون حضور نویسنده، آن ادعا را مجدداً اجرا کند.
- ایزولاسیون: دادهها یا Secrets موجود در پرامپت (هیچکدام | سانسور شده | مسدود شده).
- پیگیری: آیا PR اصلاحی مورد انتظار است (خیر | بله، شناسه تیکت).
اگر چکلیست خالی است اما CI سبز است، شما با یک کاندیدای «کاذب-تکمیلشده» روبرو هستید. سبز بودن به معنای تکمیل شدن نیست؛ سبز بودن صرفاً به این معناست که تستهایی که از قبل داشتید، فریاد نزدند.
ریسکهای خود-ارزیابی و محدودیتها
این رویکرد برای همه مناسب نیست. در مخازن تفننی دو نفره که نویسنده و بازبین یک نفر هستند، این مدل شکست میخورد زیرا FDR به «خود-ارزیابی» تبدیل میشود. همچنین نمیتوان از این مدل برای «پولشویی» استثنائات سیاستی استفاده کرد؛ اگر بخش حقوقی خروج کد از مرز سازمان را ممنوع کرده است، هیچ مقدار پایینی از FDR نمیتواند استفاده از یک مسیر رایگان مشترک را توجیه کند.
محدودیتهای آشکاری در این مدل وجود دارد. FDR به شدت به سختگیری در طبقهبندی کامیتهای اصلاحی وابسته است. برای جلوگیری از اختلاف نظر، تیمها باید یک قانون سختگیرانه بنویسند: یک مسیر لمسنشده، یک ادعای غیرقابل بازتولید یا نبود مالک، به معنای «کاذب-تکمیلشده» است، نه اینکه صرفاً سبک کدنویسی مورد پسند نباشد. علاوه بر این، یک بازه ۱۴ روزه ممکن است سطوح نادر کد را نادیده بگیرد، در حالی که بازه ۹۰ روزه میتواند یک هفته بد را زیر سایه یک ماه خوب پنهان کند. اگر شعاع اثر بالا است، حلقه تصمیمگیری را کوتاه کنید.
چه زمانی مسیر رایگان همچنان پذیرفته است؟
برخی تیمها به یک مسیر آزمایشی (Scratch Lane) نیاز دارند تا پیش از پرداخت هزینه برای ایزولاسیون، FDR را اندازهگیری کنند. این یک وظیفه واقعی است، نه یک ترجیح برند. برای مثال، MonkeyCode یک ابزار کدنویسی متنباز با دسترسی رایگان به مدل و گزینه سرور رایگان ارائه میدهد. اینها واقعیتهای مربوط به در دسترس بودن هستند. اگر یک سرور رایگان مشترک نتواند پرامپتهای شما را نگه دارد، نیاز به ایزولاسیون از پیش True است و محصول دیگر حق رأی ندارد.
از مسیر رایگان تنها در صورتی استفاده کنید که:
۱. نیاز به ایزولاسیون برای آن سطح از کد False باشد.
۲. PRهای تغییریافته توسط AI را برچسبگذاری کنید و بازه ۱۴ روزه را اجرا کنید.
۳. مالک اختیار داشته باشد که تصمیم «حفظ» (Keep) را رد کند.
۴. کارهای آزمایشی و کارهای تولیدی در یک صف نباشند.
حاکمیت نهایی: مالک، انقضا و خروج
این فرآیند باید بر سه ستون استوار باشد:
- مالک: یک مدیر مهندسی یا لید پلتفرم برای آن سطح از کد. «قهرمانان AI» نمیتوانند مالک باشند زیرا قهرمانان معمولاً دسترسیها را لغو نمیکنند.
- انقضا: یک محدودیت ۲۸ روزه که در فایل YAML نوشته شده است. اگر کارت دوباره امتیازدهی نشود، مسیر به حالت «متوقف» (Park) میرود. حالت Park، همان حالت Keep با نور کم نیست؛ بلکه یک توقف است.
- خروج: فعال میشود توسط هر بازه تکمیلشدهای که FDR آن بالای حد مجاز باشد، EL برای دو بازه متوالی بالای سقف باشد، یا نیاز به ایزولاسیون به True تغییر کند. خروج یعنی تولید کد در آن سطح متوقف میشود تا زمانی که محدودیت (Boundedness) بهبود یابد.
در نهایت، هدف این است که خرید ابزارهای AI را از یک مسابقه زیبایی بین وزنهای مدل یا جداول تأخیر (Latency) خارج کنیم. اگر سوال شما این است که «کدام وزنها این هفته داغتر هستند»، شما در جلسه اشتباهی هستید. تنها سوالی که اهمیت دارد این است: کدام تکفیلد در این کارت، اگر این هفته تغییر کند، تصمیم ما برای حفظ مسیر فعلی را میکشد؟
اگر تیمی نمیتواند نام ببرد که این فیلد FDR است، تأخیر شواهد است، محدودیت است یا نیاز به ایزولاسیون، آنها در حال اتخاذ یک تصمیم فنی نیستند؛ بلکه امیدوارند که یک بیلد سبز به معنای تکمیل واقعی کد باشد. اما احتمالاً اینطور نیست.
گفتگو