وحدات التعديل (Mods) في Claude Code من Anthropic تتيح للمطورين إعادة كتابة الوكيل نفسه

أطلقت Anthropic ميزة تسميها «mods» لـ Claude Code. الفكرة موجزة: دوال TypeScript صغيرة تغيّر سلوك وكيل البرمجة، تُحمَّل في الأداة بدل أن تكون مدمجة في النموذج.

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

لماذا تتفوق دالة على إعداد؟

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

أما الـ mod فهو كود. يُنفَّذ، ويعيد قيمة، ويكون ناتجه حتميًا. وهذا يغيّر طبيعة التحكم. فإذا أردت ألا يمسّ الوكيل مجلدًا بعينه مطلقًا، يمكن لـ mod موضوع في المكان الصحيح أن يفرض ذلك بدل أن يطلب الأمر بلطف. وإذا أردت تطبيق تحويل معيّن على كل فرق (diff) قبل أن يصل إلى المراجعة، يستطيع الـ mod فعل ذلك في كل مرة، لا في معظمها.

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

طبقة التخصيص هي حيث انتقلت المنافسة

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

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

ما تقوله الـ mods عن الثقة

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

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

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

خط «ابنِ أم اشترِ» يتحرك مرة أخرى

على مدى سنوات، كان السؤال في أدوات المطورين هو: هل تبني أداتك بنفسك أم تشتريها؟ وقد حرّك وكلاء البرمجة هذا الخط. والـ mods تحرّكه مرة أخرى، وفي اتجاه محدد: يبقى النموذج سلعة مشتراة، أما السياسة المحيطة به فتصبح شيئًا تبنيه في بضع عشرات من أسطر TypeScript.

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

القابلية للتوسع هي كيف تنجو الأداة من نجاحها

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

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

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

إلى أين يتجه هذا بعد ذلك

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

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

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

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