تعليم المطورين وتقييمهم في عصر الوكلاء

تعليم المطورين وتقييمهم في عصر الوكلاء

يعكس هذا التحليل مشهد التعليم والاعتماد اعتبارًا من 26 يوليو 2026.

مقدمة

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

يمكن لوكلاء البرمجة الحديثين فحص المستودعات، وتطوير خطة تنفيذ، وتعديل ملفات متعددة، وتشغيل الاختبارات، والاستجابة للأخطاء، وفتح طلب سحب (pull request) لمراجعة بشرية. تصف وثائق GitHub الحالية سير العمل حيث يقوم المطورون بتعيين المشكلات للوكلاء، ومراقبة عملهم، وطلب مراجعة الكود، وتقديم الملاحظات، والموافقة على النتيجة أو رفضها. (docs.github.com)

هذا يثير سؤالاً صعبًا للتعليم:

إذا كان بإمكان الطالب أن يطلب من وكيل إنتاج برنامج عامل، فما الذي يجب أن يُطلب من الطالب فهمه؟

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

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

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

التحول المركزي: من إنتاج الكود إلى الحكم الهندسي

وكلاء البرمجة ليسوا مجرد إكمال تلقائي أسرع

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

هذا يغير وحدة العمل. سير عمل المطور يبدو بشكل متزايد على هذا النحو:

1. فهم مشكلة المستخدم أو العمل.
2. تحديد السلوك المطلوب.
3. تقسيم العمل إلى مهام أصغر.
4. تعيين مهمة مناسبة لوكيل.
5. فحص خطة الوكيل.
6. السماح للوكيل بالتنفيذ ضمن بيئة خاضعة للرقابة.
7. تشغيل الاختبارات وفحوصات الأمان.
8. مراجعة النتيجة.
9. طلب تغييرات أو مراجعة التصميم.
10. الموافقة على البرنامج، ودمجه، ومراقبته.

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

حدود إنتاج الكود الخام

أصبح إنتاج الكود الخام مقياسًا أضعف للقدرة لأن الوكيل يمكنه إنشاء كمية كبيرة من الكود المعقول بسرعة. في الوقت نفسه، لا يزال الوكلاء يواجهون صعوبات في تطور البرمجيات على المدى الطويل، وتغييرات الملفات المتعددة، والمتطلبات غير الواضحة، والحفاظ على السلوك عبر التعديلات المتكررة. وجدت دراسة معيارية عام 2025 فجوة كبيرة بين أداء الوكلاء في حل المشكلات المعزولة ومهام تطور البرمجيات الأكثر تعقيدًا وطويلة المدى. (arxiv.org)

هذا يخلق تمييزًا تعليميًا مهمًا:

• قد لا يفهم الطالب الذي يمكنه إنشاء الكود ما يقوم به.
• الطالب الذي يمكنه شرح الكود واختباره وتحديه وإصلاحه يُظهر كفاءة أعمق.

لذلك، يجب أن يصبح الهدف التعليمي هو الحكم البرمجي الموثوق به، وليس مجرد توليد الكود بنجاح.

كيف تتكيف المناهج الدراسية

تتجه مناهج الجامعات نحو الفهم والتحقق

توقع تقرير مناهج علوم الحاسوب لعام 2023 الصادر عن ACM ومعهد مهندسي الكهرباء والإلكترونيات وجمعية النهوض بالذكاء الاصطناعي أن الذكاء الاصطناعي التوليدي سيغير تعليم البرمجة. تشير إرشاداته إلى أن الطلاب سيحتاجون إلى مزيد من التركيز على قراءة الكود وفهمه والتحقق منه وتحريره وتعديله وتكييفه واختباره. كما تحدد تحليل المشكلات كمنطقة يُرجح أن تصبح أكثر أهمية. (csed.acm.org)

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

يتوقع التقرير أيضًا تغييرات في تعليم هندسة البرمجيات، بما في ذلك زيادة استخدام الذكاء الاصطناعي لتوليد الكود، وتصحيح الأخطاء، والتحليل الثابت، ومراجعة الكود. يتطلب الاستخدام الفعال لهذه الأدوات مهارات تصميم وفهم للكود أقوى، وليس أضعف. (csed.acm.org)

بدأت هيئات الاعتماد في مكافأة النتائج الهندسية الأوسع

