مدير منتج بلا مطوّر يصدر إضافة بوكلاء الذكاء الاصطناعي ويحميها بـ89 اختبارًا حارسًا

يكتب الوكيل: «انتهيت، جميع الاختبارات تنجح». وإذا لم يكن في المشروع مطوّر ولا تقرأ الشيفرة بنفسك، فلا خيار أمامك سوى تصديق كلامه أو ابتكار طريقة للتحقق. اختار مدير المنتج، الذي يطوّر منذ يناير إضافة لمتصفح Chrome بواسطة وكيلَي ذكاء اصطناعي هما Claude Code وCodex، الخيار الثاني.

وحتى 28 أكتوبر بلغ لديه 593 commit، و78 478 سطرًا من الشيفرة، و177 511 سطرًا من الاختبارات، وصدر الإصدار 1.0.1 في Chrome Web Store.

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

أما المستخدم فينتظر يومًا كاملًا. وضد هذا النوع من الأخطاء أنشأ المؤلف «الحرّاس» (guard بالإنجليزية): اختبارات تحمي وعدًا محددًا من وعود المنتج وتفشل عند انتهاكه. عددها الآن 89.

وإذا كنت تكلّف الوكيل بمهمة تستغرق عدة ساعات، فيمكنك اعتماد هذا النهج.

ما هو المنتج وعلى ماذا اختُبر هذا النهج

تحمل الإضافة اسم Chat with Multiple AI، وترسل طلبًا واحدًا دفعة واحدة إلى 15 دردشة ذكاء اصطناعي، بينها ChatGPT وClaude وGemini. هذه مواقع تخص جهات أخرى، وهي تتغير دون إنذار. لذلك نُقل وصف طريقة التعامل مع كل دردشة إلى ملف إعدادات منفصل. وعندما تتغير دردشة ما، يعدّل المؤلف الملف، فيصل التصحيح إلى المستخدمين دون إصدار جديد في المتجر. حدث ذلك مرتين: في 19 أكتوبر وفي 1 نوفمبر. وقبل الإصدار 1.0.1 أجرى الوكيل بنفسه في المتصفح 70 سيناريو قبول.

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

الحارس: وعد المنتج مكتوبًا في اختبار

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

أُضيف الحرّاس بوتيرة غير منتظمة: 2 في مايو، و9 في يوليو، و33 في أغسطس، و40 في سبتمبر، و5 في أكتوبر. أما القالب العملي للطلب الموجّه إلى الوكيل فهو: صِف الوعد بكلمات المستخدم، واطلب من الوكيل أن يجد ما الذي يحفظه في الشيفرة، وأن يكتب حارسًا باسم واضح، وأن يُظهر أنه يفشل عند انتهاك الوعد.

البناء الأخضر ونسختان من القواعد

قد لا يتحقق البناء الأخضر من أي شيء. ففي 27 يوليو وصل عدّاد أخطاء الأنواع (عندما تخلط الشيفرة بين أنواع البيانات، كأن تعامل نصًا على أنه رقم) إلى الصفر. ويمكن الوصول إلى الصفر بطريقتين: إصلاح الأخطاء أو التوقف عن البحث عنها، مثلًا بتعطيل الوضع الصارم أو باستثناء مجلد من الفحص. وللمؤلف ضد ذلك أسلوبان. الأول حدّ أدنى: يحسب الفحص الملفات التي قرأها ويفشل إذا كانت قليلة جدًا. والثاني كسر متعمّد: تُخرق قاعدة عمدًا في نسخة من المشروع، ويجب أن يفشل الحارس. وفي التطوير يسمّون ذلك اختبار الطفرات (mutation testing). ويكسر القالب نسخة من المشروع بـ42 طريقة ويُظهر أي فحص التقط كل كسر؛ وعلى حاسوب المؤلف يستغرق العرض أقل من دقيقة.

مشكلة أخرى هي تكرار القواعد. كان Claude Code وCodex يقرآن القواعد من ملفين مختلفين هما CLAUDE.md وAGENTS.md، وكان يُفترض أن يتطابقا. وتراكمت الفروق: 9 أسطر في مارس، و12 في يونيو، و21 في أغسطس، حين كان في الملفين 102 و85 سطرًا. ونما ملف القواعد من 61 سطرًا في فبراير إلى 179 في أكتوبر. ومنذ 25 سبتمبر بقي ملف AGENTS.md واحد فقط، ويفشل الحارس إذا ظهر بجانبه ملف قواعد آخر. أما المهارات (skills، وهي تعليمات لإجراءات متكررة مثل commit) فتوجد في مجلدات كل وكيل، ولذلك يقارن الحارس كل زوج منها.

ويوضح المؤلف بصراحة أنه لم يقِس مقدار التحسن الذي أسهمت به منظومة الإحاطة (harness)، ومقدار ما أسهمت به النماذج الأذكى. وقد نشر هذه المنظومة قالبًا مفتوحًا على GitHub (yesgenius/agent-harness).