معظم المطورين يقيمون وكلاء البرمجة بالذكاء الاصطناعي (AI coding agents) بطريقة خاطئة. يقومون بتثبيت ثلاث أدوات، ويفتحون واجهة الأوامر (terminal)، ثم يشغلون نفس الأمر التجريبي البسيط: أنشئ لي صفحة هبوط. ثم يختارون أي مخرج يبدو الأجمل. هذا الاختبار لا يخبرك تقريبًا بأي شيء عن كيفية أداء هذه الأنظمة داخل قاعدة كود (codebase) حقيقية.

السؤال الأفضل ليس أي نموذج حقق أعلى درجة في اختبارات البرمجة المرجعية (coding benchmark). بل السؤال هو أي نظام يمكنه أخذ الذكاء الخام وتطبيقه فعليًا على مشاريع برمجية فوضوية ومتعددة الملفات. يوفر النموذج "الدماغ"، بينما يوفر "الإطار" (the harness) — إدارة السياق، والوصول إلى الأدوات، ومعالجة الأخطاء، وطبقات الأذونات — "اليدين والعينين". فالدماغ العبقري مع يدين خرقاء سيعطل كود الإنتاج الخاص بك بنفس سرعة الدماغ المتوسط.

إليك ما يميز الأدوات الرائدة فعليًا عندما تتجاوز مرحلة العروض التجريبية المبتكرة وتنتقل إلى العمل الهندسي.

الإطار هو المنتج

يحدد إطار الوكيل (agent harness) كيفية عمل الذكاء داخل المستودع (repository). فهو يتحكم في مقدار السياق الذي يتذكره الوكيل، والملفات التي يمكنه لمسها، وكيفية تعافيه من أمر فاشل في واجهة الأوامر، وما إذا كان يعرف متى يتوقف قبل حذف ملف .env الخاص بك. قد يعمل وكيلان بنماذج ذات درجات مرجعية متشابهة، ولكن إذا فقد أحدهما تتبع العلاقات عبر الوحدات (modules) بعد تعديل ثلاثة ملفات، بينما حافظ الآخر على خريطة متماسكة لهيكلية مشروعك، فإن الثاني سينهي عملية إعادة الهيكلة (refactor) بينما سيتسبب الأول في حدوث تراجعات (regressions).

فكر في الأمر على هذا النحو: النموذج هو المحرك، لكن الإطار هو نظام التعليق والمكابح والتوجيه. القوة لا تعني شيئًا إذا لم تتمكن من البقاء على الطريق.

Claude Code: استنتاج عميق للمستودعات

يتألق Claude Code عندما تحتاج إلى فهم قاعدة كود معقدة بدلاً من مجرد إضافة كود إليها. تكمن قوته في الحفاظ على نموذج ذهني للعلاقات عبر الوحدات (modules). إذا كنت تتبع خطأً (bug) يبدأ في برمجية وسيطة للمصادقة (authentication middleware)، وينتقل عبر غلاف قاعدة بيانات (database wrapper)، ويظهر في أداة تحقق (validation utility)، فإن Claude Code يميل إلى الحفاظ على تسلسل الخيط. وهو مفيد بشكل خاص للتخطيط لعمليات إعادة هيكلة كبيرة حيث تحتاج إلى إعادة تسمية واجهة برمجة تطبيقات (API) داخلية، وتحديث كل مستهلك لها، وتعديل الاختبارات دون نسيان استيراد (import) مخفي في مجلد أدوات منسي.

الطريقة العملية لتحقيق أقصى استفادة منه هي استخدام ملف CLAUDE.md في جذر مشروعك. تعمل هذه الوثيقة كذاكرة مؤسسية يمكنك تقنينها. قد تحدد أن جميع عمليات تسجيل السجلات (logging) يجب أن تستخدم الغلاف الداخلي بدلاً من console.log ، أو أن عمليات ترحيل قاعدة البيانات (database migrations) تعيش فقط في /infra/migrations ، أو أن كل مكون React جديد يحتاج إلى ملف Storybook مطابق. بدون هذا الحاجز الواقي، سينحرف أي وكيل نحو الإعدادات الافتراضية لتدريبه. ومع وجوده، يمكن لـ Claude Code احترام الاصطلاحات التي استغرق فريقك شهورًا لترسيخها.

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

OpenAI Codex: الأتمتة المنظمة

