آیا تاییدیه های متوالی در کدنویسی AI نشانه کیفیت است؟

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

این چالش زمانی رخ می‌دهد که تیم‌ها برای مدیریت وصله‌های سبک MonkeyCode به گیت‌های خودکار متکی می‌شوند. اکثر این سیستم‌ها از سه لایه تشکیل شده‌اند: بررسی ویژگی‌ها (Property Checks) برای تضمین قوانین ثابت که باید روی هر ورودی برقرار باشند، فیکسرهای پین‌شده (Pinned Fixtures) برای بازسازی دقیق محیط عملیاتی، و انجماد تست‌های ناپایدار (Flaky-test Freeze) برای حذف نویزهای ناشی از شکست‌های غیرقطعی. این لایه‌ها اگرچه جریان تحویل کد را روان می‌کنند، اما با تایید هر چیزی که «تقریباً درست» به نظر می‌رسد، حس امنیت کاذبی ایجاد می‌کنند. این وضعیت در واقع تکرار همان خطای ساختاری است که در بررسی شکست حفاظ‌های امنیتی در عامل‌های هوش مصنوعی به آن پرداختیم، جایی که ثبت رضایت جایگزین بررسی دقیق شواهد می‌شود.

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

ممیزی جهش (Mutation Audit) — شبیه به این است که برای تست کردن یک سیستم دزدگیر، عمداً کسی را برای ورود غیرقانونی استخدام کنید تا ببینید آیا واقعاً زنگ هشدار به صدا در می‌آید یا خیر — با تبدیل خودِ گیت بازبینی به موضوع تست، این مشکل را حل می‌کند. در این روش، یک وصله که قبلاً تایید شده انتخاب می‌شود و دقیقاً یک نقص معنایی یا «جهش‌یافته» (Mutant) به آن تزریق می‌گردد تا مشخص شود آیا گیت بازبینی اکنون آن را رد می‌کند یا خیر. اگر جهش‌یافته تایید شود، شما یک نقطه کور واقعی در مجموعه تست‌های خود یافته‌اید و این نقطه کور، ارزش بسیار بیشتری نسبت به آن تیک سبز اولیه دارد. این رویکرد در واقع پاسخی به پدیده رانش خاموش مدل‌های AI است که می‌تواند به مرور زمان نرخ تشخیص باگ را بدون هیچ هشدار بیرونی کاهش دهد.

به نقل از یک راهنمای فنی منتشر شده در ۲۸ اوت ۲۰۲۶، این ممیزی از یک گردش‌کار شش‌مرحله‌ای سخت‌گیرانه پیروی می‌کند:

• جمع‌آوری وصله‌ها: انتخاب مجموعه‌ای از وصله‌های پذیرفته‌شده بر اساس یک برش زمانی (Chronological Slice)، نه نمونه‌های گلچین‌شده و برجسته.
• تعریف کلاس‌ها: تعریف انواع جهش‌ها بر اساس تاریخچه باگ‌های واقعی تیم، زیرا نقص‌های کتابخانه‌ای و تئوریک معمولاً همان مواردی هستند که تست‌های شما از قبل آن‌ها را می‌گیرند.
• تک‌جهش: در هر اجرا، تنها یک جهش در یک فایل اعمال می‌شود؛ هرگز دو جهش را در یک اجرای واحد ترکیب نکنید تا متغیرها کنترل شوند.
• اجرای گیت واقعی: استفاده از همان گیت عملیاتی روی درخت کاری (Worktree) جهش‌یافته، نه یک نسخه ساده‌شده یا شبیه‌ساز (Mock).
• فیلتر کدهای مرده: حذف جهش‌هایی که باعث خطای کامپایل می‌شوند (Compile-dead)، زیرا این‌ها هرگز به مرحله تصمیم‌گیری گیت نمی‌رسند و نباید در مخرج کسر محاسبه نرخ قرار گیرند.
• محاسبه نرخ: تقسیم تعداد جهش‌های ردشده بر جهش‌های زنده برای به دست آوردن نرخ تشخیص واقعی. این روش با تکیه بر احکام واقعی به جای انتظارات، صداقت نتایج را تضمین می‌کند.

برای پیاده‌سازی این فرآیند به گونه‌ای که صادقانه و قابل بازبینی باشد، می‌توان کل ممیزی را در یک فایل واحد به نام mutant_audit.py نگه داشت. این اسکریپت یک دایرکتوری از کدهای پذیرفته‌شده را می‌خواند، یک کلاس جهش را به صورت قطعی (Deterministic) از یک Seed انتخاب می‌کند، یک تغییر متنی در یک فایل اعمال می‌کند، نتیجه را کامپایل کرده و سپس از گیت پیکربندی‌شده درخواست رای می‌کند.

#!/usr/bin/env python3
# mutant_audit.py - one mutation per patch, then count gate rejections.
import argparse
import py_compile
import random
import subprocess
import tempfile
from pathlib import Path

