Google Jules: ماذا يفعل وكيل البرمجة غير المتزامن، وما الذي لا يستطيع إثباته؟

ما هو Google Jules؟

Google Jules هو وكيل برمجة غير متزامن يعمل بالاعتماد على Gemini. أُتيح في مرحلة تجريبية عامة في 20 مايو 2025، مع تشغيل مهام على مستوى المستودع داخل آلة افتراضية آمنة على Google Cloud. 24 ثم خرج من المرحلة التجريبية وأطلقت Google مستويات استخدام منظمة في 6 أغسطس 2025. 14

فكرة Jules بسيطة: تسند إليه مهمة من مستودع GitHub، ثم تتركه يعمل في الخلفية وتعود لاحقًا لمراجعة النتيجة. ووفق توثيق Google، ينشئ الوكيل بيئة جديدة داخل آلة افتراضية، يثبت الاعتماديات، يكتب الاختبارات أو يحدّثها، يعدّل الكود، يشغّل الفحوص المتاحة، ثم يفتح طلب دمج (Pull Request) للمراجعة. وتشمل المهام المدعومة إصلاح الأخطاء، وتحديث الاعتماديات، وترحيل الكود، وإضافة ميزات جديدة. 18

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

كيف يعمل Jules؟

1. يربط المطور مستودع GitHub ويصف المهمة المطلوبة.
2. يفحص Jules المشروع ويضع خطة لتنفيذها.
3. ينسخ قاعدة الكود إلى آلة افتراضية معزولة ويثبت اعتماديات المشروع.
4. يعدّل الملفات، ويكتب الاختبارات أو يحدّثها، ثم يشغّل الفحوص المتاحة.
5. يعرض التغييرات في طلب دمج ينتظر قرار الفريق البشري. 18

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

أسعار Jules وحدود المهام

تعرض صفحة الاستخدام الرسمية من Google ثلاثة مستويات وصول. وتُحتسب الحدود ضمن نافذة متحركة مدتها 24 ساعة، لا وفق وقت إعادة ضبط يومي ثابت بالضرورة. 1

الخطة	المهام خلال 24 ساعة متحركة	المهام المتزامنة	إتاحة النماذج بحسب Google
الوصول التمهيدي	15	3	Gemini 2.5 Pro
Jules ضمن Google AI Pro	100	15	وصول أعلى إلى النماذج الأحدث، بدءًا من Gemini 3 Pro
Jules ضمن Google AI Ultra	300	60	أولوية في الوصول إلى النماذج الأحدث، بدءًا من Gemini 3 Pro

تقدم Google خطة Pro للمطورين الذين يستخدمون البرمجة بالذكاء الاصطناعي يوميًا، بينما تستهدف Ultra أعباء العمل الأكبر والأكثر توازيًا. 9 وعند إطلاق المستويات المدفوعة في أغسطس 2025، أُدرجت Pro وUltra ضمن اشتراكات Google AI الأوسع، بسعرَي 19.99 دولارًا و124.99 دولارًا شهريًا على التوالي. 13 وبما أن الأسعار والأهلية قد تتغير، ينبغي التحقق من صفحة الخطط الحالية لدى Google قبل اعتماد هذه الأرقام في قرار شراء أو ميزانية مؤسسية.

يجعل نظام التسعير القائم على عدد المهام تجربة Jules سهلة نسبيًا. فالحد التمهيدي يكفي لاختبار قدرة الوكيل على التعامل مع مستودعات الفريق، بينما تهم القدرة على تشغيل مهام متزامنة عند توزيع أعمال صيانة مستقلة أو معالجة قائمة طويلة من المهام المحددة. ومع ذلك، لا تقيس الحصة العددية القيمة الهندسية وحدها؛ فقد يستهلك طلب دمج ضعيف قدرًا قليلًا من السعة، لكنه يضيف عبئًا أكبر على المراجعين.

أين يقف Jules مقارنة بالمنافسين؟

ينافس Jules في سوق تنتقل فيه أدوات البرمجة بالذكاء الاصطناعي من اقتراح الأسطر إلى التخطيط والتعديل والاختبار وإرسال التغييرات. ويتمثل تموضعه الأساسي في التنفيذ غير المتزامن عبر المستودع بأكمله؛ إذ يستطيع المطور وضع عدة مهام في قائمة الانتظار والعودة لاحقًا لفحص النتائج.

لكن هذا الأسلوب لم يعد ميزة حصرية. فوكيل GitHub Copilot السحابي يقدم مسارًا قريبًا: يستجيب للمشكلات المسندة إليه، وينشئ فروعًا، ويكتب الكود، ويفتح طلبات دمج من بيئة مؤقتة معزولة بجدار حماية، مع فحص أمني آلي. 17

