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

اگر برنامه‌نویسی هستید که برای یافتن باگ‌ها در Pull Requestها به هوش مصنوعی تکیه می‌کنید، احتمالاً دسته‌ای کامل از خطاها را از دست می‌دهید که فقط هنگام اجرای واقعی کد ظاهر می‌شوند. در ۱۷ ژوئن ۲۰۲۶، شرکت Greptile معماری TREX (مخفف Test, Run, Execute) را معرفی کرد؛ سیستمی که هدفش انتقال بررسی کد از «خواندن ایستا» به «اجرای فعال» است.

سقف تحلیل ایستا

برای دهه‌ها، بررسی کد تغییری بنیادین نکرده است. از مقاله سال ۱۹۷۶ مایکل فاگان در IBM که در آن توسعه‌دهندگان کدها را روی کاغذ چاپ کرده و خط‌به‌خط می‌خواندند تا امروز که ما Diffها را روی نمایشگر می‌بینیم، منطق کار یکی است. در دوران فاگان، برنامه‌نویسان در یک اتاق جمع می‌شدند و کدها را به صورت دستی بررسی می‌کردند. امروز، با وجود اینکه هوش مصنوعی سرعت این فرآیند را افزایش داده است، اما اکثر ابزارها همچنان فقط Diffها را می‌خوانند.

این وضعیت یک سقف سخت ایجاد می‌کند: تحلیل ایستا می‌تواند بفهمد کد چه «می‌گوید»، اما نمی‌تواند بگوید کد چه «می‌کند». این رویکرد برای باگ‌هایی که به وضوح در متن کد اعلام شده‌اند مفید است، اما دسته‌ای کامل از باگ‌ها را که فقط در زمان اجرای برنامه وجود دارند، نادیده می‌گیرد. نمونه‌هایی از این دسته‌ها عبارتند از:

• خطاهای منطقی که نیاز به توالی خاصی از وضعیت‌ها (State) دارند.
• نقص‌های رابط کاربری (UI) که فقط پس از بارگذاری کامل صفحه ظاهر می‌شوند.
• شرایط رقابتی (Race Conditions) که برای تحریک شدن، نیاز به یک درخواست واقعی دارند.

شما می‌توانید یک Diff را به طور کامل و بی‌نقص بخوانید و با این حال این نوع باگ‌ها را کاملاً از دست بدهید، زیرا آن‌ها در خودِ کد ظاهر نمی‌شوند.

معماری ارکستراسیون

طبق اعلام Greptile، آن‌ها ابتدا سعی کردند TREX را به عنوان یک عامل (Agent) مستقل برای تولید تست بسازند. اما متوجه شدند عامل‌های جداگانه، بافتار (Context) لازم برای یافتن باگ‌های مرتبط را ندارند. آن‌ها دریافتند که تولید تست با یافتن باگ دو فعالیت متفاوت است. وقتی عامل مستقل TREX سعی می‌کرد تست بنویسد، این تست‌ها با اهداف کاربر مرتبط نبودند و در نتیجه باعث ایجاد نویز غیرضروری و نادیده گرفتن موارد خاص (Edge Cases) می‌شد. یادگیری این درس بیش از آنچه انتظار می‌رفت زمان برد.

این جدایی همچنین باعث ناکارآمدی‌های فنی شد. چون عامل‌ها پنجره‌های متنی (Context Window) جداگانه‌ای داشتند، دانش خود را به اشتراک نمی‌گذاشتند. آن‌ها اغلب هم‌پوشانی داشتند و بخش‌های یکسانی از کد را دو بار بررسی می‌کردند که منجر به اتلاف منابع پردازشی می‌شد.

تلاش برای ترکیب همه در یک عامل واحد نیز شکست خورد؛ چون عامل بیش از حد بارگذاری می‌شد. مدیریت کامل بررسی — شامل راه‌اندازی سرویس‌ها، گرفتن اسکرین‌شات و اجرای تست‌ها — حجم اطلاعاتی ایجاد می‌کرد که برای یک عامل واحد، مدیریت تمیز آن غیرممکن بود.

