هل من المنطقي فحص الكود البرمجي المسلَّم باستخدام الذكاء الاصطناعي قبل اعتماده واستلامه؟

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

من الناحية التقنية، العائق الأكبر هو نافذة السياق (context window). فنظام إدارة مستودعات بتكلفة 26.000 EUR يتكون غالباً من عشرات الخدمات ومخططات قواعد البيانات والتكاملات الخارجية. النماذج تفحص كل ملف بمعزل عن غيره، ولأنها لا ترى التحقق من البيانات الذي تجريه دالة في ملف يبعد ثلاثة مسارات، فقد تصدر إنذاراً كاذباً بوجود 'ثغرة أمنية'.

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

جربنا هذا الأمر بالضبط العام الماضي في بوابة B2B دفعنا فيها 18.000 EUR. استخرج لنا النموذج قائمة من 47 نقطة. وقبل إرسالها للوكالة، دفعنا 400 EUR لمطور أول مستقل لفحصها؛ فتبين أن 4 نقاط فقط من أصل 47 كانت عيوباً حقيقية، والباقي بلا أساس. لكن أحد تلك الأخطاء الأربعة كان كفيلاً بإسقاط النظام بالكامل في بيئة الإنتاج. الذكاء الاصطناعي مفيد كأداة تصفية أولية، لكنه غير كافٍ إطلاقاً كحَكَم نهائي.

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

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

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

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

ما كُتب هنا يطابق تماماً ما عشناه. معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

أتمنى أن يفيدك هذا.

قضيت وقتًا طويلاً في هذا المجال. تسير الأمور على ما يرام في الأشهر الثلاثة الأولى، وتظهر المشاكل في الشهر الرابع.

أتمنى أن يفيدك هذا.

إذا دخلنا في التفاصيل: كل من يستعجل في تعليمات مراجعة الكود البرمجي يتعثر في نفس النقطة.

حدث معنا هذا. كلما كان التراجع عن القرار أصعب، كان يجب اتخاذه ببطء أكبر.

صححوا لي إن أخطأت.

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

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

هناك نقطة لم أفهمها. إذا لم تقم بصياغة هذا كتابيًا من البداية، فستنشأ خلافات لاحقًا.

معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة. إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

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

إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

وكيف حللتم هذه النقطة؟ كل عبارة "سننظر في ذلك لاحقًا" في الاجتماع تعني عملًا غير مُسعّر.

هذا كل شيء، أرجو المعذرة إذا أطالت.

ظهرت ثلاث وجهات نظر مختلفة، وكلها تكمل بعضها. كلما كان التراجع عن القرار أصعب، كان يجب اتخاذه ببطء أكبر.

القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر.

أنت محق تمامًا ثم أكثر ما أهدر وقتنا كان عدم وضوح من يتخذ القرار.

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.