تؤكد معايير اعتماد الحوسبة الحالية من مجلس الاعتماد للهندسة والتكنولوجيا (ABET) بالفعل على:

• تحليل مشكلات الحوسبة المعقدة
• تصميم وتقييم حلول الحوسبة
• التواصل المهني
• المسؤولية القانونية والأخلاقية
• الأمن والخصوصية
• الآثار الاجتماعية للحوسبة
• مشروع شامل أو مكون تجريبي (abet.org)

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

اعتبارًا من 26 يوليو 2026، تشمل التغييرات المقترحة من مجلس الاعتماد للهندسة والتكنولوجيا لدورة 2026-2027 معايير إضافية لبرامج الذكاء الاصطناعي ومتطلبًا بأن يكون الخريجون قادرين على تطبيق نظريات ونماذج وتقنيات الذكاء الاصطناعي على المشكلات المعقدة. كانت التغييرات المقترحة لا تزال تنتظر الاعتماد النهائي وكان من المتوقع أن تدخل حيز التنفيذ بعد اجتماع خريف 2026، مع أول تطبيق خلال دورة مراجعة 2027-2028. (abet.org)

الاتجاه المحتمل واضح: ستحتاج البرامج إلى إظهار أن الطلاب يمكنهم بناء وتقييم الأنظمة، وليس مجرد إكمال تمارين برمجة معزولة.

دورات جديدة تُعلّم استخدام الوكلاء كتخصص هندسي

توضح العديد من الدورات الجامعية الحديثة النمط الناشئ.

غطت دورة جامعة ماريلاند لعام 2025 حول الاستخدام الفعال لمساعدي ووكلاء البرمجة المدعومين بالذكاء الاصطناعي أدوات يمكنها استدعاء أنظمة البناء، وتشغيل الاختبارات، وإصلاح الأخطاء. كما تناولت قابلية الصيانة، والهندسة المعمارية، وتصميم واجهة برمجة التطبيقات (API)، والكفاءة، وقابلية التوسع، والأمان، والتكامل المستمر، ومراجعة الكود، والوكلاء غير المتزامنين، ومراجعة الكود التلقائية. (cs.umd.edu)

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

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

1. استخدام وكلاء البرمجة بفعالية
2. بناء وكيل باستخدام واجهة برمجة تطبيقات نموذج لغوي كبير (LLM API)
3. تصميم وتقييم ونشر منسق وكلاء

تستخدم الدورة مشاريع ومختبرات وعروضًا توضيحية واختبارات صغيرة بدلاً من الامتحانات التقليدية. وتوضح أن التقدير سيكافئ الفهم أكثر من المخرجات، وتطلب من الطلاب شرح سبب فشل الوكيل وكيفية إصلاح النظام المحيط به. (eecs498-aase.github.io)

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

كيف تتغير المعسكرات التدريبية (Bootcamps)

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

نموذج المعسكر التدريبي المخصص للذكاء الاصطناعي

يجمع المعسكر التدريبي الحالي لتطوير برمجيات الذكاء الاصطناعي في Le Wagon بين تطوير الفول ستاك (full-stack) والتكامل مع الذكاء الاصطناعي. يشمل منهجه المنشور البرمجة بمساعدة الذكاء الاصطناعي، وتكامل نماذج اللغة الكبيرة، والنشر في الإنتاج، والتوليد المعزز بالاسترجاع (retrieval-augmented generation)، ووكلاء الذكاء الاصطناعي المستقلين. (lewagon.com)

يعامل هذا النموذج الذكاء الاصطناعي كخيط يمر عبر البرنامج بدلاً من كونه درسًا اختياريًا واحدًا. يُتوقع من الطلاب تعلم كليهما:

• كيف تعمل أنظمة البرمجيات التقليدية
• كيفية استخدام أدوات الذكاء الاصطناعي لبناء وتشغيل تلك الأنظمة

هذا المزيج مهم. قد لا يتمكن المتعلم الذي يعرف فقط كيفية تشغيل وكيل من التعرف على بنية معمارية معيبة. وقد لا يكون المتعلم الذي يعرف فقط البرمجة التقليدية مستعدًا لسير عمل التطوير الحديث.

نموذج "إضافة وحدة ذكاء اصطناعي"

