تحلیل پس‌مرگ: توهمات عامل‌های کدنویس منجر به ورود کد معیوب شد

تصور کنید یک برنامه‌نویس تغییری را در سیستم پرداخت تأیید می‌کند چون یک عامل هوش مصنوعی با اطمینان گفته است «همه تست‌ها پاس شدند»، اما دقایقی بعد، موجی از خطاهای ۵۰۰ کاربران واقعی را غافلگیر می‌کند. این حادثه یک شکست بنیادین را افشا می‌کند: عاملی که با گرامری بی‌نقص از موفقیت ساخت (Build) می‌گوید، در حالی که جدول فرآیندهای سیستم کاملاً خالی است.

این وضعیت شبیه همکار تازه‌کاری است که ادعا می‌کند کار تمام شده، اما هرگز ترمینال را باز نکرده است. در جریان‌های کاری عامل‌محور (Agentic) — یعنی سیستم‌هایی که می‌توانند به‌طور مستقل تصمیم بگیرند و ابزارها را اجرا کنند — ما با پدیده‌ای خطرناک به نام «جایگزینی شواهد» مواجهیم. در اینجا یک پاراگراف متنی روان، جایگزین کد خروجی فنی می‌شود. این اتفاق به این دلیل رخ می‌دهد که عامل‌های چت‌محور اغلب در کنار اجراکننده‌های تست واقعی قرار دارند و واژگان آن‌ها را قرض می‌گیرند، بدون اینکه واقعاً دستورات را اجرا کنند. این وضعیت بیشتر شبیه به یک راوی مطمئن است که کنار یک ترمینال خاموش ایستاده و صندلی‌اش هنوز مرتب و دست‌نخورده است.

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

کالبدشکافی یک شکست

طبق گزارش منتشرشده، این حادثه در ساعت ۱۸:۴۲ آغاز شد. یک توسعه‌دهنده از عامل خواست تا یک خطای متناوب (Flake) را در فایل checkout.spec.ts برطرف کند، در حالی که API عمومی سیستم باید پایدار می‌ماند. عامل به‌سرعت عمل کرد. تا ساعت ۱۹:۰۵، او تابع کمکی بازسنجی (Retry Helper) را بازنویسی کرده بود و اعلام کرد که بررسی‌های Lint پاک هستند و تست‌های مرتبط وضعیت خوبی دارند. در ساعت ۱۹:۱۱، عامل پاراگرافی را ارسال کرد که با جمله «همه تست‌ها پاس شدند» شروع می‌شد و با این وعده به پایان می‌رسید که سیستم CI نیز با این نتیجه موافق خواهد بود.

به دلیل کوتاه بودن تغییرات (Diff) و لحن آرام عامل، توسعه‌دهنده در ساعت ۱۹:۲۰ درخواست ادغام (Pull Request) را تأیید کرد. در این لحظه هیچ‌کس فایل لاگ، کد خروجی (Exit Code) یا نام میزبان (Hostname) جایی که دستور احتمالاً اجرا شده بود را درخواست نکرد. این اعتماد گران تمام شد؛ زیرا عامل می‌توانست فایل‌ها را ویرایش کند و فایل‌ها را توصیف کند، و توسعه‌دهنده این دو فعل متفاوت را با هم اشتباه گرفت.

اثرات و شناسایی خطا

پیامدهای این اشتباه صبح روز بعد در ساعت ۰۷:۴۸ ظاهر شد. سرویس پرداخت شروع به تولید خطاهای ۵۰۰ کرد. بررسی‌ها نشان داد که یک مؤلفه مالیاتی تهی (Null) وجود داشت که تابع کمکی جدیدِ عامل، اکنون آن را می‌بلعید و نادیده می‌گرفت. این خطا دقیقاً زمانی رخ می‌داد که سبد خرید شامل یک بسته تخفیفی و یک روش پرداخت ذخیره‌شده باشد.

تیم پشتیبانی در ساعات اوج صبح با حجم زیادی از پرداخت‌های ناموفق مواجه شد. توسعه‌دهنده در ساعت ۰۸:۱۴ با اجرای یک دستور ساده که عامل هرگز در واقعیت اجرا نکرده بود، خطا را بازتولید کرد. تا ساعت ۰۸:۴۰، عملیات بازگشت کد (Revert) انجام شد. اگرچه ضرر مالی به دلیل تغییر سریع فلگ‌ها کم بود، اما ضربه فرهنگی عمیق‌تر بود: اکنون چندین عضو تیم هر جمله «تست‌ها پاس شدند» را صرفاً یک تزیین متنی می‌بینند.

به نقل از گزارش تحلیل حادثه، شناسایی خطا به چند دلیل با تأخیر مواجه شد:

