Netflix تسرّع وكلاء الذكاء الاصطناعي على Java: محرك IntelliJ وفّر 20–30%، وحتى 65% في أفضل الحالات

اكتشفت فرق Netflix (Application Development Platform وGenAI Platform وAgentic SDLC) كلفة غياب الفهم الحقيقي للشيفرة لدى وكلاء الذكاء الاصطناعي. فقد ربطت بكلٍّ من Claude Code وCodex نسخة بلا واجهة (headless) من محرك تحليل الشيفرة لدى JetBrains، وهو المحرك نفسه الذي تقوم عليه IntelliJ IDEA. وفي المهام الحقيقية استهلك الوكلاء رموزًا ووقتًا أقل بنسبة 20–30%، وبلغ الوفر في أفضل الحالات نحو 65%. ولم تنخفض صحة النتائج في أي قياس. أُجريت الاختبارات في يوليو–أغسطس 2026.

المشكلة: ملفات JAR التي يفقد الوكيل فيها بصيرته

تُوزَّع المكتبات في مشاريع JVM عادةً على شكل أرشيفات JAR بلا شيفرة مصدرية. ويضطر الوكيل إلى فك الأرشيفات بنفسه مخمِّنًا أيها مهم، ثم فك ترجمة ملفات class عند الحاجة، ثم البحث في هذه الصورة الناقصة عبر grep. والنتيجة بحث بطيء وغير موثوق، وتُهدر الرموز في التخبّط. ويصف بول بكر (Paul Bakker)، مهندس البرمجيات الأول (Staff Software Engineer) في Netflix، الوضع بأن وكلاء مثل Claude Code بطيئون وغير موثوقين في التنقل داخل Java/Kotlin، وخصوصًا عند حدود المكتبات.

بنت JetBrains على مدى سنوات فهرسًا حتميًا لمصادر المشروع مع جميع مكتباته. وهو متاح اليوم عبر LSP، بما في ذلك في المحررات المتوافقة مع VS Code. لكن LSP وحده ليس جاهزًا للوكيل، فهو خادم ببروتوكول لا يمكن استدعاؤه ببساطة من الوكيل، كما أنه يفتقر إلى إدارة العمليات لإعادة استخدام نسخة قيد التشغيل.

خدمة خلفية تُبقي الفهرس «دافئًا»

يستغرق بناء الفهرس وقتًا ملموسًا، كما يحدث عند فتح مشروع كبير لأول مرة في IntelliJ IDEA. أما الوكيل فيستدعي LSP عبر خطوات صغيرة كثيرة، وتحتاج المهمة الواحدة إلى عدة استدعاءات. وإذا شغّل كل استدعاء خادمًا جديدًا، دفع كل منها ثمن بدء بارد يستغرق عدة ثوانٍ، حتى لو بُني الفهرس قبل دقيقة.

لم تكن JetBrains قد أصدرت هذه الخدمة الخلفية (daemon) وقت التقييم، لذلك كتبتها Netflix بنفسها:

• كل استدعاء للأداة قصير العمر وبلا حالة، ويتوجّه ببساطة إلى CLI؛
• يوجّه مدير الجلسات في الخدمة الخلفية الاستدعاء بحسب جذر المشروع إلى عملية الخادم المناسبة التي تحتفظ بالفهرس في الذاكرة؛
• الاستدعاء المتكرر على المشروع نفسه يتجاوز الفهرسة ويتصل بالخادم «الدافئ» عبر stdio؛
• كُتبت الخدمة الخلفية وCLI بلغة Java وتُوزَّعان كملف تنفيذي GraalVM، فلا تترتب على بدء التشغيل أعباء JVM.

كيف جرى القياس وما النتيجة

كان التصميم بسيطًا: نموذج واحد، ومهمة واحدة، وقاعدة شيفرة واحدة، ومتغيّر واحد فقط هو: هل محرك JetBrains متاح للوكيل أم لا. واستُخدمت قاعدتا شيفرة حقيقيتان:

• خدمة إنتاجية داخلية متوسطة الحجم على Spring Boot 4 وGradle؛
• إطار DGS Framework المفتوح من Netflix، وهو إطار GraphQL مختلط بين Kotlin وJava.

انقسمت المهام إلى نوعين. الأول مهام تنقّل صغيرة: أين تُستخدم الواجهة، وما تطبيقاتها، وما بنية الصنف. والثاني مهام شاملة من البداية إلى النهاية: تنفيذ ميزة، وإعادة هيكلة صنف، وحذف شيفرة. أما تكوينات الوكلاء والنماذج فهي:

• Claude Code مع Opus 5 (جهد medium/high)؛
• Claude Code مع Sonnet 5 (جهد medium/high)؛
• Codex مع GPT-5.6 Sol (جهد medium/high).

كان المقياسان الرئيسيان استهلاك الرموز ووقت التنفيذ. وتولّى التحقق من الصحة LLM بدور الحَكَم: في المهام الشاملة بالمقارنة مع مجموعة مرجعية من التعديلات، وفي مهام التنقل بمقياس حتمي. واستُبعدت من المجموعتين معًا المهام التي فشلت، أو بلغت حد الميزانية، أو دخلت في حلقة تكرار في إحداهما على الأقل، حتى لا يشوّه إخفاق واحد المقارنة. وتكررت التشغيلات عدة مرات.

في مهام التنقل أنفقت جميع النماذج ومستويات الجهد رموزًا أقل، وكان أكبر مكسب للنموذج الأقوى. وبقيت الصحة في معظم التشغيلات على حالها، وارتفعت في تشغيلين، ولم تنخفض في أي منها. والشذوذ الوحيد أن إحدى توليفات الأداة والنموذج تجمّع عدة استدعاءات بحث في أمر واحد، فتجري استدعاءً واحدًا مع المحرك وبدونه. والرجوع إلى المحرك أبطأ قليلًا في حالتها، ولذلك لا مكسب في الوقت هناك، ولا تعدّ Netflix هذه النقطة ممثِّلة للعمل الفعلي. والأوثق النظر إلى المهام الشاملة، حيث كان المحرك أسرع لكل نموذج ولكل وكيل، ويُعزى جزء من الأثر إلى انخفاض عدد استدعاءات الأدوات للوصول إلى الاستنتاجات نفسها.

جاء أكبر مكسب مع النماذج القوية ذات مستوى الجهد العالي. فهي أغلى، ولذلك يكون الوفر عليها أثمن، وهي أقدر على العمل مع الفهرس. وتشدد Netflix على أن الأرقام لقطة آنية: فكل نموذج جديد يغيّر طريقة بحث الوكلاء واستدلالهم واستدعائهم للأدوات.

ما الذي استُبعد وإلى أين الاتجاه

قبل القرار النهائي استبعدت Netflix خيارين. الأول CLI داخلي خاص بها كان يتصل بنسخة IntelliJ IDEA قيد التشغيل: فهو يتطلب بيئة تطوير مفتوحة ولا يناسب البيئات بلا واجهة مثل Otto وBitbot وأدوات إعادة الهيكلة الموزعة وCI. والثاني Eclipse LSP الذي يُستخدم لـ Java في VS Code: ولم يعمل ببساطة مع بناء Gradle لدى Netflix.

وفي الخطوة التالية ستطبّق الشركة المنهجية نفسها على Python وTypeScript/JavaScript وGo، حيث يواجه الوكلاء مشكلات مشابهة، وإن اختلفت آلية تحميل المكتبات في هذه المنظومات. وقد أصدرت JetBrains بالفعل ذكاء Java الذي اختبرته Netflix ضمن إضافة Java & Kotlin by IntelliJ IDEA، وتواصل تجاربها على نهج LSP+CLI.

يشير أليكسي ستوكالوف (Alexey Stukalov)، رئيس اتجاه IDE في JetBrains، إلى نقطة ضعف في LSP نفسه: فالأساس فيه هو موضع المؤشر في النص، بينما يفكر الوكلاء بالرموز والتشخيصات وروابط الاختبارات والسلوك أثناء التشغيل. وموضع النص هش، إذ يتغير بإدراج حرف واحد. وبحسب قوله، لا يحتاج الوكلاء إلى محرر افتراضي، بل إلى محرك شيفرة بعمليات دقيقة على بنية البرنامج.

أما الخلاصة العملية للفرق التي تدفع فعلًا ثمن الوكلاء على JVM: إذا كانت الرموز على النماذج القوية تشكّل بندًا ملحوظًا في النفقات، فإن طبقة تحليل شيفرة حتمية إلى جانب الوكيل تُسترد كلفتها أسرع من ترقية النموذج. لكن لا توجد حتى الآن خدمة خلفية جاهزة للاستخدام مباشرة: فعليكم إما بناؤها بأنفسكم وفق مخطط Netflix، أو انتظار إصدار من JetBrains.