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

قبل بضعة أشهر وخلال مشروع تجريبي لمراجعة طلبات السحب (pull requests) باستخدام الذكاء الاصطناعي، شاهدتُ تغييرًا يجتاز مسار التكامل المستمر (Continuous Integration Pipeline) في أقل من أربع دقائق. كان فحص الأخطاء البرمجية سليمًا واختبارات الوحدة (unit tests) ناجحة ونسبة التغطية (coverage) أعلى من الحد الأدنى المطلوب. حتى لوحة التحكّم احتفت بنا بالقصاصات الخضراء الصغيرة التي تخصّصها لعمليات الدمج الناجحة. بدا التغيير مطابقًا لـ 100 عملية دمج آمنة سبقته. بعد يومين، بدأت لوحة بيانات أخرى تعرض قِيَم درجات حرارة مستحيلة فيزيائيًا لوسم محدّد (tag) حيث انقلب تحويله من المئوية إلى الفهرنهايت. وهي حالة لم يفكّر أحد – لا بشر ولا ذكاء اصطناعي – في كتابة اختبار لها.

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

الفجوة التي لا يقيسها أي مسار تكامل مستمر (CI Pipeline)

في دراسة نُشرَت عام 2023، أُتيح لمجموعة من المطورين استخدام مساعد برمجي يعتمد على الذكاء الاصطناعي بينما لم تتم إتاحة هذه الأداة لمجموعة أخرى ثم طُلِب من المجموعتين إنجاز المهام البرمجية ذاتها المتعلّقة بالأمن (security). تبيّن أن المجموعة التي استعانت بالذكاء الاصطناعي كتبت كود أقل أمانًا بفارق ملموس في مُعظَم المهام. غير أن النتيجة الثانية هي التي تستحق التوقف عندها: فقد كانت هذه المجموعة أكثر ثقة بسلامة الكود الخاص بها من المجموعة التي لم تستخدم الذكاء الاصطناعي. أي أن ثقتهم ارتفعت في الوقت نفسه الذي تراجعت فيه صِحّة عملهم.

كشفت تجربة عشوائية منفصلة أُجريَت عام 2025 عن النمط ذاته لكن في الإنتاجية هذه المرة وليس في الأمن. فقد تبيّن أن المطورين ذوي الخبرة عند عملهم على قواعد برمجية (codebases) ضخمة ومألوفة لديهم كانوا أبطأ بشكل ملموس عند الاستعانة بأدوات الذكاء الاصطناعي في المهام المعقدة رغم توقعهم المُسْبَق أن هذه الأدوات ستزيد سرعتهم. وحتى بعد أن أصبحوا أبطأ بالفعل ظلّوا يعتقدون أن الأدوات قد ساعدتهم. ولا تملك مجموعة الاختبارات (test suite) ولا علامة التحقق الخضراء (green checkmark) أي وسيلة لرصْد هذه الفجوة فعملية البناء (build) لا تعرف إن كان الشخص أو الوكيل البرمجي الذي أنتج الكود قد تصرّف بثقة مفرطة بل تكتفي بالتحقق ممّا إذا كان الكود يعمل.

لماذا تبقى النتيجة خضراء بينما تتدهْوَر جودة الكود؟

لا تخبرك نسبة التغطية ونجاح مجموعة الاختبارات إلا عن حالة التغيير في لحظة معيّنة، ولا تخبرك بما يحدث للقاعدة البرمجية (codebase) بمرور الوقت. فقد كشف تحليل أُجري عام 2025 لأكثر من 200 مليون سطر من الكود أن كُتَل الكود المكررة (duplicated code blocks) ارتفعت بنحو ثمانية أضعاف وأن نسبة الكود الذي أُعيدَت كتابته في غضون أسبوعين تضاعفت تقريبًا وذلك خلال الفترة التي تحولّت فيها مساعدات البرمجة المدعومة بالذكاء الاصطناعي من ميزة جديدة إلى ميزة أساسية.

لا يثير أيٌّ من ذلك أي مشكلة في حينه. يمر الكود المكرّر ويجتاز الاختبارات لدالّة ستُعاد كتابتها بعد أيام قليلة. فمسار التكامل المستمر يقيّم كل طلب سحب بمعزل عن غيره ولذلك قد يصبح الحفاظ على قاعدة الشيفرة البرمجية (codebase) أكثر صعوبة بشكل ملحوظ، بينما يجتاز المراجعة بنجاح كل تعديل فردي ساهم في هذا التدهور.

كيف نسدّ الفجوة فعليًا؟

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

تتبّع التكرار والتغيير بوصفهما إشارتين (signals) داخل مسار التكامل المستمر، لا إشارتين استرجاعيتين (retrospective). ويمكن ذلك بتشغيل أداة لكشف الكود المكرّر تُصدر تقريرًا مع كل طلب سحب دون أن تعطّله ثم تحديد الملفات التي أُعيدَت كتابتها بشكل كبير أكثر من مرة خلال أسبوعين من دمجها (merging). ولا يتطلّب أيٌّ من هذين الإجراءين تعطيل عملية البناء في الوقت الحالي فكلاهما مفيد بما يكفي لتوفير رؤية واضحة وهذا ما يدفع معظم الفرق إلى التحرّك بمجرد ملاحظتها هذا النمط (pattern).

ما الذي يجب تجنبه؟

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

الخلاصة

بالنسبة لمسار التكامل المستمر، لم يكن الحل يَكمُن في نموذج أكثر ذكاءً أو مجموعة اختبارات أطول ولكن الحل في طرح سؤال مختلِف على الكود الماثِل أمامنا: ليس هل تم تشغيل هذا الكود؟ بل ما الذي يجب أن يتحقق في هذا الكود حتى أثق به فعلاً؟ إنه سؤالٌ يستحق الطرح بشأن كل عملية بناء ناجحة (تظهر باللون الأخضر) على شاشتك الآن بما في ذلك تلك التي تُقابَل باحتفالات النجاح والبهجة.

* المصدر: https://www.softwaretestingmagazine.com/knowledge/certainty-isnt-correctness-the-real-cost-of-trusting-ai-written-code

** الصورة من موقع: https://about.gitlab.com/blog/measuring-ai-effectiveness-beyond-developer-productivity-metrics