جلوگیری از توهمات کدنویسی با متدولوژی «تست قرمز اول

احتمالاً همین حالا در حال تأیید کدهایی هستید که توسط هوش مصنوعی تولید شده‌اند اما نمی‌توانید منطق آن‌ها را به‌طور کامل توضیح دهید. این وضعیت که «تئاتر بازبینی» (Review Theater) نامیده می‌شود، زمانی رخ می‌دهد که عامل‌ها (Agents) — شبیه دستیارهای پرسرعتی که بدون فکر کردن، کوهی از کاغذ را پر می‌کنند — تغییراتی (diffs) را با سرعتی ارائه می‌دهند که نقشه‌های ذهنی انسان را مختل می‌کند. این مسئله به‌ویژه برای مهندسان تازه‌کار در اولین هفته استقرار (onboarding) بحرانی است؛ وقتی شما به مخزنی می‌پیوندید که تقریباً هیچ نقشه ذهنی از آن ندارید، هنوز قادر نیستید یک وصله (patch) گسترده تولید شده توسط هوش مصنوعی را به‌درستی قضاوت کنید. کد «محتمل» یا باورپذیر، همچنان می‌تواند در لایه‌ای اشتباه شکست بخورد.

طبق گزارشی که در ۱۷ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، یک راهنمای عملی برای توقف این فرسایش قضاوت، گردش‌کار «تست قرمز اول» (Red Test First) را معرفی کرده است. فرض اصلی این است که یک عامل تنها زمانی باید به دنبال «سبز شدن» (پاس کردن تست) باشد که یک انسان ابتدا «قرارداد شکست» را تعریف کرده باشد. در این مدل، شما مالک هر تست شکست‌خورده‌ای در اولین درخواست تغییر (PR) هستید. این سد دفاعی از مهندسان تازه‌کار در هفته اول استقرار محافظت کرده و حجم تغییرات تولید شده را به اندازه‌ای کوچک نگه می‌دارد که بازبینی آن‌ها ممکن باشد.

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

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

مدل ذهنی پیش از تست

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

پیش از نوشتن تست، این چهار پرسش را در یک یادداشت پیش‌نویس پاسخ دهید:

• چه ورودی‌هایی در روز اول مجاز هستند؟
• چه خروجی‌هایی نباید در آینده تغییر کنند؟
• کدام فایل در حال حاضر مالک این رفتار است؟
• کدام فایل باید در این هفته دست‌نخورده باقی بماند؟

توالی پنج‌مرحله‌ای «قرمز-اول»

برای اجرای این متدولوژی، یک ترتیب عملیاتی سخت‌گیرانه پیشنهاد شده است که برای صرفه‌جویی در زمان نباید تغییر کند:

۱. تأیید خط پایه (Baseline Verification): مخزن را کلون کرده و مجموعه تست‌های مستند شده (مانند npm test یا pytest یا go test ./...) را اجرا کنید. از یک شاخه تمیز استفاده کنید: git checkout -B week1/red-first origin/main. اگر تست‌ها در شاخه اصلی (main) قرمز هستند، فوراً متوقف شوید؛ نباید نویزِ عامل را به یک خط پایه خراب اضافه کنید.

۲. تست قرمز دستی (Manual Red Test): یک تست شکست‌خورده کوتاه و قطعی را با کلمات خودتان بنویسید. این فایل را از طریق یک پرامپت کلی تولید نکنید. برای مثال در یک سیستم تخفیف، یک قالب تست به این شکل خواهد بود:

# tests/test_welcome_discount.py
def test_welcome_discount_applies_once_per_account():
    account = {"id": "acct_1", "orders": []}
    first = apply_welcome_discount(account, amount=40)
    second = apply_welcome_discount(account, amount=40)
    assert first == 36
    assert second == 40

این «تست قرمز» را با یک پیام واضح (مثلاً test: red welcome discount applies once) در یک شاخه شخصی کامیت کنید، پیش از آنکه هرگونه فایل تولیدی (production) ویرایش شود. این کامیت به عنوان یک قرارداد عمومی از نیت شما عمل می‌کند.

۳. انجماد مسیرها (Path Freezing): از لیست‌های مجاز (allowlists) برای محدود کردن عامل استفاده کنید. عامل باید فقط به فایل‌های تولیدی خاص (مثلاً src/pricing/welcome_discount.py) از طریق یک فایل agent-allow.txt دسترسی داشته باشد. همچنین باید دسترسی آن به پوشه تست‌ها، فایل‌های package-lock.json یا yarn.lock و مسیر .github/workflows/ از طریق یک فایل agent-deny.txt به‌طور سخت‌گیرانه مسدود شود. این کار مانع از آن می‌شود که عامل برای پاس کردن تست، خودِ تست را تغییر دهد تا با پیاده‌سازی راحت (اما غلط) خود سازگار شود.

۴. محافظت از Diff (Diff Guarding): از یک اسکریپت محلی استفاده کنید تا مطمئن شوید هیچ مسیر محافظت‌شده‌ای تغییر نکرده است. این راهنما یک اسکریپت بش (scripts/check-agent-diff.sh) ارائه می‌دهد که با استفاده از git diff --name-only و یک عبارت منظم (regex)، اگر هر مسیری در لیست deny_re ویرایش شده باشد (به جز فایل RED_TEST خاص)، عملیات را متوقف می‌کند. این یک کمربند ایمنی است تا مطمئن شوید عامل به‌طور پنهانی یک lockfile یا گردش‌کار CI را دستکاری نکرده است.

