DigitalOcean در آموزش تازه‌ای نشان می‌دهد که موفقیت نهایی یک AI agent لزوماً به معنی درست‌بودن مسیر اجرای آن نیست. در این آزمایش، یک agent مسئول رفع issue و بازکردن pull request، چهل بار اجرا شد. همهٔ اجراها pull request قابل‌استفاده با testهای موفق تولید کردند، اما در تمام آن‌ها یک bug مشترک پنهان مانده بود.
این agent با نام Fixer، پنج issue را هرکدام هشت بار انجام داد. هر اجرا در یک Sandbox تازه آغاز می‌شد که پس از پایان از بین می‌رفت. مشکل این بود که هویت git در این محیط تنظیم نشده بود؛ بنابراین نخستین commit همیشه شکست می‌خورد. agent سپس نام و ایمیلی به انتخاب خودش تنظیم می‌کرد و دوباره commit می‌زد. نتیجهٔ نهایی موفق بود و این بازیابی در خروجی نهایی دیده نمی‌شد.
طبق مقاله، این رفتار سه هزینه داشت: کاری که باید با یک دستور انجام می‌شد به سه دستور تبدیل می‌شد؛ خواندن خطا و تصمیم‌گیری برای رفع آن، فراخوانی بیشتر مدل و مصرف token داشت؛ و commitها به هویت‌هایی نسبت داده می‌شدند که agent ساخته بود و GitHub نمی‌توانست آن‌ها را به حساب واقعی مرتبط کند.
Signals با بررسی sessionها، در مجموع ۸۲ رویداد در شش دسته ثبت کرد. خطای ExecutionFailureStateError در هر ۴۰ session دیده شد. مقاله تأکید می‌کند که Telemetry زیرساخت، log درخواست‌ها و dashboard هزینه ممکن است همگی سالم به نظر برسند، درحالی‌که رفتار agent مشکل دارد؛ خواندن دستی متن اجراها هم در مقیاس صدها یا هزاران اجرا عملی نیست.
برای آزمودن اصلاح، Simulations از یک معیار سفارشی، سناریویی با همان prompt محیط production و نتیجهٔ قبول یا رد استفاده کرد. اصلاح شامل چهار متغیر محیطی روی نسخهٔ آزمایشی agent بود. همان simulation به نسخهٔ production امتیاز صفر و به نسخهٔ آزمایشی امتیاز یک داد؛ بنابراین اصلاح پیش از تغییر production بررسی شد. مسیر معرفی‌شده در این آموزش چهار مرحله دارد: پیداکردن مشکل، ساخت آزمون، اصلاح و اعتبارسنجی.
