اگر امروز به تیک سبزِ تستهای خودکار در Pull Requestهای تولیدشده توسط AI اعتماد میکنید، احتمالاً در حال دعوت از باگهای پنهان به محیط عملیاتی هستید. تیک سبز تنها میگوید کد اجرا شده است، اما هرگز تضمین نمیکند که کد «درست» کار میکند.
طبق راهنمایی که در ۱۰ سپتامبر ۲۰۲۶ در وبسایت dev.to منتشر شد، تلقی کردنِ «پاس شدن تستها» به عنوان پایان بازبینی، یک اشتباه استراتژیک است که منجر به پسرفت (Regression) در سیستمهای عملیاتی میشود. بسیاری از برنامهنویسان اکنون از عامل (Agent) — شبیه دستیاری که هم کد را مینویسد و هم امتحانش را طراحی میکند — برای هر دو مرحلهٔ پیادهسازی ویژگی و نوشتن تست استفاده میکنند. این وضعیت یک حلقهٔ بازخورد خطرناک میسازد؛ جایی که عامل بهجای تمرکز بر «شکستن کد در صورت خطا»، روی «پوشش ظاهری» بهینهسازی میکند.
همانطور که در تحلیلهای قبلی ما دربارهی توهمات مدلهای زبانی اشاره کردیم، مدلها تمایل دارند پاسخهایی تولید کنند که «درست به نظر برسند». این موضوع ضرورت جایگزینی اعتماد کورکورانه با شواهد اجرایی دقیق برای حذف توهمات در کدنویسی AI را بیش از پیش آشکار میکند. تصور کنید عاملی باگی را رفع کند، اما تستی بنویسد که فقط بررسی میکند آیا تابع «هر مقداری» برمیگرداند یا خیر، نه اینکه آیا مقدار «درست» را برمیگرداند.
برای مقابله با این وضعیت، نویسندهٔ این راهنما یک توالی چهارمرحلهای برای اعتبارسنجی پیشنهاد میدهد:
۱. بررسی Diff بهجای خلاصه
ابتدا لیست فایلها را باز کنید. روایتِ متنیِ عامل را نادیده بگیرید و بپرسید آیا تغییرات با قصد انسانی شما مطابقت دارد؟ مراقب فایلهای lock یا تغییرنامهایی باشید که درخواست نکردهاید؛ عاملها اغلب برای پر کردن فضای تست، توابع کمکی نامرتبط اضافه میکنند. در این راستا، ابزارهایی مانند CodeVetter تلاش میکنند تا ابهامات موجود در گزارشات عاملهای کدنویس را از طریق استانداردسازی شواهد کاهش دهند.
۲. بازبینی خصمانهٔ Assertions
تستهای جدید را بخوانید و بپرسید اگر باگ اصلی دوباره رخ دهد، آیا این تست واقعاً شکست میخورد؟ مراقب تستهای «نمایشی» باشید، مانند:
- بررسیهایی که فقط کد وضعیت ۲۰۰ (Status 200) را چک میکنند.
- اسنپشاتهایی که هر تغییر رفتاری را بدون خطا میپذیرند.
- پوشش مسیرهای موفق (Happy-path) که لبههای خطا (Edge cases) را نادیده میگیرند.
۳. تمرین مسیرهای شکست
تستهای سبز اغلب مسیرهایی را که باعث قطعی سیستم میشوند، نادیده میگیرند. شما باید بهصورت دستی تستهایی برای ورودیهای نامعتبر، نبودِ احراز هویت، عدم دسترسی و Timeoutها اضافه کنید. یک مورد منفیِ دقیق، از پنج مورد مثبتِ سطحی ارزشمندتر است.
۴. بازتولید محلی
به خروجیهای کپیشده اعتماد نکنید. دستور دقیق را روی ماشین خود اجرا کنید تا متوجه خطاهای گذرا (Flakes) یا هشدارهایی شوید که عامل ممکن است حذف کرده باشد. اگر نمیتوانید وضعیت سبز را محلی بازتولید کنید، شما با یک داستان مواجهید، نه یک تاییدیه.
این تغییر رویکرد، نقش توسعهدهنده را از یک بازبین غیرفعال به یک حسابرس خصمانه تبدیل میکند. با اولویت دادن به توالی «Diff ← Assertions ← مسیرهای شکست ← بازتولید محلی»، مهندسان میتوانند سرعت تولید AI را حفظ کنند بدون اینکه قضاوت فنی خود را از دست بدهند.
گام بعدی شما
- تمام PRهای فعلی که توسط AI تولید شدهاند را با چکلیست بالا بازبینی کنید تا تستهای نمایشی را شناسایی کنید.
- در دستورالعملهای تیم خود، بازتولید محلی (Local Reproduction) را به عنوان شرط اجباری برای ادغام کد قرار دهید.
- برای هر ویژگی جدید، حداقل دو مورد «تست منفی» (Negative Test) بهصورت دستی طراحی کنید.
اما چالش اصلی زمانی شروع میشود که این عاملها را در مقیاس هزاران خط کد رها کنیم؛ اثر این رویکرد بر پایداری زیرساختها را در گزارش بعدی بررسی خواهیم کرد.
گفتگو