لذلك لا ينافس Jules على أساس «الاستقلالية» وحدها، بل على جودة العمل المدعوم بـGemini، وفهم سياق المستودع، وبيئة التنفيذ، والتكامل مع منظومة Google، وكمية الأدلة التي يرفقها بكل تغيير. وفي المقابل، تركز وثائق Anthropic على استخدام Claude Opus 5 في مهام البرمجة الوكيلة الصعبة والطويلة، بما في ذلك الميزات متعددة الملفات وعمليات إعادة الهيكلة الكبيرة. 28

وعند اختيار أداة مناسبة، قد يكون السؤال العملي أقل ارتباطًا بـ«أي وكيل هو الأكثر استقلالية؟» وأكثر ارتباطًا بالأسئلة التالية:

• أي أداة تنسجم مع طريقة الفريق في استخدام GitHub وإدارة الفروع؟
• هل يمكن تشغيلها بأمان مع اعتماديات المشروع وسياسة الأسرار والصلاحيات؟
• هل تعرض خطتها وخطوات تنفيذها بما يكفي لتسهيل المراجعة؟
• هل تستطيع أنظمة التكامل المستمر والأمن المستقلة رفض التغيير السيئ؟
• هل تحقق نتائج جيدة على مستودعات الفريق الفعلية، لا على الاختبارات العامة فقط؟

واجهة سطر الأوامر وواجهة API والاقتراحات والمهام المجدولة

يشير اتجاه تطوير Jules إلى منتج يتجاوز واجهة الويب والمهام الفردية. فقد تلائم واجهة سطر الأوامر بيئات التطوير المحلية أو مسارات التكامل المستمر، بينما قد تسمح واجهة برمجة التطبيقات للأنظمة الداخلية بإرسال المهام ومتابعتها. كما يمكن للاقتراحات الاستباقية والمهام المجدولة تحويل أعمال الصيانة المتكررة، مثل تحديث الاعتماديات وتنظيف الاختبارات وعمليات البناء، إلى قائمة مستمرة من مهام الوكيل.

لكن الوثائق المرجعية المتاحة تؤكد بوضوح أكبر سير عمل المستودع وحدود الخطط، ولا تؤكد بالدرجة نفسها التوافر الحالي أو نطاق أو شروط المؤسسات لكل ميزة من ميزات سطر الأوامر وواجهة API والاقتراحات والجدولة. لذلك ينبغي التحقق من هذه التفاصيل في توثيق Google الحالي قبل بناء نظام أتمتة أو قرار شراء عليها.

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

لماذا لا تكفي نتيجة اختبارات ناجحة؟

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

توضح تقييمات مستقلة الفرق بين النجاح الوظيفي وجودة البرمجيات. فقد أفادت Sonar بأن Claude Opus 5 نجح في 88.6% من 544 مهمة اختبار قابلة للتنفيذ، مقارنةً بـ82.9% لـOpus 4.8. كما سجلت انخفاضًا في كثافة الأخطاء والثغرات لكل سطر، مع ملاحظة أن Opus 5 أنتج كودًا أكثر بـ2.3 مرة، وأن إجمالي النتائج المكتشفة ارتفع 2.7 مرة. 30

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

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

طبقات تحقق مستقلة للكود المولّد بالذكاء الاصطناعي

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

1. فروع محمية وموافقة بشرية إلزامية: يجب ألا يستطيع الوكيل دمج عمله بنفسه في الفروع الحساسة.
2. تكامل مستمر غير قابل للتلاعب أو خاضع لسيطرة منفصلة: لا ينبغي للوكيل إعادة كتابة الفحوص التي تحدد نجاح التغيير.
3. اختبارات تراجع وتكامل موجودة مسبقًا: يمكن لاختبارات أنشأها الوكيل أن تساعد، لكنها لا يجب أن تكون وسيلة التحقق الوحيدة.
4. تحليل أمني مستقل: يشمل تحليل الكود الساكن، وفحص الأسرار، والاعتماديات، وقائمة مكونات البرمجيات (SBOM)، والتراخيص، واختبارات أمن التطبيقات، على أن تعمل هذه الأدوات خارج حلقة التفكير الخاصة بالوكيل.
5. فحوص سياسات للتغييرات عالية المخاطر: تستحق تعديلات التفويض والوصول إلى البيانات والبنية التحتية وترحيل قواعد البيانات وإعدادات النظام قواعد تتجاوز اختبارات الوحدات المعتادة.
6. مسارات مراجعة منفصلة: يمكن لنموذج ثانٍ أو أداة تحقق البحث عن النواقص والتناقضات، مع إحالة الحالات غير الواضحة أو عالية التأثير إلى مسؤول بشري.

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

ماذا يعني Jules للمطورين؟

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

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

المنافسة المقبلة ستكون على الثقة

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

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