MUTATIONS = {
    'off_by_one': [('retries = 3', 'retries = 4'), ('retries = 3', 'retries = 2')],
    'sign_flip': [('shipping_cost = -', 'shipping_cost = +')],
    'comparison': [('status == COMMITTED', 'status != COMMITTED'), ('status == REFUNDED', 'status != REFUNDED')],
    'guard_removed': [('if not order.is_paid():\n', '')],
    'logic_swap': [('discount > 0.1', 'discount > 0.5')],
}

def apply_mutation(lines, cls):
    for i, line in enumerate(lines):
        for old, new in MUTATIONS[cls]:
            if old in line:
                lines[i] = line.replace(old, new, 1)
                return lines, '{!r} -> {!r}'.format(old, new)
    return None, None

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument('pool_dir')
    parser.add_argument('--gate', default='./gate.py')
    parser.add_argument('--seed', type=int, default=20260828)
    args = parser.parse_args()
    rng = random.Random(args.seed)
    rows = []
    for path in sorted(Path(args.pool_dir).glob('*.py')):
        cls = rng.choice(list(MUTATIONS))
        lines = path.read_text().splitlines(keepends=True)
        mutant, _ = apply_mutation(lines, cls)
        if mutant is None:
            continue
        with tempfile.TemporaryDirectory() as tmp:
            worktree = Path(tmp) / 'review'
            worktree.mkdir()
            (worktree / path.name).write_text(''.join(mutant))
            try:
                py_compile.compile(str(worktree / path.name), doraise=True)
                dead = False
            except py_compile.PyCompileError:
                dead = True
            result = subprocess.run(args.gate, shell=True, cwd=worktree, capture_output=True)
            accepted = result.returncode == 0
            rows.append((cls, dead, not accepted))
    header = '{:<14}{:>6}{:>10}{:>8}'.format('class', 'live', 'rejected', 'rate')
    print(header)
    for cls in MUTATIONS:
        live = [r for r in rows if r[0] == cls and not r[1]]
        rejected = [r for r in live if r[2]]
        rate = 100 * len(rejected) / len(live) if live else 0.0
        row = '{:<14}{:>6}{:>10}{:>7.0f}%'.format(cls, len(live), len(rejected), rate)
        print(row)

if __name__ == '__main__':
    main()

این اسکریپت با یک دایرکتوری استخر (Pool) و یک دستور گیت اجرا می‌شود. گیت باید قادر باشد در درخت کاری موقتی که توسط اسکریپت ایجاد شده است، عمل کند. برای مثال:

