مطوّر لعبة يعتمد على وكيل ذكاء اصطناعي: 30 اختبارًا ناجحًا لم تثبت شيئًا حتى كتب اختبارًا جديدًا

موقف مألوف: تشرح للوكيل الأمر نفسه للمرة الثالثة، فيتصرف في المرة الرابعة على طريقته. مؤلف لعبة الاستراتيجية Age of Poleis، التي يكتب الذكاء الاصطناعي شيفرتها بينما يبتكر هو أفكارها ويتخذ قراراتها ويلعبها بنفسه، وصف كيف خرج من هذه الحلقة. وتفيد تجربته كل من يوكل إلى الوكلاء المهام الروتينية.

القاعدة والطريقة والفحص

تتكوّن المنظومة التقنية من خلفية بإطار Django وواجهة بـ React وTypeScript. يُوصَف العقد (contract) في الخلفية، ومنه يُستخرج مخطط OpenAPI، ثم تُولَّد أنواع TypeScript من المخطط. والإغراء واضح: حين لا يتطابق نوع في الواجهة الأمامية مع استجابة API، يبدو تعديله يدويًا مغريًا لأنه سطر واحد. لكن التعديل سيختفي بصمت عند التوليد التالي، وسيعود الخطأ.

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

الصيغة بسيطة: قاعدة، وطريقة لتنفيذها، وفحص. فمن دون فحص تعمل القاعدة ما دام الوكيل يتذكرها، ومع الفحص تعمل دائمًا. وبالطريقة نفسها يعالج المؤلف التنسيق والتوطين وغيرهما من المهام الروتينية المتكررة.

ثلاثون اختبارًا أخضر كانت تفحص شيئًا آخر

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

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

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

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

ما يبقى للإنسان

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

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

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

الخلاصة العملية

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