برای حل این مشکل، Greptile یک ساختار سلسله‌مراتبی پیاده کرد. در این مدل، بررسی‌کننده اصلی به عنوان یک ارکستراتور (Orchestrator) عمل می‌کند. او Diff را می‌خواند، نقاط پرریسک را شناسایی می‌کند و سپس زیر-عامل‌های TREX را به‌صورت موازی برای بررسی مسائل خاص فعال می‌کند. این اولین باری بود که تیم Greptile موفق شد عامل‌ها را از درون یک عامل دیگر مدیریت کند.

این زیر-عامل‌ها برخلاف مدل‌های مستقل، بافتار ارکستراتور را به ارث می‌برند. آن‌ها از صفر شروع نمی‌کنند، بلکه روی مسئله‌ای خاص متمرکز می‌شوند که از آن‌ها خواسته شده بررسی کنند. این ساختار به آن‌ها اجازه می‌دهد تسک‌های پیچیده تنظیمات — مانند عبور از گیت‌های احراز هویت یا پیکربندی Feature Flagها — را بدون شروع مجدد انجام دهند. برای مثال، یک زیر-عامل می‌تواند به تنهایی راه عبور از یک گیت احراز هویت را پیدا کند و اسکرین‌شاتی از یک قابلیت رندر شده برگرداند.

اعتماد از طریق مصنوعات چندوجهی

Greptile دریافت که خلاصه‌های متنی (Bullet-point) از نتایج تست، ناکافی و مستعد توهم (Hallucination) هستند. جمله‌ای مثل «جریان پرداخت تست شد و خطا داشت» هیچ کاربردی ندارد، زیرا توضیح نمی‌دهد فرآیند در کجا شکست خورده است؛ آیا مشکل در تنظیمات بود، در تاییدیه (Assertion) یا یک مشکل محیطی؟ علاوه بر این، عامل‌ها گاهی ادعا می‌کردند چیزهایی را تست کرده‌اند که در واقع انجام نداده بودند. خلاصه‌های متنی هیچ راهی برای تایید این ادعاها به تیم نمی‌دادند.

برای تضمین اعتبار، TREX اکنون برای هر یافته، مجموعه‌ای از مصنوعات چندوجهی (Multi-modal Artifacts) تولید می‌کند:

• اسکرین‌شات‌ها و ویدیوها: ثبت واقعی رندرهای UI و تغییرات انیمیشن. اگر کاربر تغییری در انیمیشن ایجاد کند، TREX ویدیویی از اجرای آن می‌گیرد تا بررسی‌کننده بدون نیاز به باز کردن محیط محلی، نتیجه را ببیند.
• لاگ‌ها و ردپای API: ارائه مسیر دقیق اجرا برای حذف حدس و گمان.
• اسکریپت‌های اجرا: ارائه اسکریپت‌های استفاده شده تا یک انسان یا عامل پایین‌دستی بتواند خودشان اجرا را بازتولید و تایید کنند.

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

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

سندباکس مدل-ناشناس

به دلیل تغییر سریع مدل‌های پیشرو، Greptile سیستم TREX را به‌صورت مدل-ناشناس (Model-Agnostic) طراحی کرده است. این یعنی آن‌ها می‌توانند ارائه‌دهنده مدل را بدون بازسازی کل سیستم تغییر دهند. این انعطاف‌پذیری عمیق است: ارکستراتور اصلی و زیر-عامل‌ها می‌توانند هم‌زمان از ارائه‌دهندگان مختلف در یک بررسی واحد استفاده کنند. این به Greptile اجازه می‌دهد بر اساس ارزیابی‌های داخلی، بهترین مدل را در هر لحظه انتخاب کند.

Greptile مدل‌ها را بر اساس دو معیار ارزیابی می‌کند:

• فراخوانی (Recall): اندازه‌گیری اینکه چه تعداد از باگ‌های واقعی شناسایی شده‌اند (تست شده روی داده‌های مشتری یا PRهای متن‌باز که کامنت‌های آن‌ها پاسخ داده شده بود).
• دقت (Precision): اندازه‌گیری ثبات در اجراها؛ اگر یک PR دو بار بررسی شود، آیا تقریباً مجموعه یکسانی از مسائل پیدا می‌شود؟