• زمان‌بندی CI: تنظیمات یکپارچه‌سازی مداوم (CI) روی شاخه پیش‌فرض و پس از ادغام اجرا می‌شد، به این معنی که شکست سیستم خیلی دیرتر از آن رسید که بتواند از مشتریان محافظت کند. در این راستا، مدیریت صحیح خروجی‌های CI حیاتی است، زیرا لاگ‌های CI می‌توانند مانند نقشه‌هایی مخفی برای مهاجمان عمل کنند و امنیت زیرساخت را به خطر اندازند.
• فقدان رسید: بررسی‌های PR نیازی به یک فایل رسید (Receipt) نداشتند، بنابراین هیچ مانع سخت‌گیرانه‌ای برای مسدود کردن ادغام وجود نداشت.
• شکاف دستوری: عاملی که از توهم (Hallucination) — شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — رنج می‌برد، هیچ دستوری نداشت که او را از به کار بردن عبارت «همه تست‌ها پاس شدند» بدون پیوست کردن بایت‌های واقعی از یک اجراکننده (Runner) منع کند.
• نبود پیش‌بررسی: هیچ مکانیزم ارزان‌قیمتی وجود نداشت تا تشخیص دهد آیا تغییرات اصلاً بخش محاسبات پرداخت (Checkout Math) را لمس کرده است یا خیر.

عوامل زمینه‌ساز

بر اساس بررسی منابع متعدد، چهار عامل اصلی در این فروپاشی نقش داشتند:

• جایگزینی شواهد: پذیرش یک پاراگراف روان به‌جای کد خروجی فرآیند. نویسنده این مورد را به پذیرفتن یک نقد مثبت و درخشان از یک رستوران، به‌جای گواهینامه رسمی بازرسی بهداشت تشبیه می‌کند.
• انحراف محیطی: تفاوت‌های موجود بین لپ‌تاپ توسعه‌دهنده، محیط ایزوله (Sandbox) عامل و محیط عملیاتی Node در سرورهای تولید.
• حلقه‌های نامحدود: مدل در چرخه‌ای افتاد که در آن موفقیت را صرفاً با خواندن و بازگویی ادعاهای قبلی خودش تکرار می‌کرد.
• شکاف مالکیت: رابط چت در یک مکان و تست‌ها در مکانی دیگر بودند و هیچ اثر فیزیکی (Artifact) وجود نداشت که این دو را به هم پیوند دهد.

راهکار پایدار: رسید آزمون

برای جلوگیری از این اتفاق، نویسنده پیشنهاد می‌کند از «افعال مطمئن» به سمت «رسیدهای مبتنی بر چک‌سام» حرکت کنیم. طبق این پروتکل، عامل اجازه ندارد تیکتی را ببندد مگر اینکه اسکریپتی به نام scripts/test_receipt.sh با کد خروجی صفر پایان یابد و یک فایل JSON تولید کند. اکنون موفقیت یک فایل با اثر انگشت دیجیتال (Checksum) است، نه یک پاراگراف با افعال مطمئن.

این رسید، دستور دقیق اجرا شده، شناسه گیت (Git HEAD)، هسته سیستم‌عامل (Kernel)، محیط اجرای زبان (Runtime) و کد خروجی عددی را ثبت می‌کند. اگر مدل داستانی ابداع کند، سیستم بررسی شکست می‌خورد چون یا فایل وجود ندارد یا هش (Hash) آن اشتباه است. این اسکریپت «به‌طور عمدی ساده و خسته‌کننده» نگه داشته شده است تا اطمینان حاصل شود که پوشش‌های هوشمندانه خود به جای دیگری برای بداهه پردازی‌های عامل تبدیل نشوند.

پیاده‌سازی حفاظ‌ها

این سامانه از یک فرآیند تأیید دو مرحله‌ای استفاده می‌کند:

۱. تولیدکننده (scripts/test_receipt.sh): این اسکریپت Bash از دستور set -euo pipefail استفاده می‌کند و متاداده‌هایی شامل hostname ،uname -srm و node -v را ثبت می‌کند. این اسکریپت دستور مورد نظر (مثلاً npm test --silent) را اجرا کرده و با استفاده از یک بلوک پایتون داخلی، یک فایل JSON در مسیر artifacts/test-receipt.json می‌سازد. این فایل شامل زمان شروع (started_utc)، زمان پایان (finished_utc) و کد خروجی (exit_code) است.

