في عالم الهندسة البرمجية المُحَوَّلة بقوة من قبل الذكاء الاصطناعي، أصبحت المهام أكثر تعقيدًا، لكنها لم تُغيّر جوهر المهنة. كمهندس برمجيات في مجال الذكاء الاصطناعي، أجد نفسي أُجسّد مزيجًا من المهارات التقليدية: هندسة البرمجيات، والتفكير في المنتج، والتفهم العميق لاحتياجات المستخدم، إلى جانب مهارات التقييم التي أصبحت حجر الزاوية في تطوير الأنظمة الذكية. التحول الجوهري الذي ألاحظه هو أن "هندسة الذكاء الاصطناعي" ليست بديلًا للهندسة البرمجية، بل طبقة إضافية من التعقيد تُبنى فوقها. في معظم الشركات، لا نُدرّب نماذج من الصفر، بل نُوظّف نماذج جاهزة — عبر واجهات برمجة التطبيقات (API)، أو أنظمة استرجاع المعلومات المرتبطة بالنموذج (RAG)، أو التفاعل مع أدوات خارجية — مع الحفاظ على المعايير التقليدية: النشر، المراقبة، التوسع. أحد أهم التحديات اليوم هو تقييم أداء النماذج — أو ما يُعرف بـ "evals". في البرمجيات التقليدية، تُستخدم الاختبارات للكشف عن التراجعات (regressions) بعد كل تغيير. في الذكاء الاصطناعي، كل تغيير — سواء في النص التمهيدي (prompt)، أو في بنية RAG، أو في التدريب الدقيق — يمكن أن يحسّن أداءً في مكان ويُضعفه في آخر، دون أن نلاحظ ذلك فورًا. الحل؟ التقييم المستمر. لكنه ليس سهلًا. النماذج الذكية تُنتج إجابات تبدو صحيحة، لكنها قد تكون غير دقيقة أو غير مكتملة. المهام مفتوحة الاتجاه، ولا توجد إجابة واحدة "صحيحة" دائمًا. وغالبًا ما نتعامل مع نماذج كـ "صندوق أسود"، حيث لا نعرف تفاصيل التدريب أو البيانات المستخدمة. لذلك، أرى أن التقييم ينقسم إلى نوعين: كمي ونوعي. الكمي يعتمد على معايير واضحة: هل تم حل المسألة الرياضية بشكل صحيح؟ هل الكود يعمل دون أخطاء؟ يمكن تلقائيًا تقييم هذا النوع، مما يسمح بالتوسع. أما النوعي، فيتعلق بالتأويل: هل النص يبدو متسقًا؟ هل نبرة الدردشة مناسبة؟ هل الملخص يعكس الفكرة الأساسية؟ أحد الحلول المبتكرة هو استخدام نموذج ذكاء اصطناعي كـ "محكم" (AI judge). نُعرّف معايير تقييم واضحة (مثل: الوضوح، المساعدة، الدقة)، ونُقدّم للنموذج المُقيّم المدخل والنتيجة، فيُعيد تقييمها بدرجة أو تفسير. يمكن تكرار هذا على مجموعات كبيرة من البيانات، مما يسمح بالرصد المستمر، تمامًا كما في ممارسات CI/CD. الفكرة الأهم؟ التقييم المُوجّه (eval-driven development): تُحدّد معايير النجاح قبل البدء في البناء. لا يكفي أن يكون الناتج "دقيقًا"، بل يجب أن يكون عمليًا، سريعًا، آمنًا، وذو قيمة حقيقية للمستخدم. فمثلاً، نموذج يحوّل النص إلى SQL قد يُنتج استعلامًا صحيحًا، لكن إن استغرق 10 دقائق، فهو غير مفيد. القيمة الحقيقية تكمن في دمج عدة جوانب: الدقة، الاتساق (محليًا مع السياق، أو عالميًا مع مصادر خارجية)، القدرة على التحقق الذاتي (من خلال مقارنة إجابات متعددة)، والسلامة (تجنب تسريب بيانات حساسة، أو التعرض لهجمات التلاعب بالنص). في النهاية، التقييم ليس مجرد خطوة في النموذج، بل هو حجر الأساس في بناء أنظمة موثوقة. مع تطور الذكاء الاصطناعي، أصبحت المعايير التقليدية للجودة غير كافية. نحن نحتاج إلى مهارات جديدة: التفكير في التقييم كعملية مستمرة، والقدرة على قياس ما لا يمكن قياسه بسهولة، والعمل بوعي على توازن بين الأداء، والكفاءة، والثقة. الذكاء الاصطناعي لا يُغيّر هندسة البرمجيات — بل يُعمّقها. والمهندس المُحترف في هذا العصر هو من يُتقن التوازن بين القوة التقنية والرؤية الاستراتيجية، ويُقيّم ليس فقط ما يُنتج، بل ما يُحقّق.