Habr يحلل «انحياز الأوراكل»: الذكاء الاصطناعي يسرّع كتابة الكود، لكن الثقة به لا ترتفع

يتناول الجزء الثاني من سلسلة «البرمجة الموثوقة: من الكود إلى التقنية» على Habr مفارقة مزعجة. فبعد الانتشار الواسع لمساعدات LLM، ترتفع مؤشرات العملية (السرعة وعدد الـcommits والمهام المنجزة)، بينما لا ترتفع ثقة المهندسين بأن الكود يفعل بالضبط ما يُراد منه. يفسّر الكاتب ذلك بانحياز الأوراكل، ويستند إلى أبحاث DORA وVeracode ومجموعة البيانات FormAI. إعلان المنشور قصير، لذا نستعرض أدناه الفكرة نفسها والبيانات التي تستند إليها.

مشكلة الأوراكل في عصر التوليد

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

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

ماذا تُظهر الأبحاث

تدعم عدة مصادر مستقلة الصورة التي يصفها كاتب السلسلة:

• DORA، تقرير 2024: ارتبطت زيادة اعتماد الذكاء الاصطناعي بنسبة 25% بانخفاض إنتاجية التسليم بنحو 1,5% وانخفاض استقراره بنحو 7,2%.
• DORA، تقرير 2025: يستخدم الذكاء الاصطناعي نحو 90% من المشاركين، بينما لا يثق نحو 30% منهم تقريباً بالكود المولَّد.
• Veracode، 2025: وُجدت ثغرات في 45% من عيّنات الكود التي ولّدتها أكثر من مئة نموذج على مجموعة من المهام.
• FormAI: نحو 112 000 برنامج بلغة C كتبتها LLM. وكشف التحقق الرسمي عن ثغرات في نحو نصفها.

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

أين يتراكم الدين التقني

يصبح التوليد أرخص، أما التحقق فلا. يزداد حجم الكود، بينما يبقى انتباه المراجِع كما هو. ينتقل عنق الزجاجة من الكتابة إلى التحقق، وإذا تحولت المراجعة إلى نظرة سريعة على الـdiff، تراكم الدين التقني دون أن يلاحظه أحد. هذا استنتاج من منطق العملية وليس رقماً منفصلاً من التقارير، لكنه يتسق مع انخفاض استقرار التسليم في بيانات DORA.

ما الذي يمكن فعله الآن

الإجراء الرئيسي: ألا يُترك للنموذج تنفيذ الكود ومعايير صحته معاً. عملياً يبدو ذلك كما يلي:

• صياغة المتطلبات واختبارات القبول الأساسية يدوياً، قبل توليد الكود.
• إضافة فحوصات لا تعتمد على المساعد: التحليل الساكن، واختبارات property-based، واختبار الطفرات (mutation testing)، والتحقق الرسمي للأجزاء الحرجة.
• النظر إلى درجة الطفرات (mutation score) وليس إلى التغطية وحدها. فالاختبار الذي لا يفشل عند تعطّل الكود لا يثبت شيئاً.
• وسم الكود الذي أنشأه الذكاء الاصطناعي، واحتساب نسبة إعادة العمل وعمليات التراجع، وليس سرعة التسليم فقط.
• تخصيص وقت مستقل للمراجعة وعدم اعتباره نفقات إضافية.

يعد الكاتب في الجزء الثالث من السلسلة بالمدقق النهائي، ومقياس الثقة L0–L4، وتوصيات عملية. وحتى ذلك الحين، الأمر الوحيد الواضح هو أن قياس السرعة وحدها سيُضعف الثقة بالكود، حتى لو ارتفعت كل الرسوم البيانية.