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