تطوير الأكواد البرمجية بين صُنع الإنسان والذكاء الاصطناعي التوليدي

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

وقد شكّلت هذه الإشكالات نقطة انطلاق لعمل باحثي جامعة محمد بن زايد للذكاء الاصطناعي، الذين طوّروا نظام Droid؛ وهو مجموعة بيانات ونظم كشف متخصصة أعلن عنها خلال فعاليات مؤتمر EMNLP 2025. وقد لخّص طالب الماجستير دانييل أوريل الإشكالية البحثية وفق منطق واضح مفاده:

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

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

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

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

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

ويتميّز نظام DroidCollection بجمعه بين الحجم الكبير والتمثيل الواقعي للسيناريوهات المحتملة، وهي سمة نادرة في مجال دراسات الكشف عن الأكواد البرمجية المولّدة آلياً.

تدريب الكواشف على تمييز الأكواد البرمجية التي تبدو وكأنها من صنع الإنسان

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

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

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

كما أخذ الباحثون في الاعتبار بُعداً هجومياً ذا طابع “اختباري” شبيه بمنهجيات “الفرق الحمراء”. فالكواشف التي تُدرَّب حصراً على مخرجات “صادقة” من النماذج تولّد نقاط ضعف واضحة؛ إذ يمكن التحايل عليها بمجرد توجيه النموذج لإنتاج أكواد “شبيهة في أسلوبها بما ينتجه المطورون”. وقد تناولت ورقة Droid هذا التحدي بشكل مباشر عبر إدراج نظامين خصمين (adversarial regimes) ضمن عملية بناء البيانات.

يتمثل النظام الأول في الهجمات المعتمدة على التوجيهات (prompt-based attacks)، حيث تُصاغ مقدمات توجه النماذج لاتباع أسلوب برمجي أقرب إلى أسلوب الإنسان. أما النظام الثاني فيعتمد على الضبط التفضيلي .(preference‑tuning) ففي هذا الإطار، جمع الباحثون مجموعة ضخمة تضم 157 ألف زوج من مخرجات المطورين والمخرجات المولدة آلياً (نفس التوجيه، مع اختلاف جهة التأليف)، واستخدموها لضبط نماذج لغوية صغيرة ومتوسطة الحجم باستخدام أسلوبي DPO وLoRA، بحيث تنحاز مخرجات هذه النماذج تدريجياً نحو التوزيعات الأسلوبية البشرية.

وتولّد النماذج المضبوطة تفضيلياً سلسلة جديدة من الأكواد “المُموَّهَة بشرياً”، والتي يتم إخضاعها لاحقاً للتنقيح قبل دمجها في DroidCollection. وبالنظر إلى الحجم الكلي للبيانات، يظهر أن الجزء الخصومي من المجموعة يتوزع بشكل شبه متوازن بين الهجمات المعتمدة على التوجيهات، والهجمات الناتجة عن الضبط التفضيلي – وهي أنواع من البيانات غالباً ما تغيب تماماً عن مجموعات التدريب التي تعتمدها معظم كواشف الأكواد المتاحة.

وتتضافر جميع هذه المكوّنات لتشكيل نظام DroidDetect، وهو زوج من الكواشف المعتمدة على بنية encoder-only، جرى ضبطها اعتماداً على نموذج ModernBERT، وتدريبها وفق هدف تصنيفي متعدد الفئات. ويتيح هذا الهدف التمييز بوضوح بين ثلاثة أنواع من الأكواد البرمجية: الأكواد البرمجية من صنع الإنسان، والأكواد البرمجية المُولَّدة آلياً، والأكواد البرمجية التي خضعت لتحسينات نفّذها نموذج ذكاء اصطناعي.

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

وقد جرى تدريب كواشف نظام DroidDetect عبر مجموعة واسعة من اللغات البرمجية والمجالات ونُظُم التوليد المختلفة، تماشياً مع تنوع سيناريوهات البرمجة المعاصرة. كما خضعت لاختبارات دقيقة في بيئات ضمن التوزيع (in-distribution) وخارج التوزيع (out-of-distribution)، وذلك بهدف تقييم قدرتها على التعميم وقياس فاعليتها في نقل الأداء إلى سياقات جديدة لا تظهر في بيانات التدريب الأصلية.

