رحلة اختيار وكيل

خلال الفترة الماضية، كانت -ولا زالت- هذه الشاشة الرئيسية في عملي. فقد سئمتُ التنقل كل فترة بين أداة وأخرى، ووكيل وآخر، وأضناني البحث عن تلك الأداة المثلى التي تغنيني عن سواها. فعزمتُ أن ألزم جميع هذه الأدوات مرة واحدة لإسبوعين كاملين؛ لأنظر إلى ما أنتهي إليه. وقد خبرتُ في هذه الرحلة وكلاء أُخر غير ما في الصورة، مثل OpenCode وGoose وCrush، وخلُصتُ في هذه المدة إلى قناعات عدة رسخت في نفسي.

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

حين يخفق الوكلاء

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

كانت المهمة عسيرة، لا سيما أن محاكي المتصفح DOM Emulator الذي تستخدمه بيئة الاختبارات لا يدعم بعض الخصائص التي تعتمد عليها المكتبة اعتمادًا كليًا. وهنا بدأت المعركة الحقيقية. أوكلتُ المهمة لوكيل Claude Code GLM، فبدأ بداية حسنة، ثم ما لبث أن وصل إلى هذه النقطة الشائكة، فبدأ يتخبط. وبدلًا من أن يقترح حلولًا بديلة وعملية، راح يحتال على القصور في محاكي المتصفح وعدل الشفرة الأساسية لتتماشى مع الاختبار! وهذا في عرفنا خطيئة كبرى!

خلاصات

خلال الفترة الماضية، خرجتُ بأربع قناعات، أرى لزامًا عليَّ بسطها:

هيمنة الطرفية

قبل أن اجرب الوكلاء المذكورين، انتقلت بين الوكلاء المدمجين في المحررات وجربت إضافات المحررات كـ Cline وRoo Code وغيرهم، وأرى أن وكلاء سطر الأوامر هم الخيار الأمثل على المدى الطويل. فالمحررات القائمة بذاتها، مثل Windsurf أو Cursor، بحاجة إلى واجهة رسومية، ولا يمكنك نقلها إلى سيرفر والعمل هناك -وهذه حالة احتاجها- ففيهم المرونة الكافية للعمل.

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

النموذج الوكيل

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

بدايةً، اكتشفتُ أن "Grok" غير متاح في منطقتي، مما حتَّم عليَّ استعمال VPN. فوقع اختياري على "ProtonVPN"، لأجد أن موقعه هو الآخر يتطلب VPN آخر للدخول إليه وإنشاء حساب! وبعد كل هذا العناء، تمكنتُ أخيرًا من الاشتراك والدفع، لكن النتيجة كانت مخيبة للآمال؛ فشل الوكلاء الثلاثة -OpenCode وGoose وCrush- في تشغيله تشغيلًا يُعتمد عليه. لم ينجح الأمر إلا مرة واحدة يتيمة مع OpenCode، ثم لم يعمل بعدها. وذهب جهدي هدرًا.

هل يعني هذا أن نموذج "Grok" رديء؟ قطعًا لا. فقد جربته مع Cursor-Agent، والذي يقدم "Grok" بدعم مثالي. إن الخلل يكمن في غياب التوافق التام بينه وبين الوكلاء متعددي النماذج الذين لم يُبنوا له خصيصًا. لقد كانت هذه التجربة خير برهان على أن قوة النموذج وحدها لا تكفي، بل لا بد لها من وكيل مُحكَم يُخرج أفضل ما فيها، وإلا بقيت حبيسة إمكاناتها النظرية.

ليس كل ما يلمع ذهبًا

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

الهروب من Gemini والعودة إليه

من بين النماذج التي تُعدُّ مجانية أو رخيصة، لعل Gemini هو أفضلها بلا منازع (وقد خبرته فترة طويلة قبل أن انتقل لغيره). لقد انصب اهتمامي في المدة الماضية على ثلاثة: وكيل Gemini المجاني (الذي يستعمل غالبًا نموذج "Gemini Flash")، ووكيل Cursor-Agent في وضعه التلقائي -وما أعجب الشبه بين النتائج عند التبديل بين التلقائي ونموذج Grok حتى في نوعية الأخطاء-، ووكيل Claude Code بنموذج "GLM v4.5".

وما لاحظته أن بين Gemini والوكلاء الآخرين فرقًا كبيرًا، وأنه يُعوَّل عليه كثيرًا حتى في استخدامه المجاني. أما الفرق بين Cursor-Agent وClaude Code GLM فكان يسيرًا، ولعل الأول أفضل قليلًا، إلا أني لاحظت أنه يشرع في الهذيان بعد مدة، فيبدأ بتكرار المخرج ذاته بلا نهاية، حتى أضطر إلى إغلاقه إغلاقًا قسريًا. أما مع الثاني، فكانت التجربة مستقرة تمامًا.

وهنا أعود للتنويه أن كل عملي في الويب، فأحد زملائي خلص إلى أن Claude Code GLM لا قيمة له أمام "Cursor Auto".

من مطور إلى مدير مشروع

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

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

خاتمة

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