تصور کنید کدی را میبینید که در نگاه اول کاملاً درست به نظر میرسد، اما در واقع غیرضروری است، اشتباهات ظریفی دارد، بیش از حد مهندسی شده (Overengineered) است یا بر اساس باگهایی نوشته شده که اصلاً وجود ندارند. سازنده Network Doctor (یک ابزار خط فرمان نوشته شده با زبان Go) این پدیده را «زبالههای هوش مصنوعی» (AI Slop) مینامد؛ نقطهای بحرانی در خط لولههای CI/CD که در آن «منطقی به نظر رسیدن» با «تأیید فنی» اشتباه گرفته میشود. خطر اصلی در کلمه «متقاعدکننده» نهفته است. این نوع کدها در زمان کامپایل خطا نمیدهند و تستهای قرمز موجود را هم فعال نمیکنند، بنابراین بهراحتی وارد محیط تولید میشوند.
این خطر صرفاً تئوری نیست و هزینههای آن در مقیاس صنعتی قابل اندازهگیری است. به گزارش TechCrunch در ۲۵ سپتامبر ۲۰۲۴، شرکت امنیت سایبری UpGuard متوجه شد که حدود ۱۶,۰۰۰ پایگاه داده حاوی اطلاعات شخصی در سرویس Supabase افشا شده است. این گزارش توضیح داد که کدهای تولیدشده توسط هوش مصنوعی اغلب دارای نقصهای امنیتی هستند یا برنامهها به پیکربندیهای خاصی نیاز دارند که توسعهدهنده از آنها بیاطلاع است.
اگرچه بیل هارمر (Bil Harmer)، مدیر امنیت Supabase، تأکید کرد که پلتفرم آنها «بهصورت پیشفرض امن» است و اشاره کرد که «ما پیشفرضهای امن و ابزارهای لازم را فراهم میکنیم و مشتریان کنترل میکنند که پروژههایشان چگونه پیکربندی شوند»، اما این اتفاق یک شکاف سیستمی را نشان میدهد. در واقع، دقیقاً همان بخشی که «مشتریان کنترل میکنند که پروژههایشان چگونه پیکربندی شود»، همان جایی است که عامل (Agent) — شبیه دستیاری که دستورات را اجرا میکند اما لزوماً منطق کل سیستم را نمیفهمد — کد را برای شما مینویسد و احتمالاً هیچ انسانی دوباره آن را نمیخواند. این چالشها در مدیریت عاملها، یادآور مهارتهای تخصصی برای جلوگیری از سقوط سیستمهای بکاند است که برای مهندسان در مواجهه با اتوماسیونهای هوشمند ضروری است.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدلها بدون لایههای نظارتی سخت، ریسکهای عملیاتی را بهشدت افزایش میدهد. برای مقابله با این وضعیت، لورنس لیو (Lawrence Liu)، سازنده ابزار Orbi، یک سیستم گیت چهارقاعدهای را پیشنهاد میکند تا اطمینان حاصل شود کدهای تولیدشده توسط هوش مصنوعی واقعاً امن هستند.
قانون ۱: بازبین نباید همان نویسنده باشد
لیو استدلال میکند که اجرای دوبارهی یک پرامپت در همان جلسه (Session) برای بازبینی، یک بررسی واقعی نیست. چون هوش مصنوعی همان استدلالهایی را به ارث میبرد که برای نوشتن کد استفاده کرده، صرفاً اشتباهات خودش را تقویت میکند. او شرط را اینگونه تعریف میکند: «بازبین نباید نویسنده باشد... باید یک فرآیند مجزا با یک پنجره متنی (Context Window) — مثل میز کاری که فقط چند ورق را در لحظه نگه میدارد و حافظهاش از کارهای قبلی پاک شده — پس از ایجاد Pull Request شروع شود و تغییرات منجمد شده (Frozen Diff) را بخواند.»
- زمینه تازه: بازبین باید یک فرآیند مجزا باشد. پرامپتی مثل «حالا کد بالا را بررسی کن» در همان جلسه، بازبینی نیست چون دلایل متقاعدکننده نویسنده را به ارث میبرد که در طول جلسه برای متقاعد کردن خودش استفاده کرده است.
- تست قصد: بازبینی با زمینه پاک، از قصد نویسنده بیخبر است. به باور لیو این یک نقطه قوت است: «اگر کد برای فهمیده شدن به قصد نویسنده نیاز دارد، یعنی کد هنوز تمام نشده است.»
- سقف سخت: لیو محدودیت سخت ۵ دور برای یافتههای بازبینی اعمال میکند. او اشاره میکند: «دوری که با یافتههای خطا به پایان میرسد، یک ادغام (Merge) نیست، بلکه دور دیگری است... تمام کردن این دورها به معنای توقف است، نه ادغام.» وقتی این سقف پر شود، فرآیند متوقف شده و یک انسان فراخوانده میشود، نه اینکه استانداردها برای پاس شدن پایین بیایند.
- تنوع مدل: توصیه میشود برای بازبینی از مدل متفاوتی استفاده شود؛ نه لزوماً چون مدل دوم دقیقتر است، بلکه چون «اختلاف نظر مفید است».
قانون ۲: تأیید از راه دور در سه نقطه
احکام تأیید تاریخ انقضا دارند. بین لحظه پایان بازبینی و فشردن دکمه Merge، ممکن است شاخه (Branch) تغییر کرده باشد. لیو سه بررسی را در لحظه دقیق ادغام علیه سرور (Remote) اجرا میکند:
- وضعیت CI: وضعیت CI باید دقیقاً روی آخرین کامیت (Commit Head) که بازبینی شده است، سبز باشد.
- ثبات Head: سر شاخه نباید از زمان صدور حکم جابهجا شده باشد. لیو صراحتاً میگوید: «هر Push بعد از بازبینی، آن را باطل میکند.»
- بهروزرسانی Base: PR باید آخرین نسخه شاخه اصلی (Main) را داشته باشد. این کار باید از طریق Merge استاندارد انجام شود، نه Rebase که تاریخچه بازبینیشده را بازنویسی میکند.
لیو برای اتوماسیون این مورد از دستور gh pr merge "$PR" --squash --match-head-commit "$REVIEWED_HEAD" استفاده میکند. او رفتار این دستور را اینگونه توصیف میکند: «اگر سر ریموت بعد از بازبینی جابهجا شده باشد، این فراخوان به جای ادغام چیزی که هیچکس بازبینی نکرده، با خطا مواجه میشود.»
این ارزانترین بررسی امنیتی در سیستم است—یک فلگ ساده که به هیچ زیرساخت جدیدی نیاز ندارد. لیو استدلال میکند که این موارد باید به صورت کد نوشته شوند نه عادت، زیرا «اینها سه خط در یک ماشین وضعیت هستند، نه سه عادت در ذهن یک شخص؛ بنابراین حتی ساعت ۳ صبح در نودمین PR هم به درستی عمل میکنند.»
قانون ۳: تبدیل خطاهای تکراری به ناورداها
پروژه Network Doctor پیشنهاد میکند مخازن کد را نسبت به «کارهای تأییدنشده» خصمانه کنید. به جای اصلاح دستی اشتباهات تکراری هوش مصنوعی، آنها را به ناورداها (Invariants) — قوانینی تغییرناپذیر که هرگز نباید نقض شوند — تبدیل کنید.
- ضد-باگ: عاملها باید قبل از تلاش برای اصلاح، ثابت کنند که باگ در نسخه فعلی (HEAD) وجود دارد. دستورالعمل مخزن میگوید: «قبل از تغییر رفتار، مسئله گزارش شده را روی HEAD فعلی تأیید کنید.» این کار مانع از «اصلاح» باگهایی میشود که ماهها پیش رفع شدهاند. این رویکرد برای جلوگیری از شکستهای سیستمی در مقیاس بالا حیاتی است، مشابه آنچه در بررسی ۱۰ نقطه شکست در مقیاسدهی Playwright Python برای متخصصان SDET تحلیل کردیم.
- اجرا به جای ادعا: هوش مصنوعی نمیتواند صرفاً ادعا کند کد درست است. نویسنده نسبت به این چرخه شکسته هشدار میدهد: «هوش مصنوعی کد را مینویسد. هوش مصنوعی کد را میخواند. هوش مصنوعی میگوید کد درست به نظر میرسد. تمام. این بازبینی نیست.» در عوض، کد باید از یک بررسی اجرایی شامل Format, Vet, Build (با محدودیتهای انتشار), Cross-compile و تستها عبور کند.
- تست قرارداد: هوش مصنوعی میتواند همزمان کد، تستهای نزدیک و کامنتها را بهروز کند و تغییری «بهطور ظاهری سازگار» ایجاد کند که قراردادهای عمومی (Public Contract) را میشکند. تنها راه شناسایی این خطاها، تستهایی است که خارج از محدوده پیادهسازی قرار دارند.
- قانون متا: «اگر یک اشتباه تکراری را مدام دستی اصلاح میکنید، آن را به یک ناوردا تبدیل کنید.» برای مثال، یک مخزن شامل تستی خاص برای رد کردن خط تیره بلند (Long Dash) در فایلهای متنی است، صرفاً چون نویسنده از یادآوری مداوم به مدل خسته شده بود.
- حوزههای هدف: ناورداها باید روی «قراردادهای خستهکننده» مانند شکل پارامترها، کدهای خروجی (Exit Codes)، نام فیلدهای JSON و رفتارهای Timeout قرار گیرند.
قانون ۴: گیت کیفیت تیکت
هیچ گیت پاییندستی نمیتواند یک تیکت مبهم را نجات دهد. لیو هشدار میدهد که «یک تیکت مبهم، یک تحویل غلط اما با اعتمادبهنفس تولید میکند، و هیچ گیت پاییندستی آن را نمیگیرد، زیرا گیت بررسی میکند که آیا کد همان کاری را انجام داده که تیکت گفته است یا خیر.»
این گیت سازگاری بین کد و توضیحات را تضمین میکند؛ اما نمیتواند بداند آیا توضیحات با قصد واقعی شما مطابقت دارد یا نه. معیارهای پذیرش (Acceptance Criteria) باید بهگونهای نوشته شوند که یک سیستم غیرهوشمند بتواند بدون نیاز به پرسش برای شفافسازی، تشخیص دهد که کار «تمام شده» است یا خیر.
این چارچوب اجازه اتوماسیون شدید را میدهد. لیو گزارش داد که پس از یک ماه اجرای این لایهها، ۴۳۱ Pull Request را ادغام، ۴۱۶ ایشو (Issue) را تکمیل و ۴۰ نسخه را منتشر کرده است. نتیجهگیری او تکاندهنده است: «من Diff کدها را نخواندهام.» این سطح از اعتماد تنها زمانی ممکن است که عادت انسانی جای خود را به ماشینهای وضعیت سختافزاری بدهد.
گام بعدی شما
- فلگ
--match-head-commitرا به مراحل ادغام خود اضافه کنید تا از ورود تغییرات بازبینینشده جلوگیری شود. - بازبینیها را در یک جلسه جدید و پس از ایجاد PR، بر روی Diff منجمد شده و با سقف تعداد دور مشخص اجرا کنید.
- سه خطای تکراری که بیش از دو بار دستی اصلاح کردهاید را شناسایی کرده و آنها را به تستهای ناوردا تبدیل کنید.
- آخرین تیکت خود را با «معیارهای پذیرش ماشینخوان» بازنویسی کنید و خروجی عامل را با آن بسنجید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو