Google تستخدم Gemini 4 Argon لإعادة هيكلة Chromium بملايين الأسطر البرمجية

نشرت Google DeepMind مقطع فيديو يشرح كيف يستخدم فريق Chromium نموذج Gemini 4 Argon في صيانة واحدة من أثقل قواعد الكود البرمجي في عالم المصدر المفتوح. المعطيات المتاحة متواضعة: «ملايين الأسطر» و«عقود» من التاريخ. ولا يتضمن المحتوى أرقامًا دقيقة، مثل عدد التعديلات التي جرى دمجها، أو نسبة الرقع المقبولة، أو ساعات العمل التي جرى توفيرها. لكنه يصف آلية العمل جيدًا، وهي أكثر إثارة للاهتمام من النموذج نفسه.

ما الذي يفعله Gemini 4 Argon تحديدًا في Chromium

بحسب DeepMind، تجعل بنية Chromium العمل عليه أشبه بالتنقل بين ميزات متشابكة. فإذا لمستَ مكوّنًا واحدًا، تعطّل مكوّن آخر على نحو غير متوقع. ويستخدم إريك تشين، مهندس Google، نموذج Gemini 4 Argon من أجل «فك تشابك» هذه البنية. أي أن الأمر يتعلق بإعادة هيكلة: تتغير بنية الكود ويبقى السلوك كما هو.

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

كيف تُضبط الجودة

السؤال الرئيسي في أي إعادة هيكلة بالذكاء الاصطناعي داخل قاعدة كود ضخمة هو: من يضمن أن شيئًا لم يتعطل؟ تذكر DeepMind مستويين من الحماية:

• مجموعات اختبار Chromium التي تمر عبرها تعديلات الوكلاء؛
• مراجعة الكود من مهندسي Chromium.

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

ما المعروف من المادة

• النموذج: Gemini 4 Argon، وقد أحالت Google تفاصيله إلى منشور مستقل في مدونتها.
• الهدف: قاعدة كود Chromium، ملايين الأسطر وعقود من التاريخ.
• المنفّذون: عدة وكلاء يعملون بشكل مستقل.
• التحقق: اختبارات Chromium ومراجعة المهندسين.
• الهدف المعلن: تفريغ فريق إريك تشين للعمل على مستقبل Chromium.
• لم يُكشف عنه: حجم التعديلات، ونسبة الرقع المرفوضة، وتكلفة عمليات التشغيل، وعدد الأخطاء التي رصدتها الاختبارات.

كيف نقرأ هذه الحالة

صدرت المادة عن DeepMind نفسها، وهي واجهة لعرض قدرات النموذج وليست تدقيقًا مستقلًا. أما القول إن «الوكلاء يصونون قاعدة الكود» فلا يستند حتى الآن إلا إلى وصف العملية. ولن تُظهر القيمة الحقيقية إلا الأرقام: كم تعديلًا وصل إلى الفرع الرئيسي، وكم من الوقت يقضيه المراجعون في فحص رقع الوكلاء مقارنة بتعديلات البشر. فالمراجعة أيضًا مورد محدود، وإذا أغرقها سيل من الرقع الآلية فسيتلاشى المكسب.

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

الخلاصة العملية للفرق

إذا كان لديكم مشروع قديم ضخم، فالأجدر أن تأخذوا من حالة Chromium آلية العمل لا اسم النموذج. تأكدوا أولًا أن تغطية الاختبارات تسمح بالوثوق بنجاح البناء (اللون الأخضر). ثم قسّموا إعادة الهيكلة إلى مهام مستقلة كي لا يتنازع الوكلاء على الملفات نفسها. وأبقوا المراجعة البشرية خطوة إلزامية، وابدؤوا من اليوم الأول بجمع مقاييس الرقع المقبولة والمرفوضة. فمن دونها يتعذر معرفة ما إذا كان الوكيل يوفّر الوقت أم يكتفي بنقل العبء إلى المراجعين.