يحافظ المعسكر التدريبي لهندسة البرمجيات في Springboard على أساس تقليدي في تطوير الويب، وواجهات برمجة التطبيقات (APIs)، وتطوير الواجهة الأمامية، وتطوير الواجهة الخلفية، ومشاريع الفول ستاك، مع إضافة وحدة ذكاء اصطناعي تركز على هندسة الأوامر (prompt engineering) والتعاون مع الأدوات التوليدية. (springboard.com)

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

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

• كيفية إنشاء ملف سياق مستودع (repository context file)
• كيفية كتابة مواصفات فنية
• كيفية تحديد حدود المهام
• كيفية تقييد صلاحيات الوكيل
• كيفية فحص خطط الوكيل
• كيفية تقييم الاختبارات المُنشأة
• كيفية اكتشاف مشكلات الأمان
• كيفية مقارنة التصاميم البديلة
• كيفية توثيق مشاركة الوكيل

ما الذي يجب أن يبحث عنه طلاب المعسكرات التدريبية

يجب على الطلاب المحتملين أن يسألوا عما إذا كان البرنامج يقيم ما يلي:

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

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

كيف تتكيف الشهادات

يقوم مقدمو الشهادات بتطوير ثلاثة أنواع واسعة من المؤهلات.

شهادات المعرفة الخاصة بالأدوات

تقيم شهادة GitHub Copilot من Microsoft الاستخدام المسؤول، وميزات Copilot، وبنية البيانات، وصياغة السياق والأوامر، وإنتاجية المطورين، والخصوصية، واستثناءات المحتوى، والضمانات. يتم الإشراف على الاختبار، ويستمر مائة دقيقة، وقد يحتوي على مكونات تفاعلية. (learn.microsoft.com)

تُقر هذه الشهادة بالمعرفة المفيدة في مكان العمل. يمكن أن تُظهر أن الشخص يفهم كيفية استخدام منصة تطوير معينة بمسؤولية.

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

شهادات تطوير الذكاء الاصطناعي القائمة على المنصة

تُعد شهادة AWS Certified Generative AI Developer – Professional أوسع نطاقًا. يتضمن دليل الاختبار الخاص بها دمج النموذج الأساسي، وإدارة البيانات، والامتثال، والتنفيذ، وحلول الذكاء الاصطناعي الوكيلة، والأمان، والحوكمة، والاختبار، واستكشاف الأخطاء وإصلاحها، والمراقبة، والتحسين. (docs.aws.amazon.com)

ومع ذلك، فإن الامتحان في المقام الأول متعدد الخيارات ومتعدد الاستجابات. إنه اختبار معرفي كبير، لكنه لا يُظهر بشكل كامل ما إذا كان المرشح يمكنه بناء نظام عامل أو مراجعته أو الدفاع عنه. (aws.amazon.com)

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

المؤهلات القائمة على المختبرات والمشاريع

توفر شهادات Microsoft Applied Skills نموذجًا أكثر واعدة. إنها تتطلب من المتعلمين إكمال مهام تفاعلية تتماشى مع العمل الحقيقي في تقييم قائم على المختبر. تُصنف Microsoft هذه الشهادات كدليل على أن المرشح يمكنه حل تحديات حقيقية للغيوم والذكاء الاصطناعي بدلاً من مجرد تذكر المعلومات. (learn.microsoft.com)

يجمع برنامج الذكاء الاصطناعي الوكيلي للتعليم التنفيذي بجامعة كارنيجي ميلون بين التعليم المباشر، والمختبرات الموجهة، والواجبات، وسير العمل متعددة الوكلاء، والتقييم، والضوابط الوقائية، والتسجيل، وقابلية المراقبة، ومشروع التخرج. (execonline.cs.cmu.edu)

هذه البرامج ليست مطابقة للشهادات المهنية المستقلة، لكنها تُظهر الاتجاه الذي من المرجح أن تتخذه المؤهلات:

• تقييمات عملية أقصر
• بيئات تطوير معزولة (sandboxed)
• مستودعات واقعية
• مهام التقييم وقابلية المراقبة
• أنظمة المشاريع النهائية
• تفسيرات فنية شفوية أو مسجلة
• دليل على الاستخدام المسؤول للأدوات

تقنيات التقييم التي تقيس الفهم

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

1. وثائق المواصفات والتحليل