تم بناء Codex للفرق التي تحتاج إلى نتائج قابلة للتكرار على نطاق واسع. فبينما يميل Claude Code نحو الاستكشاف، يميل Codex نحو الأتمتة. إنه يعمل بشكل أفضل عندما يكون لديك مهام محددة بوضوح تحتاج إلى إدراجها في أنظمة الفريق الحالية: إنشاء كود أساسي (boilerplate) لخدمة مصغرة (microservice) جديدة، أو بناء هياكل نقاط نهاية CRUD مع مجموعة البرمجيات الوسيطة الخاصة بك، أو تحديث ملفات التكوين عبر مجموعة من الخدمات.

العائق هو أنك بحاجة إلى أن تكون دقيقًا. إذا كانت معايير القبول لديك غامضة، فسيقوم Codex بكل سرور بإنشاء كود يعمل تقنيًا ولكنه ينتهك اصطلاحاتك. حدد الهيكل، وقواعد التسمية، ونمط معالجة الأخطاء، وتوقعات الاختبار مسبقًا. في تلك البيئة، يتصرف Codex بشكل أقل مثل مبرمج مساعد (pair programmer) وأكثر مثل خط تجميع يفهم تعليمات اللغة الطبيعية. وهذا يجعله قويًا للأدوات الداخلية، وسير العمل المرتبط بـ CI، وأي موقف تكون فيه الاتساق أهم من حل المشكلات الإبداعي.

Gemini CLI: سير عمل مفتوح وقابل للبرمجة النصية

يتخذ Gemini CLI شكلًا مختلفًا تمامًا. فهو ليس مساعد برمجة حواريًا بقدر ما هو مكون قابل للتوسيع داخل بيئة واجهة الأوامر الخاصة بك. إنه قابل للبرمجة النصية (scriptable) بدرجة عالية، مما يعني أنه يمكنك تمرير مخرجاته إلى سير عمل Unix القياسي، وربطه مع grep أو awk أو jq ، وبناء سلاسل أدوات مخصصة لا تتطلب منك النسخ واللصق بين نوافذ الدردشة.

هذه الانفتاحية تهم المهندسين الذين يتعاملون مع الطرفية (terminal) كواجهة أساسية لهم. قد تستخدمها لإنشاء رسائل الالتزام (commit messages) تلقائيًا من الفروقات المرحلة (staged diffs)، أو لإعادة كتابة سكربتات shell القديمة إلى Python مع شروحات مضمنة، أو لتلخيص مخرجات السجلات (logs) من حاوية Kubernetes pod فاشلة. كما أن وضع عدم التفاعل (non-interactive mode) الخاص بها عملي للغاية في خطوط أنابيب التكامل المستمر (CI pipelines)؛ حيث يمكنك تضمينها في GitHub Action أو خطوة في Makefile لإجراء تحويلات برمجية خفيفة، أو إنشاء مقتطفات من التوثيق من المصدر، أو تنقية مخرجات الأخطاء قبل نشرها في قناة Slack.

إذا كان سير عملك مبنيًا بالفعل حول سكربتات shell والأدوات القابلة للتركيب، فإن Gemini CLI سيندمج معك دون أن يطلب منك تغيير عاداتك.

العمل الذي يهم حقًا

تكشف الأبحاث حول معدلات قبول وكلاء الذكاء الاصطناعي (AI agents) عن نمط لن يفاجئ المهندسين ذوي الخبرة: يتم الموافقة على تغييرات التوثيق (documentation) بشكل أكبر بكثير من العمل على الميزات الجديدة. إن تحديث الـ docstrings، أو تصحيح التعليقات، أو توسيع ملف README يلعب على نقاط قوة الوكيل لأن السياق محدود والأسلوب محدد مسبقًا في المستودع (repository). أما العمل على الميزات الجديدة فيتطلب ابتكارًا، وتوقعًا لحالات الحافة (edge cases)، وفهمًا لنية المستخدم التي قد لا تكون مكتوبة في أي مكان. لا توجد أداة واحدة تتفوق في الفئتين معًا لأن متطلبات بيئة التشغيل (harness requirements) مختلفة جوهريًا.

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

أين تفشل الوكلاء فعليًا

