۵ الگوی کدنویسی C# که هوش مصنوعی تولید می‌کند و سیستم‌های تست را می‌فریبد

اگر برنامه‌نویس .NET هستید و برای سرعت بخشیدن به کارتان از هوش مصنوعی استفاده می‌کنید، احتمالاً درخواست‌های ادغام (Pull Request) شما در حال پنهان کردن شکست‌های بحرانی در محیط عملیاتی است. در ۹ ژوئن ۲۰۲۶، گزارشی از dev.to روندی رو‌به‌رشد را افشا کرد: کدهای C# تولیدشده توسط AI، اصطلاحاً «بومی» و درست به نظر می‌رسند و تست‌های CI را می‌گذرانند، اما رگرسیون‌های معماری‌ای را بازمی‌گردانند که تیم‌های ارشد سال‌ها برای حذف آن‌ها تلاش کرده بودند.

زمینه رگرسیون‌های هوش مصنوعی

این اتفاق به این دلیل رخ می‌دهد که دستیارهای هوش مصنوعی از «دانش جمعی» (Tribal Knowledge) و تجربه‌های سختِ یک تیم مهندسی حرفه‌ای بی‌خبرند. آن‌ها قوانین خاص هر تیم، مثل قراردادهای EF یا ضرورت ارسال توکن‌ها را نمی‌شناسند. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بیش از حد به خروجی مدل بدون درک زمینه، ریسک‌های پنهانی ایجاد می‌کند. در حالی که یک بازبین انسانی شاید اشتباه در نوع داده (Lifetime) را در یک PR کوچک می‌گرفت، حجم بالای کدهای تولیدشده توسط AI اکنون منجر به «مرور سریع و سطحی» (Review Skimming) شده است.

نتیجه این است که کد از نظر نحوی درست است اما از نظر معماری شکسته است. این‌ها خطای سینتکس نیستند، بلکه نقضِ قصدِ معماری‌اند. چون کد کامپایل می‌شود و تست‌ها سبز می‌مانند، این کدها به‌طور مؤثر هشدارهای IDE و نظارت انسانی را دور می‌زنند تا اینکه در نهایت در محیط تولید (Production) شناسایی شوند.

جزئیات الگوهای شکست

طبق تحلیل dev.to، پنج الگوی تکرار‌شونده وجود دارد که به‌طور مداوم به محیط عملیاتی نفوذ می‌کنند:

• مسیرهای خواندن EF Core: هوش مصنوعی اغلب متد AsNoTracking() را حذف می‌کند. مثلاً کوئری _db.Orders.Where(o => o.CustomerId == id).ToListAsync() منطقی به نظر می‌رسد، اما موجودیت‌هایی را ردیابی می‌کند که هرگز تغییر نمی‌کنند. این مورد در محیط توسعه مشکلی ندارد اما در مسیرهای پرترافیک خواندن در محیط تولید، بسیار هزینه‌بر است.
• وابستگی‌های اسیری (Captive Dependencies): مدل ممکن است یک سرویس با طول عمر Scoped را در یک Singleton تزریق کند. اگر IOrderRepository دارای محدوده (Scoped) باشد اما ReportCache یک تک‌مقدار (Singleton) باشد، تک‌مقدار تا ابد زنده می‌ماند در حالی که وابستگی Scoped منقضی شده است. این اتفاق منجر به وضعیت (State) غلط در درخواست‌های مختلف می‌شود.
• نادیده گرفتن CancellationTokens: متدها ممکن است توکن لغو را در امضا (Signature) بپذیرند، اما AI آن را به جلو منتقل نمی‌کند. مثلاً متدی await Task.Delay(500) را بدون پاس دادن توکن فراخوانی می‌کند و درخواست لغو را نادیده می‌گیرد، در حالی که امضای متد ادعای پشتیبانی از آن را دارد.
• بلعیدن استثناها (Swallowed Exceptions): برای «مدیریت مودبانه خطاها»، AI اغلب بلوک‌های catch خالی می‌سازد. با قرار دادن فراخوانی await SaveAsync(cancellationToken) در یک try-catch که استثنا را نادیده می‌گیرد، ابزارهای مانیتورینگ سبز می‌مانند در حالی که سیستم به‌طور خاموش شکست می‌خورد.
• انسداد I/O از طریق Task.Run: هوش مصنوعی مکرراً فراخوانی‌های مسدودکننده را در Task.Run می‌پیچد؛ مثلاً await Task.Run(() => File.ReadAllText(path)). این کار فقط بار را منتقل می‌کند اما انسداد را حذف نمی‌کند و به‌جای استفاده از APIهای واقعاً async مثل ReadAllTextAsync یا OpenReadAsync ،یک رشته از Thread Pool را می‌بندد.

این روند نشان‌دهنده تغییر نقش بازبین کد است. دیگر بررسی اینکه آیا کد «کار می‌کند» کافی نیست؛ بازبین‌ها باید اکنون فعالانه به دنبال شکست‌های الگویی AI باشند. خطر اینجاست که ردیابی این رگرسیون‌ها به یک PR خاص سخت است، چون Diff اولیه تمیز است و CI سبز مانده است.

حرکت به سمت اجبار (Enforcement)

برای تیم‌های کوچک و متوسط .NET، راهکار در عبور از هشدارهای IDE است. ابزارهایی مثل Roslynator و Sonar مسائل کیفی عمومی را می‌گیرند، اما هشدارها اغلب هنگام تایپ دفن شده یا نادیده گرفته می‌شوند. نویسنده پیشنهاد می‌کند تنها راه مطمئن، اجباری کردن این قوانین در خط لوله CI است — یعنی تبدیل شدت‌های .editorconfig به خطاهای سخت (Hard Errors) — تا کدهای معیوب AI اصلاً نتوانند ادغام شوند.

برای محافظت از کدبیس خود، باید ارزیابی کنید که آیا چک‌های CI فعلی شما به‌طور خاص این ۵ الگوی شکست را هدف قرار داده‌اند یا اینکه صرفاً به نظم و انضباط انسانی تکیه کرده‌اید.

گام بعدی شما

• بررسی کنید آیا چک‌های CI شما به‌طور خاص این ۵ الگوی شکست را هدف قرار داده‌اند یا فقط به نظم انسانی تکیه کرده‌اید.
• تنظیمات .editorconfig پروژه خود را بازبینی کرده و هشدارهای مربوط به Async/Await و EF Core را به Error تبدیل کنید.
• در جلسات Code Review، تمرکز را از «صحت خروجی» به «انطباق معماری» تغییر دهید.

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