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

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

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

المعيار المرجعي دليل، وليس نتيجة في لوحة المتصدرين

توفر المعايير المرجعية مفتوحة المصدر لوكلاء البرمجة نقاط انطلاق مفيدة، لكنها تقيس قدرات مختلفة. يستخدم SWE-bench مشكلات حقيقية من GitHub ولقطات من المستودعات، ما يجعله ذا صلة بأعمال الصيانة. ويختبر Terminal-Bench التفاعل مع سطر الأوامر. أما المعايير المرجعية الأخرى المدرجة، ومنها SlopCodeBench وProgramBench، فتستهدف جوانب مختلفة من الشيفرة المُولَّدة وسلوك الوكلاء.

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

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

حزمة الاختبارات الدنيا للبرمجيات المبنية بالذكاء الاصطناعي

بالنسبة إلى تطبيق صغير، يمكن بناء حزمة جودة مفيدة من دون مختبر أبحاث معقد:

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

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

اختبر التنسيق، لا المخرجات فحسب

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

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

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

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

ستصبح قابلية إعادة الإنتاج ميزة مهنية

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

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

وينبغي أن يميّز التقرير العملي بين ثلاث نتائج على الأقل:

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

النظام الذي يجتاز 19 فحصًا من أصل 20 لفحوصات تنسيق منخفضة المخاطر ليس بالضرورة أفضل من نظام يجتاز 18 حالة من أصل 20 لكنه لا يتجاوز أبدًا حدود التفويض. يجب أن يزن معيار الجودة حالات الفشل وفقًا لعواقبها.

ينبغي أن تستهدف المراجعة البشرية المخاطر، لا كل سطر

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

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

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

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

ما ينبغي وضعه في ملف الأعمال أو عرضه في مقابلة

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

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

لا تدّعِ الموثوقية استنادًا إلى تسجيل ناجح واحد. تبدو المطالبة القابلة للتحقق أقرب إلى الآتي: «عبر 30 عملية تشغيل مسجلة لهذه السيناريوهات الاثني عشر، استوفى النظام معايير القبول في 28 منها؛ وتعلقت حالتا الفشل بإدخال تاريخ ملتبس، وكلتاهما موثقتان». فالعدد نفسه أقل أهمية من المنهج، والحدود، والصدق بشأن ما لم يُختبر بعد.

التعريف الجديد للسرعة

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

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

لذلك فإن معيار الجودة ليس: «هل يمكنك إنشاء تطبيق باستخدام الذكاء الاصطناعي؟» بل: «هل يمكنك إثبات ما يفعله التطبيق، واكتشاف متى يتوقف عن فعله، وتصميم الحدود التي تمنع تحول الفشل إلى حادث؟»