۸ استاندارد مهندسی برای جلوگیری از تخریب کد توسط عامل‌های هوش مصنوعی

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

اعتماد به‌سختی به دست می‌آید و به‌سادگی از بین می‌رود. در یک گردش‌کار عامل‌محور، اعتماد باید در هر حلقه برقرار شود: آیا به نویسنده تیکت اعتماد داریم؟ آیا مهندسی که عامل را هدایت می‌کند قابل‌اعتماد است؟ آیا به پیاده‌سازی عامل، توانایی مجموعه تست‌ها در شناسایی رگرسیون‌ها و پایداری استقرار در CI/CD اعتماد داریم؟ در نهایت، باید به تنظیمات مشاهده‌پذیری (Observability) برای ارسال هشدارها و پایداری گیت‌هاب در حساس‌ترین لحظات اعتماد کنیم.

همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، ابزارهای خودکار بدون نظارت انسانی می‌توانند نقاط ضعف امنیتی را در مقیاس وسیع تکثیر کنند. به همین دلیل، طبق گزارش ۶ سپتامبر ۲۰۲۶ از وب‌سایت kaeruct.github.io، راهکار ممنوعیت هوش مصنوعی نیست، بلکه تغییر محور پاسخگویی است. در این عصر جدید، مهندسی که درخواست ادغام یا PR (Pull Request) را ارسال می‌کند، فارغ از اینکه کد توسط انسان یا عامل نوشته شده باشد، مسئولیت کامل رفتار کد در محیط عملیاتی را بر عهده دارد. اصل حاکم ساده است: «شما مسئول چیزی هستید که منتشر می‌کنید؛ اگر سیستم خراب شد و شما نویسنده PR بودید، باید برای تعمیر آن حضور داشته باشید.»

برای جلوگیری از تخریب پایگاه کد، تیم‌ها باید این حفاظ‌های قطعی را پیاده کنند:

حفاظ‌های فنی

• ابزارهای قطعی: استفاده از زبان‌های دارای تایپ سخت‌گیرانه، لینترها (Linters) — ابزارهایی شبیه به ویراستاران سخت‌گیر که غلط‌های نگارشی کد را می‌گیرند — شناسایی کدهای مرده (Dead Code Detection) و اسکنرهای امنیتی برای مبارزه خودکار با کدهای بی‌کیفیت یا «slop». این ابزارها پیش از ظهور عامل‌ها وجود داشتند و همچنان برای تضمین کیفیت حیاتی هستند.
• PRهای کوچک: بازبین‌ها باید هر PRی را که برای بازبینی معنادار بیش از حد بزرگ است، رد کنند. بهتر است این معیارها کدنویسی شوند تا درخواست‌های غیرقابل‌بازبینی فوراً رد شوند، هرچند باید فضایی برای استثناهای نادر باقی بماند.
• دستورالعمل‌های کدنویسی: استراتژی تکنولوژی شفافی تعریف کنید. در تدوین دستورالعمل‌هایی سرمایه‌گذاری کنید که هم انسان‌ها و هم عامل‌ها بتوانند از آن‌ها استفاده کنند. حتی اگر انسان‌ها این قوانین را نادیده بگیرند، عامل‌های هوش مصنوعی (AI Agents) — مثل دستیارهای دیجیتالی که می‌توانند مستقلاً کد بزنند و ابزارها را اجرا کنند — این دستورالعمل‌ها را می‌خوانند و تا حد زیادی رعایت می‌کنند.

تغییرات فرآیندی

• تست‌های انسان‌محور: انسان‌ها باید مانند تحلیل‌گران کسب‌وکار عمل کنند. آن‌ها باید عمیقاً درباره ویژگی‌ها فکر کرده و سناریوهای تست را به‌صورت دستی تعریف کنند. عامل‌ها می‌توانند تست‌ها را پیاده کنند، اما تعریف آن‌ها باید بر عهده انسان باشد.
• نمونه‌سازی سریع: از هزینه پایین تولید با هوش مصنوعی برای ساخت کدهای یک‌بارمصرف استفاده کنید. قبل از انتخاب نهایی، سه رویکرد کاملاً متفاوت را برای حل یک مسئله امتحان کنید تا بهترین گزینه متناسب با سیستم موجود انتخاب شود.
• تمرکز بر نتیجه: واقع‌بین باشید. گاهی خروجی نهایی یک گزارش یا ابزار ساده است، نه کد عملیاتی. در این موارد، کاربردی بودن نتیجه مهم‌تر از کیفیت ساختاری کد است.

این تغییر یعنی نقش مهندس از یک «نویسنده» به یک «کیوریتور» و «تأییدکننده» تبدیل می‌شود. این تحول در واقع بخشی از یک روند گسترده‌تر است که در آن ماهیت مهندسی نرم‌افزار از مکانیک‌های کدنویسی به سمت ارکستراسیون تغییر می‌کند. ارزش اصلی اکنون در «سلیقه محصول» است؛ یعنی همکاری با تیم‌های محصول برای حفظ یک چشم‌انداز منسجم. این کار تضمین می‌کند که سرعت تولید هوش مصنوعی منجر به پیاده‌سازی ویژگی‌های بیهوده‌ای نشود که هیچ ارزشی برای کاربر ندارد.

برای توسعه‌دهنده مدرن، ارزش شما دیگر با مقدار کدی که ارسال می‌کنید سنجیده نمی‌شود، بلکه با میزان اثربخشی شما در مدیریت عامل‌هایی که کد می‌زنند اندازه‌گیری می‌شود. اگر نمی‌توانید خروجی را از طریق ابزارهای قطعی و تست‌های دستی تأیید کنید، فقط در حال شتاب دادن به انباشت بدهی فنی (Technical Debt) هستید. برای مدیریت این چالش، می‌توان از رویکردهای مهندسی هارنس برای جلوگیری از انباشت بدهی فنی در کدهای تولید شده توسط هوش مصنوعی بهره برد.

تیم‌ها باید اکنون خط لوله‌های CI/CD خود را بازبینی کنند تا ببینند کدام بررسی‌های کیفی دستی هستند و کدام‌ها را می‌توان به صورت خودکار برای رد مشارکت‌های غیرقابل‌بازبینی عامل‌ها کدنویسی کرد.

گام بعدی شما

• لیست تمام بررسی‌های دستی در CI/CD را استخراج کنید و برای تبدیل آن‌ها به قوانین خودکار (Automated Guardrails) برنامه‌ریزی کنید.
• استانداردهای کدنویسی تیم را به‌روز کنید تا به عنوان منبع مرجع برای عامل‌های هوش مصنوعی مورد استفاده قرار گیرد.
• در PRهای بعدی، سخت‌گیرانه‌تر عمل کنید و هر تغییری که بیش از ۲۰۰ خط باشد را بدون دلیل موجه رد کنید.

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