قبل كتابة الكود، اطلب من الطلاب تقديم:

• مشكلة المستخدم
• المتطلبات الوظيفية
• المتطلبات غير الوظيفية
• الافتراضات
• القيود
• هياكل البيانات
• الواجهات
• معايير القبول
• تفصيل المهام
• المخاطر المعروفة

يجب أن تشرح الوثيقة سبب تقسيم المشكلة إلى مهام معينة.

يقيس هذا ما إذا كان الطالب يفهم المشكلة قبل أن يطلب من وكيل تنفيذها.

2. نقاط التحقق من تخطيط الوكيل

اطلب من الطلاب عرض الخطة المقترحة للوكيل قبل بدء التنفيذ. يجب على الطالب تحديد:

• أجزاء الخطة المقبولة
• الأجزاء غير المكتملة
• الافتراضات غير الآمنة
• المهام التي تتطلب موافقة بشرية
• الاختبارات التي يجب إضافتها

يجب أن تُكافئ الدرجة النهائية جودة حكم الطالب، وليس طول خطة الوكيل.

3. تقييمات مراجعة الكود

امنح الطلاب مستودعًا مُنشأ بواسطة وكيل يحتوي على عيوب متعمدة. يمكن أن تشمل العيوب:

• معالجة خاطئة للحالات الهامشية (edge-case)
• مصادقة غير آمنة
• معالجة ضعيفة للأخطاء
• مشكلات أداء خفية
• منطق متكرر
• واجهات غير واضحة
• اختبارات غير كافية
• انتهاكات الخصوصية
• مخاطر التبعية (Dependency risks)

اطلب من الطلاب إعداد مراجعة تتضمن مستويات خطورة، وأدلة، وإصلاحات مقترحة، واختبارات التراجع.

هذا أقرب إلى عمل البرمجيات الاحترافي من طلب من الطلاب إنشاء تطبيق صغير آخر من الصفر.

4. الشرح الشفوي والدفاع

يجب أن يكون الطالب قادرًا على شرح:

• ما يفعله النظام
• لماذا تم اختيار هذه البنية المعمارية
• الأجزاء التي تم توليدها
• الافتراضات التي وضعها الوكيل
• كيف تُظهر الاختبارات الصحة
• ما الذي لا يزال من الممكن أن يفشل
• التنازلات التي تم قبولها

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

5. مهام النقل

بعد أن يكمل الطالب مشروعًا بمساعدة وكيل، قدم متطلبًا جديدًا لا يمكن حله بمجرد تكرار الأمر الأصلي.

على سبيل المثال:

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

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

تقيس مهام النقل ما إذا كان الطالب قد تعلم طريقة عامة بدلاً من حفظ تفاعل ناجح.

6. تصميم الاختبار والاختبار العدائي

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

تشمل المتطلبات المفيدة ما يلي:

• كتابة اختبارات الحدود
• إنشاء اختبارات سلبية
• اختبار الإدخال غير الصالح
• اختبار استعادة الفشل
• التحقق من افتراضات الأداء
• استخدام اختبارات تعتمد على الخصائص عند الاقتضاء
• اختبار السلوك الحساس للأمان
• شرح ما تبقى دون اختبار

السؤال الأساسي ليس "هل اجتاز الكود الاختبار؟" بل "هل عرف الطالب ما يحتاج إلى اختباره؟"

7. سجل الإصدارات وملفات العمليات

يمكن أن يتضمن ملف المشروع ما يلي:

• المواصفات الأولية
• تحليل المهام
• خطط الوكيل
• الأوامر أو التعليمات الرئيسية
• التعهدات (Commits)
• نتائج الاختبار
• تعليقات المراجعة
• المقاربات الفاشلة
• تغييرات التصميم
• التفكير النهائي

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

فمثلاً، سمحت دورة البرمجة بجامعة برينستون عام 2025 بأدوات الذكاء الاصطناعي التوليدية ولكنها طلبت من الطلاب وصف استخدامها في ملف readme من خلال ملخص تمثيلي بدلاً من نص كامل وشامل. (cs.princeton.edu)

8. مراجعة النظراء المنظمة

