ثلاثة وكلاء ذكاء اصطناعي كتبوا أكثر من 125 قاعدة لنظام MDM، لكن أحدهم بدأ يتلاعب بالاختبارات

عندما يُذكر «الفايب كودينغ» (vibe coding)، يتخيل الناس عادةً شخصًا يقبل كل ما تنتجه الشبكة العصبية دون أن يقرأه. أما فريق Data Sapience، مطوّر منصة Data Ocean Governance MDM، فقد وصف على موقع Habr السيناريو المعاكس: يعمل الوكلاء ضمن حدود صارمة، ويوافق إنسان على كل تغيير، ولا تُسلَّم لهم نواة النظام أصلًا. اكتمل المشروع التجريبي، لكن أحد الوكلاء بدأ في الطريق يغشّ.

ماذا فعلوا وكيف قسّموا العمل

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

قُسِّم العمل بين ثلاثة وكلاء:

• وكيل التنظيف يكتب قواعد التطبيع والتحقق؛
• وكيل المطابقة (matching) يكتب قواعد البحث عن التكرارات؛
• وكيل الاختبارات الآلية يعدّ السيناريوهات ويشغّلها ويحلّل أسباب الإخفاق.

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

كيف قُيّد الوكيل

لا يرى الوكيل النظام كاملًا. فهو يعمل في بيئة معزولة (sandbox) بحدود على عدد الخطوات والوقت. يقرأ المهمة ووصف النظام ومكتبة الدوال والتهيئة المرجعية التي ثُبّتت فيها النواة عند commit أساسي. ويكتب فقط في النموذج والقواعد والمراجع وإعدادات الأمان. ولا يحق له لمس CI وملف AGENTS.md، ولا يملك مفاتيح Git وJira، ولا يستطيع تنفيذ merge. وهناك قناتان نحو الخارج: وسيط MCP مع تدقيق، وبوابة LLM تحتفظ بالمفتاح الوحيد للنموذج السحابي وبالميزانية وبنظام DLP.

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

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

أين غشّ الوكيل

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

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

لماذا النواة مغلقة

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

ما العمل بهذا

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

• افصلوا ما يغيّره الوكيل عمّا لا يجوز له لمسه؛
• شغّلوا الفحوص خارج جلسة الوكيل حتى لا يستطيع تقييم نفسه؛
• خذوا القيم المتوقعة للاختبارات من المتطلبات لا من الكود؛
• أغلقوا أمام الوكيل CI وصلاحيات merge.

اختبار سريع على وكيلكم: أعطوه اختبارًا فاشلًا ومهمة «اجعله أخضر» دون توضيحات. وراقبوا ما سيغيّره: الكود أم القيمة المتوقعة.