نشرت Google في 22 أكتوبر إضافة Elephant-Goldfish Model المفتوحة المصدر، لتنظيم مرحلة التخطيط في تطوير البرمجيات باستخدام وكلاء الذكاء الاصطناعي. وفكرتها الأساسية بسيطة: تحتفظ جلسة واحدة بسياق المشروع والقصد منه، بينما يتلقى وكلاء منفصلون وثيقة التصميم بحثا عن الغموض والافتراضات الناقصة والفجوات. والمفترض أن تأتي كتابة الشفرة بعد توضيح المتطلبات ومراجعتها، لا أن تحل محلهما.
وتقول Google إن الإضافة طُورت أولا لمهندسيها، ويستخدمها آلاف الموظفين. وهذا رقم تذكره الشركة، وليس مقياسا مستقلا لجودة البرمجيات الناتجة عن هذه الطريقة. ويُتاح المستودع بترخيص Apache 2.0، ويتضمن التوثيق توضيحا آخر: ليست الإضافة منتجا تدعمه Google رسميا. ويهم هذا التمييز الفرق التي تفكر في دمجها ضمن عملية تطوير تعتمد عليها يوميا.
لماذا نحتاج إلى الاحتفاظ بالسياق والبداية من جديد؟
يصور اسم Elephant-Goldfish تقسيما للعمل. فـ Elephant جلسة غنية بالسياق تحتفظ بالتاريخ والبنية المعمارية والقرارات الصغيرة المتخذة أثناء النقاش. أما Goldfish فيبدأ من نقطة جديدة نسبيا: يقرأ المواصفات ويفحصها دون الاعتماد على الشروح المتراكمة في محادثة التخطيط. ولا يتعلق الأمر بنموذجين جديدين أو بتدريب نظام جديد.
يعالج هذا التقسيم مشكلة مألوفة في العمل المشترك، حتى دون الذكاء الاصطناعي. فقد يعرف من ناقشوا مسألة مطولا ما يقصدونه، رغم أن الوثيقة التي كتبوها لا تشرحه جيدا. ويكشف قارئ جديد الفجوة حين يفهم جملة بصورة مختلفة. وتحاول الطريقة جعل تلك اللحظة جزءا مقصودا من العملية، قبل ترجمة مواصفات مبهمة إلى ملفات ودوال يصعب تعديلها لاحقا.
لكن فصل المحادثات لا يضمن مراجعة صحيحة. فقد يفوت الوكيل عيبا، أو يبالغ في أهمية مشكلة هامشية، أو يوافق على تصميم غير مكتمل. والميزة المحتملة هنا تنظيمية: تحصل المراجعة على دور ومدخلات خاصين بها، بدلا من أن تضيع داخل المحادثة التي أنتجت الخطة. ويبقى على المهندس تحديد الاعتراضات المبررة والتعديلات التي تحسن الحل. فعدد الوكلاء وحده ليس شهادة جودة.
3 مراحل قبل الانتقال إلى الشفرة
يصف إعلان Google 3 مراحل للتصميم المشترك. تبدأ بتحديد المشكلة ومناقشة البدائل، مع قاعدة تمنع كتابة الشفرة في هذه المرحلة. ثم تُعد وثيقة Markdown تشمل المشكلة والمنهج التقني والبدائل المدروسة وخطة تنفيذ مفصلة. وأخيرا، يراجع وكلاء منفصلون مدى وضوح الوثيقة واستعدادها للتنفيذ.
هذا تحول في موضع التركيز، وليس مجرد إضافة أمر جديد إلى أداة التطوير. فبدلا من قياس التقدم بكمية الشفرة التي ينتجها الوكيل، تصبح المحطة الوسيطة وثيقة يستطيع شخص آخر فهمها ونقدها. وقد تتيح للفريق نقاشا مبكرا حول معايير النجاح والملفات المتوقع تغييرها وما يبقى خارج نطاق العمل. وهذه قرارات تخص المنتج والهندسة، حتى عندما يساعد الذكاء الاصطناعي في صياغتها.
وتنتج الطريقة أيضا مرجعا يمكن العودة إليه عند تغير التنفيذ. فالمواصفات المكتوبة لا تضمن التزام الشفرة بها، لكنها توفر أساسا للمقارنة. ومن دون سجل للقرار الأصلي، قد يصعب التمييز بين تغيير مقصود وانحراف حدث أثناء العمل. لذا تمتد القيمة المحتملة إلى ما بعد توليد الشفرة للمرة الأولى، لتشمل القدرة على تفسير سبب اختيار الحل لاحقا.
المراجعة تبدأ بالفهم
في مرحلة المراجعة التي تعرضها Google، يجب على وكيل منفصل أن يشرح أولا البنية المعمارية للوثيقة والقصد منها. وإذا تعذر عليه وصفهما بدقة، فهذا يشير إلى أن المواصفات لا تزال غامضة. ثم يبحث مراجعون متشككون عن الحالات الحدية والاعتماديات الخفية والثغرات المنطقية. ويتناول فحص آخر الجاهزية للتنفيذ والمعلومات اللازمة للمضي فيه.
يهم هذا الترتيب لأن قائمة طويلة من التعليقات قد تبدو شاملة حتى لو أساء المراجع فهم المشكلة. وينقل طلب إعادة الشرح الاهتمام من مدى احترافية صياغة النص إلى إمكانية أن يعمل شخص أو وكيل آخر بموجبه. فإذا كان الفهم خاطئا، فقد يفيد تصحيح جملة أساسية أكثر من إضافة صفحة من التعليمات. وإذا كان صحيحا، يمكن الانتقال إلى فحص التصميم نفسه.
كذلك تحتاج الجاهزية للتنفيذ إلى تفسير حذر. فقد تزيل وثيقة مفصلة الشك بشأن أسماء الملفات وبنى البيانات والواجهات، لكنها لا تحل محل اختبار الشفرة المكتوبة فعليا. كما أنها لا تفحص بمفردها جميع ظروف بيئة الإنتاج. وهي تعني وجود خطة محددة يمكن البدء بتنفيذها، لا حصول التغيير على موافقة شاملة من حيث السلامة أو ضمان خلوه من العيوب.
إضافة مفتوحة والمسؤولية باقية لدى المطورين
تقدم Google الإضافة ضمن نهج يحتفظ فيه الإنسان بالحكم الهندسي. ويشمل توثيق المستودع طرق تثبيت في Antigravity وClaude Code وCodex، إلى جانب إرشادات لبيئات أخرى. وعلى الفريق اختيار التوثيق الملائم لبيئته والإصدار الذي يستخدمه. ولا تضمن قائمة خيارات التثبيت سلوكا متطابقا أو مستوى الدعم نفسه في جميع بيئات العمل.
لم تقدم الشركة في إعلان الإطلاق مقارنة كمية تثبت عدد العيوب التي تمنعها الإضافة أو الوقت الذي توفره في كل مشروع. وقد يقلل التخطيط الإضافي إعادة العمل، لكنه يحتاج أيضا إلى وقت وقراءة وقرارات بشأن التعليقات. وربما تكون هذه الكلفة أوضح في مهمة صغيرة، بينما يختلف وزن التوضيح المبكر في تغيير يرتبط بعدة أنظمة. ويتوقف القرار على نطاق العمل.
بالنسبة إلى الفرق في إسرائيل، تتعلق الفائدة أساسا بمسار العمل مع أدوات التطوير القائمة. ولا يتضمن الإعلان مسارا منفصلا للمستخدمين في إسرائيل أو وعدا بدعم مخصص للعبرية. ويمكن استخلاص مبدأ أوسع: حين يستعد الوكيل لإجراء تغيير، ينبغي أن تكون التعليمات مفهومة بذاتها. فالوثيقة التي تعتمد على ذاكرة المحادثة قد تفقد معناها عند تغير الأداة أو المطور أو من سيتولى المراجعة.
الخبر هنا هو إتاحة أداة تحاول إعطاء التخطيط والمراجعة دورا واضحا في العمل مع الوكلاء. وهي لا تطلب من المهندس التوقف عن فهم النظام، بل تقترح طريقة لاختبار ما إذا كان هذا الفهم قد كُتب بصورة يستطيع الآخرون استخدامها. وإذا نجحت العملية، فلن تبقى المحادثة الطويلة المكان الوحيد الذي يحمل القصد: ستكون هناك وثيقة وقراء ناقدون وشخص يتحمل مسؤولية القرار النهائي.