مستخدمو Claude Code يوافقون على 93% من الطلبات — والإشراف يتحول إلى إجراء شكلي

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

يورد مقال على Habr عن إرهاق الإشراف مؤشرًا من Anthropic: مستخدمو Claude Code يوافقون على 93% من طلبات التأكيد. هذه النسبة وحدها لا تثبت قلة الانتباه، فمعظم الإجراءات قد تكون آمنة فعلًا. لكنها تطرح سؤالًا مفيدًا على مستوى المنتج: أي خطأ تستطيع واجهتكم إيقافه إذا كان السيناريو المعتاد للتعامل معها هو الموافقة والمتابعة؟

لماذا يتوقف الزر عن الحماية

الشخص الذي ينفذ المهمة بنفسه يبني فهمه لما يجري تدريجيًا. أما مراجِع الوكيل فعليه أن يستعيد هذا الفهم من أفعال غيره: ما الملفات التي قُرئت، ولماذا اختير هذا الأداة، وما الذي تغيّر بالفعل، وما عواقب الأمر التالي. ونادرًا ما تتسع نافذة تأكيد منفصلة لكل هذا السياق.

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

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

ما الذي يجب تغييره في المنتج والعملية

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

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

الخطوة الثالثة هي فحص النتيجة بالوسائل التقنية المتاحة. هل الملف الموعود موجود؟ وهل يُفتح؟ وهل يطابق محتواه المهمة؟ وهل تنجح الفحوص؟ هذه الأسئلة مهمة خصوصًا حين تنتهي الأداة بخطأ ويُبلغ الوكيل مع ذلك بثقة عن نجاح. فالملخص الجميل لا يثبت أن العمل أُنجز.

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

من يجب أن يراجع الوكيل

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

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

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