۵. پیاده‌سازی هدفمند (Targeted Implementation): تنها در این مرحله عامل را برای سبز کردن تست دعوت کنید. افشای رابطه: این مقاله به عنوان بخشی از فعالیت‌های ترویجی محصول MonkeyCode تهیه شده است. MonkeyCode دسترسی رایگان به مدل و یک گزینه سرور رایگان برای میزبانی این گام کدنویسی ارائه می‌دهد. از عامل بخواهید کوچک‌ترین تغییری را ایجاد کند که تست را سبز کند و به‌جای ارسال کل تیکت، فقط بدنه تست را در پرامپت قرار دهید.

شناسایی نتایج «سبز جعلی»

حتی وقتی تست پاس می‌شود، ممکن است پیاده‌سازی یک دروغ باشد. عامل‌ها اغلب با تضعیف ادعاهای (asserts) شما، تست را سبز می‌کنند. چهار نشانه (cheap tells) برای شناسایی این تقلب عبارت‌اند از:

• تأییدهای مبتنی بر نوع (Type-based Asserts): بررسی اینکه خروجی یک «رشته» (string) است، به‌جای بررسی مقدار دقیق مورد انتظار.
• موک‌های گسترده (Broad Mocks): استفاده از Mockهایی که رفتار واقعی را می‌بلعند و خلأیی ایجاد می‌کنند که کد در آن پاس می‌شود اما عملاً هیچ کاری انجام نمی‌دهد.
• شاخه‌های پیش‌فرض (Default Branches): نوشتن کدی که بدون توجه به منطق ورودی، مقدار مورد انتظار را به‌صورت پیش‌فرض برمی‌گرداند.
• حذف موارد خاص (Deleted Edge Cases): حذف بی‌صدای آن مورد خاص از تست قرمز اصلی که باعث شکست کد شده بود.

اگر هر خطی از تست اصلی شما در طول پیاده‌سازی جابه‌جا یا تغییر کرد، بازبینی را شکست‌خورده تلقی کنید. شما باید تست را از کامیت قرمز با دستور git checkout origin/week1/red-first -- tests/test_welcome_discount.py بازیابی کرده و دوباره اجرا کنید. اگر دوباره شکست خورد، کد تولیدی دروغ می‌گوید؛ کد تولیدی را اصلاح کنید و تست را دست‌نخورده باقی بگذارید.

حفاظ‌های هفته اول

برای مهندسان تازه‌وارد، یک جدول تصمیم‌گیری برای محدود کردن اثرات مخرب (blast radius) عامل‌ها ارائه شده است:

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

• PR 1: تخفیف خوش‌آمدگویی فقط یک‌بار اعمال شود
• PR 2: تخفیف خوش‌آمدگویی حساب‌های کارکنان را نادیده بگیرد
• PR 3: تخفیف خوش‌آمدگویی یک ردیف حسابرسی (audit row) ثبت کند

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

برخی فایل‌ها باید به‌طور کامل از لیست مجاز خارج شوند زیرا شکست آن‌ها در محیط تولید (production) بسیار شدیدتر از تست‌های واحد است:

• فایل‌های Lock و درخت‌های vendor تولید شده
• فایل‌های گردش‌کار CI و اسکریپت‌های استقرار (deploy)
• مهاجرت‌های پایگاه‌داده (migrations) و feature flagها
• ماژول‌های احراز هویت (Auth)، پرداخت (billing) و بارگذاری اسرار (secret loading)

این متدولوژی جایگزین بازبینی‌های طراحی یا راهنمایی‌های مهندسان ارشد نیست. این روش صحت کامل محصول را ثابت نمی‌کند و خطاهای هم‌زمانی (concurrency)، باگ‌های دسترسی (permission) یا حالت‌های فراموش‌شده UX را شناسایی نمی‌کند. همچنین برای اصلاحات فوری (hotfix)، بازنویسی APIهای عمومی یا مخازنی که تست‌ران ندارند، کاربرد ندارد. مهندسان ارشد که زمینه عمیقی از مخزن دارند ممکن است از این مراحل بگذرد زیرا قرارداد را در ذهن خود دارند؛ اما تازه‌کارها چنین نیستند.

برای حفظ این انضباط، یک چک‌لیست برای توصیفات PR پیشنهاد می‌شود:

• مجموعه تست‌های موجود در main سبز هستند
• یک تست قرمز توسط من کامیت شده است
• لیست مجاز عامل محدود به فایل‌های src است
• مسیرهای محافظت‌شده بعد از وصله تغییر نکرده‌اند
• تست جدید و کل مجموعه تست‌ها سبز هستند
• می‌توانم هر بخش از کد src را به‌صورت شفاهی توضیح دهم

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

گام بعدی شما

• در اولین PR بعدی خود، پیش از باز کردن چت با هوش مصنوعی، یک تست شکست‌خورده بنویسید و آن را کامیت کنید.
• اسکریپت git diff را برای بررسی تغییرات در فایل‌های حساس (مانند lockfiles) در گردش‌کار خود بگنجانید.
• اگر مهندس ارشد هستید، این جدول محدودیت‌ها را برای آنبوردینگ اعضای جدید تیم پیاده کنید.

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