Google توزّع إعداد المواصفات بالذكاء الاصطناعي على دورين في إضافة EGM

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

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

لماذا ينبغي للمراجع أن ينسى المحادثة

توزّع EGM العمل على دورين. يحتفظ «الفيل» بسياق المشروع ويعدّ الوثيقة. وتتلقى «الأسماك الذهبية» الوثيقة والكود المصدري المرتبط بها، من دون المحادثة السابقة. يختار المطوّر الملاحظات التي سيأخذ بها، ويحسم التعارضات، ويعتمد التصميم قبل كتابة الكود. هكذا تُوصف العملية في مستودع Google.

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

لكن عبارة «سياق صفري» قد تُفهم بحرفية مفرطة. فالمراجع يتلقى مواد يعمل عليها. ما يُعزل هو سجل النقاش، لا كل المعلومات المتعلقة بالنظام. لذلك تظل جودة المواصفات واختيار الكود المصدري المرفق عاملين مهمين.

كيف يبدو ذلك في مثال المدفوعات

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

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

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

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

ما الذي يمكن تجربته، وما الحدود

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

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

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

يُوزّع المشروع بموجب ترخيص Apache 2.0؛ ويوضح مؤلفوه صراحة أنه ليس منتجًا تدعمه Google رسميًا. وتتطلب المراجعة سياقات جديدة للوكلاء الفرعيين، كما أن العملية لا تحل محل الاختبارات أو الحكم الهندسي. وهذه القيود مذكورة بوضوح في README.

تقترح EGM عادة مفيدة: قبل التنفيذ، اعرض المواصفات على من لم يشارك في مناقشتها. فإذا تعذّر تنفيذها من دون توضيحات شفهية، فهذا يعني أن الوثيقة ما زالت بحاجة إلى عمل.