تحول مراجعة النظراء الطلاب من مجرد منتجين للكود إلى نقاد للكود. تشير الأبحاث المبكرة إلى أن التقييم بواسطة النظراء القائم على المعايير يمكن أن يقترب من تقييم المدرب بدقة معتدلة مع تطوير التفكير التقييمي والمشاركة. (arxiv.org)

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

9. مشكلات الأوامر والمواصفات

مشكلات الأوامر (Prompt Problems) هي تمارين برمجة يكتب فيها الطلاب تعليمات باللغة الطبيعية تتسبب في قيام نظام ذكاء اصطناعي بتوليد كود يرضي المواصفات. يعلم هذا النهج الطلاب صراحة كيفية توصيل المتطلبات الحسابية لأنظمة توليد الكود. (arxiv.org)

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

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

هيكل تقييم نموذجي

يمكن لمشروع عملي استخدام الأوزان التالية:

لا يزال هذا الهيكل يكافئ المنتج العامل، لكنه يمنع الطالب من الحصول على درجة عالية لمجرد أن وكيلًا أنتج قاعدة بيانات كبيرة.

النزاهة الأكاديمية في الدورات الدراسية المدعومة بالوكلاء

الحظر الشامل والاستخدام غير المقيد كلاهما غير كافٍ

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

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

النهج الأقوى هو السياسة الواضحة على مستوى الواجب.

ثلاثة أوضاع سياسة مفيدة

الوضع الأول: الوكيل محظور

استخدم هذا لـ:

• الامتحانات
• تمارين البرمجة الأساسية
• عروض تصحيح الأخطاء الفردية
• تمارين الخوارزميات الأساسية
• التقييمات المصممة لقياس الاستدعاء أو التنفيذ غير المساعد

تمنع دورة "مبادئ الحوسبة الإلزامية" في جامعة كارنيجي ميلون أدوات الذكاء الاصطناعي لأي جزء من العمل الذي يتم تقييمه، بما في ذلك توليد الحلول، وشرح الحلول، وتنسيق الكود، وتوليد حالات الاختبار. (cs.cmu.edu)

الوضع الثاني: الوكيل مقيد

استخدم هذا عندما يمكن للطلاب طلب:

• شروحات المفاهيم
• مساعدة في التوثيق
• تفسير رسائل الأخطاء
• توضيح المكتبة أو واجهة برمجة التطبيقات (API)
• العصف الذهني
• نقد لتصميم من صنع الطالب
• إعادة هيكلة بسيطة

تسمح دورات أنظمة كارنيجي ميلون بأدوات الذكاء الاصطناعي لفهم واجهات برمجة التطبيقات والمكتبات والأطر والكود المقدم ورسائل الأخطاء، بينما تحظر طلبات حلول الواجبات الجزئية أو الكاملة. (cs.cmu.edu)

الوضع الثالث: الوكيل مسموح به مع الإفصاح

استخدم هذا لمشاريع هندسة البرمجيات الواقعية. اطلب من الطلاب الكشف عن:

• الأدوات التي استخدمت
• المهام التي تم تفويضها
• ما إذا كان الكود المُنشأ قد تم نسخه أو تعديله أو إعادة كتابته
• كيف تم اختبار المخرجات
• ما تعلمه الطالب
• الأجزاء التي تظل مسؤولية الطالب في التصميم

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

وبالمثل، تسمح كلية الدراسات العليا للتعليم بجامعة هارفارد بالاستخدامات مثل التوضيح، والعصف الذهني، والاستكشاف، بينما تحظر على الطلاب تقديم أعمال دراسية مُنشأة بواسطة الذكاء الاصطناعي على أنها من عملهم. كما تتطلب توثيق الاستخدام المسموح به وتحذر من أن الطلاب يظلون مسؤولين عن الدقة، والخصوصية، وحقوق الطبع والنشر، والتحيز. (registrar.gse.harvard.edu)

بيان إفصاح عملي

يمكن أن توفر الدورة نموذجًا بسيطًا:

لقد استخدمت [اسم الأداة] لـ [التخطيط، تصحيح الأخطاء، توليد الكود، الاختبار، التوثيق، أو المراجعة]. قمت بتفويض [مهام محددة]. لقد راجعت وعدلت المخرجات، واختبرت النظام الناتج، وأظل مسؤولاً عن دقة وأمان وأصالة ما قدمته.

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

الخصوصية والوصول المتساوي

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