جالب اینجاست که آن‌ها عمداً سرعت (Latency) را اولویت قرار نداده‌اند. به باور تیم Greptile، برنامه‌نویس ترجیح می‌دهد کمی بیشتر منتظر بماند و پاسخی دقیق و قابل‌اعتماد بگیرد تا اینکه پاسخی سریع اما غیرقابل‌اعتماد دریافت کند. سیستم ارزیابی متن‌باز آن‌ها عملکردی مشابه با سیستم‌های ارزیابی خودِ ارائه‌دهندگان دارد، به این معنی که مدل-ناشناس بودن باعث کاهش کیفیت نشده است.

برای امنیت و سرعت، هر بررسی در یک محیط ایزوله (Sandbox) و یک‌بار مصرف اجرا می‌شود. این نمونه‌های پردازشی ایزوله در چند میلی‌ثانیه شروع شده و پس از اجرا نابود می‌شوند. این‌ها صرفاً شبیه‌ساز (Mock) برای تست‌های واحد نیستند، بلکه سرویس‌های واقعی با وابستگی‌های واقعی‌اند، زیرا بسیاری از باگ‌ها فقط در حالت End-to-End ظاهر می‌شوند.

برای جلوگیری از کندیِ شروع سرد (Cold Start)، Greptile از استراتژی‌های زیر استفاده می‌کند:

• تصاویر پایه (Base Images) قابل استفاده مجدد برای حفظ سرعت.
• اسنپ‌شات‌های هر مخزن (Repository) که اجازه می‌دهد یک مخزن یک‌بار کلون، ذخیره و سپس بازیابی شود.
• چرخش پویا در اعتبارنامه‌ها برای تضمین امنیت پیش از شروع اجرا.

این تعادل تضمین می‌کند که کش (Cache) «به اندازه کافی گرم باشد تا سریع حرکت کند و به اندازه کافی تازه باشد که بتوان به آن اعتماد کرد»، تا از ایجاد یک کش «تسخیر شده» که شامل وضعیت‌های قدیمی و منقضی شده است، جلوگیری شود. کشی با اطلاعات کم کند است و کشی با اطلاعات بیش از حد، غیرقابل‌اعتماد می‌شود.

این زیرساخت تضمین می‌کند که وقتی TREX گزارشی از به‌هم‌ریختگی چیدمان (Layout) می‌دهد، این یک مشاهده واقعی از یک محیط زنده است، نه یک حدس احتمالی بر اساس الگوهای کد. سندباکس همان چیزی است که مصنوعات را قابل‌اعتماد می‌کند.

حرکت به سوی اعتبارسنجی خودکار

این سیستم نشان‌دهنده تغییری در نحوه تعامل هوش مصنوعی با چرخه توسعه نرم‌افزار است. این اجزا — معماری زیر-عامل، استاندارد تایید مصنوعات، محیط سندباکس و سیستم ارزیابی — به عنوان یک سیستم واحد عمل می‌کنند:

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

هر جزء، اجزای دیگر را ارزشمندتر می‌کند. Greptile در حال تبدیل شدن از یک «ابزار بررسی کد» به یک «مجموعه اعتبارسنجی» (Validation Suite) است. هدف، خودکارسازی فرآیند تایید End-to-End است که تیم‌های مهندسی دهه‌ها به صورت دستی انجام می‌دادند، با چشم‌انداز نهایی دنیایی بدون باگ.

همزمان با تبدیل شدن هوش مصنوعی به یک کالای عمومی (Commoditize)، تمایز واقعی در زیرساخت‌ها — یعنی ایندکس‌گذاری کد، ارکستراسیون و خط لوله‌های تولید مصنوعات — ایجاد می‌شود که اجازه می‌دهد آن هوش بر روی اجرای واقعی کد اعمال شود. هوش مدل‌ها به طور مداوم بهبود می‌یابد، اما این «هارنس» یا چارچوب زیرساختی است که در عمل تفاوت ایجاد می‌کند.