`python mutant_audit.py accepted_pool/ --gate "./gate.py --branch review"

طبق گزارش نتایج یک اجرای نمونه روی ۵۲ وصله مصنوعی، نرخ تشخیص کلی تنها ۵۴٪ بود؛ یعنی از ۵۰ جهش زنده، فقط ۲۷ مورد شناسایی شدند. در اینجا میانگین تقریباً بی‌فایده است؛ ستون حداقل‌هاست که پیام واقعی را منتقل می‌کند. داده‌ها نشان‌دهنده واریانس شدید در کلاس‌های مختلف نقص بودند:

• تغییر علامت (Sign Flips): تشخیص ۱۰۰٪ (۹ از ۹). این موارد کاملاً پوشش داده شده بودند زیرا بررسی ویژگی‌ها، مجموع دقیق هزینه ارسال را تایید می‌کند.
• خطای یک واحدی (Off-by-One): تشخیص ۷۳٪ (۸ از ۱۱).
• خطاهای مقایسه‌ای: تشخیص ۳۸٪ (۵ از ۱۳). این کلاس ضعیف است زیرا فیکسرهای پین‌شده همیشه تنها یک مقدار وضعیت تولید می‌کنند و مجموعه تست‌های منجمد شده نمی‌توانند جای خالی شاخه‌های مفقود را پر کنند.
• حذف گاردها (Removed Guards): تشخیص ۲۵٪ (۲ از ۸). این نقص‌ها به دلیل اینکه هیچ تستی مسیر سفارش‌های پرداخت‌نشده را لمس نمی‌کند، به راحتی عبور می‌کنند.
• جابجایی منطقی: تشخیص ۳۳٪ (۳ از ۹).

این اعداد مستقیماً به سرمایه‌گذاری‌های فنی تبدیل می‌شوند. نرخ ۲۵ درصدی در حذف گاردها یعنی تیم باید فوراً یک فیکسر برای سفارش‌های پرداخت‌نشده اضافه کند. نرخ ضعیف مقایسه‌ای مستلزم افزودن یک Seed وضعیت دوم برای کلاس مقایسه است و شکست در جابجایی منطقی، نیاز به یک اینورینت (Invariant) دقیق برای تخفیف‌ها دارد.

در مورد ادغام با MonkeyCode، ابزارهای این پلتفرم می‌توانند این حلقه را تقویت کنند. مدل‌های رایگان آن‌ها می‌توانند نقاط کاندید برای جهش را از استخر وصله‌های پذیرفته‌شده پیشنهاد دهند، زیرا یک مدل می‌تواند کل فایل را بخواند، نه فقط خلاصه تغییرات (Diff). برای حفظ دقت، یک انسان باید هر کاندید را قبل از ورود به ممیزی تایید کند تا مطمئن شود پیشنهاد داده شده یک جهش واقعی است و نه یک خطای کامپایل در لباس جهش.

برای تیم‌هایی با حجم کاری بالا، در صورتی که صف اجرای محلی اشباع شود، اجرای هفتگی کالیبراسیون می‌تواند به گزینه سرور رایگان MonkeyCode منتقل شود. این‌ها جزئیات دسترسی از مستندات اپراتور هستند؛ خودِ ممیزی مستقل باقی می‌ماند و اسکریپت روی هر گیت موجودی اجرا می‌شود.

برای تبدیل این ممیزی‌های مقطعی که سریعاً قدیمی می‌شوند به یک سیستم نظارتی دائمی، پیشنهاد می‌شود ضعیف‌ترین ردیف‌های نتایج به «نگهبان» (Sentinel) تبدیل شوند. یک نگهبان، یک فایل .diff ثبت‌شده در دایرکتوری canaries/ است که حاوی یک جهش شناخته‌شده است و خط لوله بازبینی باید آن را رد کند، پیش از آنکه اجازه بررسی هر وصله واقعی را داشته باشد. این استراتژی در واقع پیاده‌سازی عملی گیت‌های کیفی قطعی است که برای توقف پس‌روندهای فنی در عامل‌های هوش مصنوعی ضروری هستند.

#!/usr/bin/env bash
# sentinel.sh - prove the gate can reject before anything real is reviewed
set -euo pipefail
for diff_file in canaries/*.diff; do
    git apply "$diff_file"
    if ./gate.py --patch HEAD >/dev/null 2>&1; then
        git apply -R "$diff_file"
        echo "sentinel accepted: $diff_file - blocking the pipeline" >&2
        exit 1
    fi
    git apply -R "$diff_file"
done
echo "sentinel check passed: gate rejects every known mutant class"

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

البته برای حفظ صداقت ممیزی، چندین نکته و محدودیت باید در نظر گرفته شود:

• سوگیری منو (Menu Bias): نرخ تشخیص توصیف‌کننده «منوی جهش‌های شما» است، نه لزوماً توزیع واقعی باگ‌ها. باگ‌های واقعی ممکن است از منویی بیایند که شما ننوشته‌اید.
• اندازه نمونه: در این حجم از استخر، مخرج کسر هر کلاس کوچک است. کمترین ردیف را به عنوان یک راهنمای قوی در نظر بگیرید، نه یک رقم دقیق.
• جهش متنی: اسکریپت در سطح متن جهش ایجاد می‌کند؛ برخی جایگزینی‌ها ممکن است متفاوت از یک باگ انسانی در همان خط رفتار کنند.
• انحراف محیطی (Environment Drift): گیت روی یک درخت کاری موقت اجرا می‌شود. انحراف پیکربندی محیط عملیاتی می‌تواند نقص‌هایی را پنهان کند که ممیزی در حالت عادی آن‌ها را آشکار می‌کرد.

این رویکرد برای هر تیمی مناسب نیست. اگر فرآیند بازبینی کاملاً انسانی است، گیت اسکریپت‌شده‌ای برای ممیزی وجود ندارد. به طور مشابه، اگر استخر وصله‌های پذیرفته‌شده کمتر از ۲۰ مورد باشد، مخرج کسر هر کلاس تبدیل به نویز می‌شود و صادقانه‌ترین یافته، خودِ اندازه کوچک نمونه است.

برای کسانی که گیت‌های ابتدایی (فقط شامل کامپایل و تست‌های واحد) دارند، توصیه می‌شود ممیزی را یک بار برای تایید موارد بدیهی اجرا کنند و سپس اولویت را بر ساخت لایه بررسی ویژگی‌ها (Property Layer) قرار دهند.

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

گام بعدی شما

• لیست باگ‌های ۶ ماه اخیر تیم خود را استخراج کرده و کلاس‌های جهش (Mutant Classes) اختصاصی خود را تعریف کنید.
• اسکریپت ممیزی را روی آخرین ۱۰ وصله تایید شده اجرا کنید تا نقاط کور فعلی گیت بازبینی را بیابید.
• برای هر کلاس جهشی که نرخ تشخیص زیر ۵۰٪ دارد، یک فایل Sentinel ایجاد کنید تا از تکرار این نقص در آینده جلوگیری شود.

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