تحدث معظم الإخفاقات في طبقة التنفيذ، وليس في طبقة النموذج. قد يكون الكود مثاليًا من الناحية النحوية، ولكن الوكيل قد ينهار بسبب انتهاء مهلة الشبكة (network timeout) لواجهة برمجة تطبيقات (API) داخلية، أو أمر sed يعمل على macOS ولكنه يفشل على GNU/Linux، أو حدود صلاحيات لا يتعرف عليها. يواجه الوكلاء صعوبة عندما:

  • تعيد واجهة برمجة التطبيقات (API) فشلاً عابرًا، فتدخل الحلقة في دوران مستمر بدلاً من التراجع (backing off).
  • تعيد الأداة تدفق أخطاء (error stream) منسقًا بطريقة يسيء الوكيل تفسيرها.
  • يتطلب الأمر صلاحيات sudo لا يملكها الوكيل، مما يؤدي إلى توقف صامت (silent hang).
  • تنجح الاختبارات المولدة في العزل ولكنها تفشل عند تشغيلها بجانب قاعدة البيانات الحقيقية لأن بيئة التشغيل (harness) لم تظهر سلسلة الاتصال (connection string) بشكل صحيح.

هذه مشكلات تكامل. وهي تتطلب بيئة تشغيل (harness) تعرف كيفية قراءة الأخطاء، واحترام الحدود، وطلب التدخل البشري بدلاً من الاندفاع العشوائي للأمام.

كيفية تقييم هذه الأدوات بشكل حقيقي

توقف عن اختبار الوكلاء بطلبات مثل بناء صفحة هبوط (landing page)؛ فهذا يقيس المخرجات المرئية وليس القدرة الهندسية. بدلاً من ذلك، أخضع كل أداة لنفس الاختبار الصارم من المهام الحقيقية:

  • إصلاح خطأ يمتد عبر ملفات متعددة، حيث يوجد السبب الجذري والعرض في طبقات مختلفة من المكدس (stack).
  • إعادة هيكلة (Refactor) وحدة برمجية لإزالة تبعية مهجورة (deprecated dependency) دون تغيير السلوك الخارجي، ثم التحقق من أن مجموعة الاختبارات لا تزال تنجح.
  • تحديث كل mock fixture، وتعريف نوع (type definition)، واختبار تكامل (integration test) بعد أن تقوم واجهة برمجة تطبيقات خارجية بتغيير شكل استجابتها.
  • تشخيص بناء (build) معطل ناتج عن تعارض في الإصدارات واقتراح إصلاح يمكن تجميعه (compile) فعليًا.

تتبع المقاييس الملموسة (hard metrics)، وليس مجرد الانطباعات (vibes). احسب معدل الإكمال: هل أنهى الوكيل المهمة أم استسلم في منتصف الطريق؟ سجل عدد التصحيحات البشرية المطلوبة قبل أن يصبح الكود قابلًا للدمج (mergeable). تحقق مما إذا كانت الاختبارات قد نجحت من المحاولة الأولى أم احتاجت إلى جولات متعددة من الترقيع. قس الوقت الذي قضاه مهندس خبير في مراجعة المخرجات. إن الأداة التي تكتب مائتي سطر من الكود الخالي من العيوب لا قيمة لها إذا كنت تقضي ساعة في التحقق من أنها لم تلمس ملفات كان يجب تركها وشأنها.

الخلاصة الحقيقية

الأداة الفائزة ليست تلك التي تولد أكبر عدد من الرموز أو العروض التوضيحية الأكثر بهرجة. بل هي الأداة التي تنتج أكثر قدر من الكود القابل للدمج بأقل قدر من صعوبة المراجعة. المنافسة في هذا المجال تتحول من ذكاء النموذج الخام إلى أطر الهندسة الموثوقة (reliable engineering harnesses). اختر الوكيل الذي يتوافق تصميم نظامه مع طبيعة عملك الفعلي: التفكير العميق للجراحة المعمارية (architectural surgery)، أو الدقة المنظمة لأتمتة الفرق، أو قابلية التوسع في الطرفية (terminal) لسير العمل المخصص. ثم اختبره على إخفاقات حقيقية، وليس على مشكلات تجريبية بسيطة.

يعتمد هذا التحليل على مقارنات مباشرة وأبحاث حول سلوك الوكلاء موصوفة في هذا التحليل المفصل.

لمزيد من النقاشات حول الأدوات الهندسية وسير عمل الذكاء الاصطناعي، انضم إلى مجتمع GyaanSetu التعليمي.