من يكتب الشيفرة الأفضل؟ معركة الذكاء الاصطناعي تدخل مختبرات البرمجة

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

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

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

جودة الشيفرة ليست المعيار الوحيد

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

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

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

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

التكلفة الحقيقية تبدأ بعد إرسال الطلب

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

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

وتبين وثائق الأسعار الرسمية لكل من أوبن إيه آي وأنثروبيك أن تكاليف الاستخدام تختلف باختلاف النموذج وحجم الرموز المعالجة والخدمات الإضافية، مثل التخزين المؤقت للمطالبات أو أنماط المعالجة الأسرع.

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

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

وهذا ما يفسر إتاحة بعض بيئات التطوير نماذج متعددة، بحيث لا تُسند كل المهام إلى النموذج نفسه، بل يُختار لكل طلب ما يتناسب مع تعقيده ومتطلبات تنفيذه.

الاختبار الحقيقي: هل ينجز النموذج المهمة من البداية إلى النهاية؟

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

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

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

وتبرز هنا حدود الاعتماد على الاختبارات المعيارية وحدها. ففي مقال نشرته أوبن إيه آي في فبراير/شباط الماضي، شرحت الشركة أسباب توقفها عن الاعتماد على اختبار إس دبليو إي بنش فيريفيد (SWE-bench Verified) لقياس قدرات النماذج المتقدمة في هندسة البرمجيات، مشيرة إلى عيوب في بعض حالات الاختبار واحتمال تلوث النتائج بسبب اطلاع النماذج على مسائل الاختبار وحلولها أثناء التدريب.

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

حماية الشيفرات والبيانات تدخل معادلة الاختيار

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

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

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

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

تعدد النماذج يمنح المطورين خيارات.. لكنه يفرض تحديات

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

لكن الانتقال من نموذج إلى آخر قد يتطلب تعديل التعليمات البرمجية وطريقة التفاعل مع الأدوات، فضلاً عن التعامل مع اختلاف حدود الاستخدام وأساليب استدعاء الأدوات والقدرة على معالجة السياقات الطويلة. كما أن ارتباط عمليات التطوير والاختبار والمراجعة بخدمة واحدة قد يزيد تكلفة الانتقال إلى بديل آخر مستقبلاً.

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

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

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