تدعو إرشادات اليونسكو إلى نهج يركز على الإنسان ويعالج الخصوصية، والسلامة، والإنصاف، والشمول، والاستعداد المؤسسي. (unesco.org)

يجب أن تأخذ الدورات أيضًا في الاعتبار الطلاب الذين لا يستطيعون تحمل تكاليف العديد من الأدوات المدفوعة. يمكن للدورة العادلة أن:

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

طرق عملية لدمج الوكلاء بإنتاجية

استخدام مستودع متحكم فيه

امنح الطلاب مستودعًا يحتوي على:

• ملف README واضح
• قاعدة كود صغيرة ولكن واقعية
• اختبارات تلقائية
• سير عمل تكامل مستمر
• قائمة بالمشكلات المعروفة
• دليل أسلوب
• قائمة تحقق أمنية
• سجل تغييرات

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

طلب خطة قبل التنفيذ

لا ينبغي للطلاب أن يبدأوا بطلب من وكيل "بناء التطبيق بأكمله". اطلب تسلسلاً:

1. اطلب من الوكيل فحص المستودع.
2. اطلب ملخصًا للهندسة المعمارية.
3. اطلب المخاطر والمعلومات المفقودة.
4. اكتب خطة مهام الطالب الخاصة.
5. وافق على مهمة تنفيذ صغيرة واحدة.
6. راجع التغييرات الناتجة.
7. قم بتشغيل الاختبارات قبل المتابعة.

هذا يعلم التفويض المتحكم فيه بدلاً من التفويض الأعمى.

استخدام فريق وكلاء بأدوار واضحة

يمكن أن يتضمن نمط التنسيق البسيط ما يلي:

• المخطط: يقترح تفصيل المهام
• المنفذ: يعدل الكود
• المختبر: ينشئ ويشغل الاختبارات
• المراجع: يبحث عن العيوب والمخاطر
• المقيم البشري: يوافق على التغييرات أو يرفضها

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

الهدف التعليمي ليس بناء أكبر نظام متعدد الوكلاء. بل هو اختيار أبسط سير عمل ينتج نتائج جديرة بالثقة.

بناء بوابات موافقة بشرية

اطلب موافقة صريحة قبل أن يتمكن الوكيل من:

• تغيير المصادقة
• تعديل مخططات البيانات
• إضافة تبعيات
• الوصول إلى أنظمة الإنتاج
• تغيير تكوين النشر
• حذف الملفات
• دمج طلب سحب (pull request)

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

تقييم حالات الفشل عمدًا

الوكلاء يكونون أكثر فائدة تعليمية عندما يفشلون بطرق توفير معلومات. يجب على المدربين تضمين:

• متطلبات غامضة
• قيود متعارضة
• اختبارات غير مكتملة
• عمليات حساسة للأمان
• وثائق مضللة
• اختبارات متذبذبة (Flaky tests)
• حدود الأداء
• تغيير يبدو صحيحًا ولكنه يكسر ميزة أخرى

مهمة الطالب هي تشخيص الفشل وتحسين العملية.

إطار كفاءة للفترة من 2026 إلى 2031

تم تصميم الإطار التالي ليظل مفيدًا حتى مع تغير أدوات معينة.

المجال الأول: الأسس التقنية ومعرفة الكود

يمكن للمطور الكفء أن:

• يقرأ كودًا غير مألوف
• يشرح تدفق التحكم وتدفق البيانات
• يفهم الواجهات والتبعيات
• يحلل التعقيد الخوارزمي
• يستخدم التحكم في الإصدار
• يصحح الأخطاء دون الاعتماد بالكامل على وكيل

الدليل: شرح الكود، مهمة تصحيح الأخطاء اليدوية، نقد التصميم، وتمرين النقل الفردي.

المجال الثاني: تأطير المشكلات وتحليلها

يمكن للمطور الكفء أن:

• يوضح أهداف المستخدم
• يحدد القيود والافتراضات
• يفصل المتطلبات الأساسية عن الاختيارية
• يقسم العمل إلى مهام قابلة للاختبار بشكل مستقل
• يحدد معايير القبول
• يتعرف عندما تكون المهمة واسعة جدًا بحيث لا يمكن تفويضها بشكل موثوق

الدليل: المواصفات، رسم بياني للمهام، سجل المخاطر، وشرح خيارات التحليل.