وفي سياق التقييمات الشاملة، حقق نموذج DroidDetect‑Large أداءً متميزاً؛ إذ سجّل متوسط درجة F1 ≈ 99.2% في مهمة التصنيف الثنائي (بشري أو آلي)، وما يقارب %93.7 في مهمة التصنيف الثلاثي الأكثر واقعية، وذلك عبر لغات برمجة متعددة. وقد استطاع بذلك التفوّق على نماذج معيارية قوية كانت قد خضعت لضبط دقيق بالاعتماد على مجموعات بيانات خاصة بها. كما أظهرت النسخة الأولية للنظام – DroidDetect‑Base – أداءً متقارباً وفي النطاق ذاته من الفعالية.

وعند تقييد تدريب النموذج على لغة برمجية واحدة، ثم اختباره على لغات أخرى، أظهرت النتائج أعلى درجات الانتقال (transfer) بين اللغات البرمجية المتقاربة بنيوياً – مثل انتقال الأداء من C/C++ إلى Java – بينما كان الانتقال أضعف عند التعامل مع لغات برمجية تختلف من حيث النمطية والهيكل، مثل Python أو JavaScript الأمر الذي يتوافق مع التوقعات النظرية، ويُبرز أهمية تضمين بيانات تدريب متعددة اللغات.

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

وتُعد، في هذا السياق، الصلابة أمام الهجمات الخصومية (Adversarial Robustness) بمثابة الاختبار الحقيقي لقدرات نظم كشف طبيعة الأكواد، إذ إن العديد من الكواشف الجاهزة – التي تبدو فعّالة عند تقييمها على بيانات “مفلترة” – يتراجع أداؤها بشكل كبير عند التعامل مع أكواد برمجية خضعت لعمليات “تحرير قام بها مطورون” تهدف إلى خداع أنظمة الكشف. فعلى سبيل المثال، لا يتجاوز معدل الاستدعاء (recall) لأداة GPT‑Zero المعتمدة على واجهات API حاجز 0.10 عند اختبارها على الأكواد البرمجية الخصومية ضمن بيئة تقييم نظام Droid، في حين تحقق كواشف النصوص العامة أداءً أفضل في بعض المقاييس وأسوأ في غيرها، وغالباً ما ترتفع لديها معدلات الإجابات الكاذبة عند تحليل الأكواد البرمجية الأصيلة من صنع الإنسان.

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

يُظهر نظام DroidDetect – في المقابل – مستوى متقدماً من الصلابة، حيث يحافظ على معدل استدعاء يتجاوز 0.9 عند التعامل مع العينات الخصومية. كما يحتفظ، في الوقت نفسه، بأداء قوي عندما يتعلق الأمر بالأكواد من صنع الإنسان. ويُعزى ذلك إلى اعتماده على تدريب صريح يتضمن التعرض لأنماط متعددة من الهجمات، سواء تلك القائمة على التوجيهات (prompt‑based attacks) أو على الضبط التفضيلي (preference‑tuned attacks)، مما يمنحه قدرة أفضل على التعميم والتعامل مع محاولات إخفاء الأسلوب البرمجي.

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

أما على مستوى التدريب، فقد تبيّن أن هناك استراتيجيتين أكثر تأثيراً: الأولى تتمثل في استخدام نسخة تعتمد على التعلّم المتري (metric learning) من خلال دالة الخسارة الثلاثية [Triplet Loss Function]، والتي يطلق عليها الباحثون اسم DroidDetect‑SCL. وتساعد هذه المنهجية في تعزيز الفصل بين الفئات، ولا سيما عندما تبدو الأكواد البرمجية الخصومية أو تلك المُنقّحة أقرب أسلوبياً إلى الأكواد البرمجية “من صنع الإنسان” مما يؤدي إلى تحسينات طفيفة وثابتة في الأداء.

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

لماذا تُعدّ مسألة المنشأ محورية؟

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

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

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

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

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

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

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

ويقول دانييل عند سؤاله عن خططه لتطوير المشروع مستقبلاً: “نحن نعمل حالياً على تنظيم مهمة مشتركة (Shared Task) ضمن مؤتمر SemEval حول الكشف عن الأكواد المولّدة آلياً، وآمل أن تسهم هذه المبادرة في زيادة الاهتمام بهذا المسار البحثي وتوسيع نطاقه“.

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