وقتی ایجنت پشتیبانی گامرود خودش باگ رو فیکس کرد
هوش مصنوعیخلاصهٔ کاملتر
تو این مقاله اومده که یکی از سازندههای گامرود به اسم Jordie Breuan یه باگ بصری گزارش کرد: سه تا خط تیرهٔ بزرگ روی نمودار فروشش تو موبایل شناور بودن. ایجنت پشتیبانی گامرود فقط تیکت رو ثبت نکرد و به مهندس پاس نداد؛ خودش باگ رو بازتولید کرد، توی کدبیس دنبالش گشت، براش تست نوشت، یه Pull Request باز کرد و فیکس رو تا پروداکشن دنبال کرد. بعدش هم به همون کاربر خبر داد که تغییر لایوه و ۲۵ دلار اعتبار استاندارد شرکت بابت باگ رو براش صادر کرد — بدون اینکه وسطش آدمی به تیکت دست بزنه.
ماجرای جالبتر بعدش شروع شد. Jordie دوباره نمودار رو چک کرد و گفت هنوز درست نیست: مارکر سر جای درستش رفته بود، ولی نمودار یه بارِ سایهدار نشون میداد درحالیکه بقیهٔ نمودار با شمارش کار میکرد و همین خوندن داده رو سختتر میکرد. یعنی باگ فنی حل شده بود ولی تصمیم طراحیِ پشتش نه. ایجنت یه قضاوت طراحی کرده بود، نه صرفاً یه اصلاح کد، و اون قضاوت غلط از آب دراومد. Sahil، یکی از بنیانگذارهای گامرود، وارد شد تا خودش تصمیم طراحی رو بگیره.
نسخهٔ دوم فیکس این بار خودکار ریلیز نشد: تأیید خود Jordie شد یه مرحلهٔ اجباری قبل از مرج شدن PR. نویسنده میگه همینجاست که این ماجرا با یه داستان معمولیِ رفع باگ فرق میکنه؛ مشتری، نه فقط مهندس یا فرایند QA، بخشی از دروازهٔ ریلیز شد. خط پایان دیگه «کد کامپایل میشه و تست پاس میشه» نبود، «مشتری تأیید میکنه که واقعاً درست به نظر میرسه» بود.
به گفتهٔ نویسنده، خیلی از باگها — مخصوصاً باگهای UI و UX — اصلاً مسئلهٔ کد نیستن و به ادراک آدم برمیگردن: یه بارِ سایهدار کنار بارهای توپر همزمان هم کدِ معتبره هم نمودارِ گیجکننده، و هیچ یونیتتستی این رو نمیگیره. مقاله این الگو رو از پشتیبانی هوش مصنوعیِ رایج جدا میکنه که فقط جواب تیکت رو سریعتر میده ولی ریشهٔ مشکل سر جاش میمونه. یه نمونهٔ مشابه تو یه شرکت رسانهای کوچیک، با بازطراحی دسترسی دعوتنامهٔ Slack، حجم تیکتهای یه هفته رو از ۵۲ به ۱۹ رسوند.
نویسنده معتقده هیچکدوم از این دو نمونه همهچیز رو دست ایجنت ندادن: تصمیمهای مربوط به دسترسی حساب، پول و طراحی محصول پیش آدم موند. پیشنهاد عملیش برای تیمهای کوچیک اینه که اول فرایند واقعی پشتیبانی رو همونطور که هست بنویسن — با همون «کارهای پنهون» مثل چک کردن رکورد پرداخت یا گشتن تو مکالمههای قدیمی — بعد تیکتها رو بهجای شکایت ظاهری بر اساس ریشه گروهبندی کنن و فقط بخش تکراری و تحقیقاتی رو خودکار کنن.
نکات کلیدی:
- ایجنت پشتیبانی گامرود یه باگ نمودار رو بازتولید کرد، تو کد ردش رو گرفت، تست نوشت، PR باز کرد و فیکس رو بدون دخالت آدم تا ریلیز برد.
- فیکس اول از نظر فنی درست بود ولی از نظر بصری غلط، چون ایجنت یه قضاوت طراحی کرد که با بقیهٔ نمودار جور درنمیاومد.
- برای نسخهٔ دوم، تأیید خود مشتری قبل از مرج شدن PR اجباری شد؛ یعنی مشتری بخشی از دروازهٔ ریلیز.
- تفاوت اصلی با چتباتهای پشتیبانی اینه که بهجای جواب سریعتر، سراغ ریشهٔ مشکل میره تا تیکت تکراری تولید نشه.
- تو یه نمونهٔ غیرکدی، اصلاح دسترسی دعوتنامهٔ Slack تیکتهای یه هفته رو از ۵۲ به ۱۹ رسوند.
- تصمیمهای پرریسک مثل دسترسی حساب، پول و طراحی محصول همچنان دست آدم موند.
- روش مقیاسدادن رویهایه: فرایند واقعی رو مستند کن، تیکتها رو بر اساس ریشه گروهبندی کن، بخش تکراری رو خودکار کن و قضاوت رو نگه دار.
