Claude Fable 5.2 يزيل تكرار الشيفرة بشكل أكثر تكرارًا عند تعيينه مالكًا لها

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

هذه نقطة مفيدة لمن يضبطون وكلاء التطوير. فصياغة الدور قد تغيّر حجم التعديلات. لذلك ينبغي اختبار هذه التعليمات مع جودة النتيجة وتكلفة التشغيل ووقت المراجعة.

ما اكتشفته Anthropic

في الملاحظة الأصلية يقتبس سايمون ويليسون من وثائق Anthropic أن اقتراح إسناد ملكية المشروع إلى النموذج رفع تكرار إزالة التكرار من أقل من 10% إلى نحو 50%. غير أن مراجعة المصدر الأولي كشفت تباينًا: فهو يورد الآن صياغة مختلفة للتعليمات ونتيجة تبلغ نحو 75% مقابل مستوى أولي أقل من 10%. ولا يصح اعتبار هذه الأرقام نتاج تجربة واحدة لم تتغير.

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

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

كيف يبدو ذلك في مهمة عادية

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

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

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

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

ثمن الاستقلالية

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

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

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