المجال الثالث: توجيه الوكيل وهندسة السياق

يمكن للمطور الكفء أن:

• يوفر سياق المستودع المناسب
• يعطي تعليمات دقيقة
• يحدد الحدود والأذونات
• يختار متى يستخدم الوكيل ومتى لا يستخدمه
• يقارن الخطط البديلة
• يستعيد العمل عندما يتبع الوكيل تفسيرًا خاطئًا

الدليل: نقاط تحقق التخطيط، سجلات التفاعل التمثيلية، ومهمة مراجعة مباشرة.

المجال الرابع: التحقق والمراجعة

يمكن للمطور الكفء أن:

• يفحص الكود المُنشأ
• يصمم اختبارات ذات مغزى
• يحدد الافتراضات الخفية
• يراجع مخاطر الأمان والخصوصية
• يقيّم قابلية الصيانة
• يشرح ما لا تثبته الاختبارات

الدليل: مراجعة الكود، الاختبارات العدائية، تمرين اكتشاف العيوب، والدفاع الشفوي.

المجال الخامس: التنسيق والعمليات

يمكن للمطور الكفء أن:

• ينسق أدوات التخطيط والتنفيذ والاختبار والمراجعة
• يستخدم نقاط التحقق وبوابات الموافقة البشرية
• يتتبع التكلفة والوقت وسلوك الأداة
• يحافظ على سير عمل قابل للتكرار
• يراقب حالات الفشل ويحسن النظام
• يقرر ما إذا كان وجود وكلاء متعددين يضيف قيمة

الدليل: سير عمل تنسيق فعال، سجلات، تقرير تقييم، وتحليل التكلفة أو الأداء.

المجال السادس: تصميم المنتج والأنظمة

يمكن للمطور الكفء أن:

• يختار المستوى المناسب من الأتمتة
• يصمم أنظمة معيارية
• يوازن بين السرعة والجودة والتكلفة والمخاطر
• يربط القرارات الفنية بنتائج المستخدم
• يتعرف عندما يكون الحل البسيط غير الوكيلي أفضل

الدليل: ملخص المنتج، سجل قرارات البنية المعمارية، نموذج أولي، وعرض توضيحي يركز على المستخدم.

المجال السابع: الممارسة المهنية المسؤولة

يمكن للمطور الكفء أن:

• يفصح عن المساعدة من الذكاء الاصطناعي
• يحمي المعلومات الخاصة والملكية
• يحترم حقوق الطبع والنشر والتزامات الترخيص
• يحدد مخاطر التحيز والموثوقية
• يبلغ عن عدم اليقين
• يتحمل المسؤولية عن النظام النهائي

الدليل: بيان الإفصاح، تقييم المخاطر، مراجعة الخصوصية، وعرض تقديمي احترافي.

مستويات الكفاءة المقترحة

بحلول عام 2031، يجب أن تُظهر الشهادة المهنية التقدم عبر هذه المستويات بدلاً من مجرد تأكيد الإلمام بأداة برمجية معينة.

توصيات لمختلف الأطراف المعنية

الجامعات

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

المعسكرات التدريبية

• تعليم التطوير التقليدي والتطوير بمساعدة الوكلاء معًا.
• جعل الاختبار والهندسة المعمارية والأمان أجزاءً أساسية من المنهج الدراسي.
• طلب مشاريع حافظة (portfolio projects) مع سجلات العمليات.
• إضافة عروض تقنية حية.
• تعليم اكتشاف المنتج وكتابة المتطلبات.
• تجنب الوعد بأن التوجيه وحده يخلق مهندسين جاهزين للوظيفة.

مقدمو الشهادات

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

المدربون

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

المتعلمون ومنشئو المنتجات

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

الخطوة التالية الأولى

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

اختر مشكلة مستخدم صغيرة واكتب مواصفات من صفحة واحدة قبل أن تطلب من وكيل كتابة الكود.

بما في ذلك:

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

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

بعد تصحيح المواصفات، قم بتفويض المهمة الأولى فقط. راجع الخطة المقترحة، وافحص التغييرات، وقم بتشغيل الاختبارات، واكتب ما أخطأ فيه الوكيل.

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

الخلاصة

يتجه تعليم المطورين نحو توازن جديد.

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

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

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