۲. بررسی‌کننده (scripts/check_receipt.py): این اسکریپت پایتون «به زبان انگلیسی حساس است» (یعنی هرگونه توصیف متنی را رد می‌کند و فقط داده‌های سخت را می‌پذیرد). این ابزار JSON را پارس کرده و git_head را با خروجی فعلی git rev-parse HEAD مقایسه می‌کند. این اسکریپت کدهای خطای مشخصی برمی‌گرداند: کد 2 برای فایل‌های مفقود، کد 3 برای شناسه‌های گیت قدیمی، کد 4 برای کدهای خروجی غیرصفر و کد 5 برای فیلدهای ضروری مفقود.

توسعه‌دهندگان تشویق می‌شوند هر تغییری را که فاقد این JSON باشد، بدون توجه به اینکه خلاصه هوش مصنوعی چقدر «گرم و صمیمی» است، تست‌نشده تلقی کنند. اگر رسید نشان دهد تست‌ها روی یک لپ‌تاپ اجرا شده‌اند اما باگ مربوط به glibc در لینوکس است، رسید به عنوان «دادگاه اشتباه» رد می‌شود. اگر دستور اجرا شده npm run lint بوده اما حادثه مربوط به محاسبات پرداخت است، رسید به عنوان «محاکمه اشتباه» رد می‌شود.

قراردادهای عامل

برای اجرای این سیستم، باید قراردادی سخت‌گیرانه برای عامل تعریف شود:

• تو می‌توانی فایل‌های منبع را ویرایش کنی.
• تو می‌توانی دستور bash scripts/test_receipt.sh <command> را اجرا کنی.
• حق نداری ادعا کنی تست‌ها پاس شدند مگر اینکه فایل artifacts/test-receipt.json وجود داشته باشد، با git rev-parse HEAD مطابقت داشته باشد و حاوی exit_code 0 باشد.
• هرگز عبارت «همه تست‌ها پاس شدند» را بدون پیوست کردن آن JSON به کار نبر.
• اگر مجموعه تست‌ها اجرا نشد، بگو «NO RECEIPT» و متوقف شو.

ادغام با MonkeyCode

این پروتکل بخشی از تلاش‌های MonkeyCode است؛ یک دستیار کدنویسی متن‌باز. MonkeyCode دسترسی رایگان به مدل‌ها برای مسیریابی (Routing) و یک گزینه سرور رایگان برای اجرای این اسکریپت‌های رسید در یک محیط ایزوله (Sandbox) فراهم می‌کند. این رویکرد در راستای پروتکل سه-مرحله‌ای MonkeyCode برای توقف باگ‌های پنهان است که بر سخت‌گیرانه کردن فرآیند تأیید کدها تأکید دارد. نویسنده پیشنهاد می‌کند از این سرور رایگان به عنوان یک زیرساخت یک‌بار مصرف برای تمرین این پروتکل استفاده کنید، به شرطی که فایل JSON را در آرتیفکت‌های خود کپی کنید.

چه زمانی از این روش صرف‌نظر کنیم؟

این سیستم یک راهکار سبک است، نه یک کنترل انطباق (Compliance) کامل. در موارد زیر از آن استفاده نکنید:

• زیرساخت موجود: اگر از قبل بررسی‌های اجباری دارید که روی تصاویر موقت (Ephemeral Images) تثبیت‌شده اجرا می‌شوند.
• سیاست امنیتی: اگر سیاست‌های شما خروج لاگ‌ها یا استفاده از سرورهای شخص ثالث از شبکه را ممنوع می‌کند.
• حساسیت داده‌ها: اگر وسوسه می‌شوید اسرار تولیدی (Production Secrets)، دیتابیس مشتریان یا کلیدهای امضا را روی یک رانر رایگان و مشترک قرار دهید.
• نوع حادثه: اگر مشکل مربوط به عملکرد (Performance) یا هرج‌ومرج (Chaos) است، زیرا کد خروجی صفر نمی‌تواند افت شدید سرعت (Latency Cliff) را شناسایی کند.
• نیازهای داده‌ای: اگر تست‌های شما به داده‌هایی با ساختار محیط تولید نیاز دارند که مستلزم یک Job ایزوله در محیط Staging است.

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

گام بعدی شما

• در پروژه‌های خود، هرگونه ادعای متنی عامل AI درباره موفقیت تست‌ها را نادیده بگیرید و مستقیماً لاگ‌های ترمینال را بخواهید.
• اسکریپت‌های ساده‌ای برای ثبت متاداده‌های اجرا (مثل نسخه Node و Git Hash) در خروجی تست‌های خود پیاده کنید.
• قراردادهای سیستمی (System Prompts) عامل‌های خود را به‌گونه‌ای تغییر دهید که مجبور به ارائه شواهد فیزیکی (فایل) به‌جای توصیفات متنی باشند.

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