يُخبرك مساعد البرمجة بأن جميع الاختبارات نجحت. البناء أخضر، فتدمج طلب السحب وتنتقل إلى المهمة التالية. بعد ثلاثة أسابيع تصل مشكلة، لكن الوكيل غير متاح للمساعدة. ربما نفدت حصتك من واجهة البرمجة، أو أنك عالق في قطار الضواحي بلا إشارة. الشيفرة أصبحت ملكك الآن، وثمة خلل فيها. فهل تستطيع فعلاً إصلاحها؟
هذا السؤال هو جوهر مشروع CodeOwnership. عمليًا، لا تعني الملكية أن يظهر اسمك على الإيداع فحسب. أنت لا تملك الشيفرة حقًا إلا إذا استطعت تتبع منطقها وترقيعها بالكامل دون مساعدة. فالاختبارات الناجحة تُثبت أن البرنامج يعمل في يوم جيد، لكنها لا تُثبت أنك تفهمه. ويتعلق هذا بالصيانة فقط، لا بالترخيص أو حقوق النشر.
بنى المؤلف CodeOwnership، وهو مشروع تجريبي خفيف، لاختبار هذه الثغرة العمياء. يكتب وكيل ذكاء اصطناعي ميزة، ويسجل المطور تقييمًا صادقًا لمدى فهمه لها. ثم يُدخل وكيل ثانٍ خللاً واحدًا مسجلًا مسبقًا. يفتح المطور تقرير حادثة بعد إيقاف جميع أدوات الذكاء الاصطناعي، ويحاول تحديد موضع العيب.
أصبح إطار الاختبار مكتملًا، ويشمل مواصفات مقفلة، واختبارات ظاهرة وأخرى مخفية، وفحص تحقق أعمى من الخلل، وواجهة سطر أوامر موجهة، وأداة تقارير لا تدمج المقاييس في درجة واحدة. في التجربة الأولى، قيّم المؤلف ثقته بـ4 من 5، ثم أوقف المؤقت عند 8 دقائق و12 ثانية دون أن يعثر على الخلل. وبعد نحو 30 دقيقة في جلسة لاحقة، عُثر على الخلل، لكن السكربت ظل يسجل الحالة NOT FIXED لأنه لم يُطبَّق أي إصلاح.
هذه نتيجة مطور واحد في تشغيل واحد، وليست مقياسًا معياريًا للصناعة. وهي تبيّن كيف يعمل إطار الاختبار، وأين يتعثر، وكيف يبدو الاختبار الواقعي لفهم الشيفرة.
المصدر: Towards Data Science · لخّصه HeadlinesBriefing