لماذا يعدل الوكيل البرمجي ملفات لم تطلب منه تغييرها

لماذا يعدل الوكيل البرمجي ملفات لم تطلب منه تغييرها

عالم البرمجة

مطور يراجع ملفات إضافية عدلها وكيل برمجي داخل مشروع

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

ربما ظهر تعديل في اختبار، أو تعريف نوع، أو ملف إعداد، أو جزء من الخادم لم تذكره في طلبك.

هنا يصعب معرفة هل الوكيل فهم ترابط المشروع، أم خرج ببساطة عن النطاق.

الإجابة ليست واحدة.

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

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

لذلك لا تعتبر كل ملف إضافي علامة ذكاء، ولا تعتبره خطأ بمجرد أن اسمه لم يظهر في طلبك.

السؤال الصحيح هو لماذا تغير هذا الملف، وهل تستطيع ربط تغييره مباشرة بالنتيجة المطلوبة قبل قبول التعديل.

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

الوكيل يعمل على هدف المهمة لا على أسماء الملفات فقط

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

في وضع الوكيل في بعض أدوات البرمجة الحديثة، تحدد له النتيجة التي تريدها ثم يقرر هو الملفات والخطوات التي يحتاج إليها.

توثيق GitHub Copilot، مساعد غيت هب كوبايلوت، يوضح مثلا أن وضع الوكيل يستطيع تحديد الملفات

 التي سيغيرها، واقتراح أوامر طرفية، ثم تكرار المحاولة لمعالجة المشكلات حتى ينجز المهمة.

لهذا فإن قولك عدل رسالة الخطأ لا يعني تقنيا دائما عدل هذا الملف فقط.

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

لكن هذه الاستقلالية ليست دليلا على أن قراره صحيح.

هي تعني فقط أن نطاق عمله مبني على تفسير الهدف، ولذلك يحتاج النطاق نفسه إلى مراجعة.

ليس صحيحا أن كل وكيل يبني خريطة كاملة للمشروع

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

وقد يستنتج العلاقات من النص والسياق من دون بناء تمثيل موحد وكامل لكل المستودع.

حتى عندما تستخدم الأداة تحليلا بنيويا أو معلومات من خادم اللغة، يبقى قرار الوكيل بشأن 

ما يجب تغييره قرارا استدلاليا يمكن أن يصيب أو يخطئ.

معرفة أن دالة تستخدم في ثلاثة مواضع لا تثبت أن المواضع الثلاثة يجب تعديلها بالطريقة نفسها.

الفكرة الأدق أن الوكيل يجمع أدلة من المشروع وأدواته ليبني خطة عمل.

جودة الخطة تعتمد على ما استطاع رؤيته، والتعليمات التي تلقاها، والنتائج التي ظهرت أثناء التنفيذ.

بعض الملفات الإضافية ضرورية فعلا لإكمال التغيير

أحيانا يكون الملف الذي لم تطلبه جزءا حقيقيا من الميزة.

إذا غيرت توقيع دالة فقد تحتاج مواضع استدعائها إلى تحديث.

وإذا أضفت خاصية إلى واجهة بيانات فقد تحتاج الأنواع والاختبارات أو طبقة التحويل إلى التوافق معها.

هنا يصبح التعديل الإضافي نتيجة للتبعية لا للرغبة في تحسين المشروع.

الملف الأول لا يستطيع العمل وحده لأن العقد البرمجي بينه وبين أجزاء أخرى تغير.

الاختبار الجيد هو أن تطلب سببا محددا لكل ملف.

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

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

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

الاختبارات وأدوات البناء قد توسع النطاق بعد الخطوة الأولى

سبب آخر شائع يظهر بعد تنفيذ التعديل الأول.

يشغل الوكيل اختبارا أو مترجما أو أداة فحص ساكن، فتظهر أخطاء في ملفات لم تكن واضحة 

عند بداية المهمة.

في هذه الحالة لا يكون الوكيل قد عرف كل شيء مسبقا.

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

هذه الحلقة جزء مهم من العمل الوكيلي الحديث.

مثلا قد يتغير نوع قيمة في ملف، ثم يكشف مترجم تايب سكربت أن استدعاء آخر لم يعد متوافقا.

وقد يتغير سلوك دالة، فيفشل اختبار كان يوثق السلوك القديم.

اقرأ ايضا : لماذا يفشل كود الذكاء الاصطناعي رغم أنه يبدو صحيحا

عندها قد يكون تعديل الملف الثاني منطقيا.

لكن فشل الاختبار لا يعطي الوكيل إذنا مفتوحا لتغيير الاختبار حتى يمر.

أحيانا يكون الاختبار هو الذي كشف أن التغيير الأول خاطئ.

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

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

ليست كل التغييرات التي تظهر بعد جلسة الوكيل ناتجة عن قرار تحرير مباشر منه.

بعض الأوامر التي يشغلها تستطيع تحديث ملفات تلقائيا.

مدير الحزم قد يحدث ملف القفل، وأداة التنسيق قد تعيد تنسيق ملف كامل، ومولد الشفرة 

قد يعيد إنشاء ملفات مشتقة، وأداة ترحيل قد تنشئ ملفا جديدا.

لذلك نسبة كل تغيير إلى فهم عميق من الوكيل قد تكون خاطئة.

هذه النقطة مهمة عند التشخيص.

اسأل ما الأمر الذي سبق ظهور الملف.

إذا تغير بعد تشغيل أداة معروفة بإعادة الكتابة، فمصدر التغيير قد يكون الأداة نفسها، بينما قرار الوكيل كان مجرد تشغيلها.

وقد يكون الملف مولدا أصلا ولا يفترض تحريره يدويا.

ملفات الأنواع المولدة وملفات القفل وبعض مخرجات البناء قد تتغير لأن مصدرها

 تغير أو لأن أداة أعادت توليدها.

هنا راجع المصدر الذي أنشأها، لا شكل التعديل وحده.

كذلك لا تفترض أن كل ملف ظهر في حالة Git، نظام غيت، صنعه الوكيل في الجلسة الحالية.

قد تكون لديك تغييرات سابقة غير محفوظة.

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

لهذا تساعد السجلات الواضحة وسجل الأوامر في فهم ما جرى.

OpenAI، أوبن أي آي، تصف القيود والسجلات والموافقات كجزء أساسي من تشغيل وكلاء البرمجة بأمان، لأن معرفة ما فعله الوكيل لا تقل أهمية عن رؤية النتيجة النهائية.

أحيانا يكون الملف الإضافي مجرد انحراف عن النطاق

ليس كل توسع مبررا.

الوكيل قد يرى فرصة لإعادة تسمية دالة، أو توحيد تنسيق، أو تحديث تعليق، أو إعادة تنظيم ملف مجاور

 لأنه يعتقد أن ذلك يحسن الحل.

وقد يستنتج أن نمطا معماريا يجب تغييره بينما لم تكن المهمة تحتاج ذلك.

هنا يظهر Scope Drift، انحراف النطاق.

المشكلة ليست أن الملف بعيد فقط، بل أن التغيير لا يملك سببا ضروريا يمكن ربطه بوعد المهمة.

قد يحدث الانحراف أيضا بسبب تعليمات عامة مثل حسن الكود أو أصلح أي مشكلة تراها.

هذه العبارات توسع مساحة القرار بشدة.

وكلما اتسعت المهمة زادت فرصة أن يخلط الوكيل بين المطلوب والتحسين الممكن.

ولهذا لا تتعامل مع التعديل الإضافي على أنه ميزة متقدمة . 

قد يكون هندسة صحيحة، وقد يكون اجتهادا غير مطلوب، والتمييز بينهما مسؤولية المراجعة.

التعليمات تضيق سلوك الوكيل لكنها ليست دائما حاجزا تقنيا

يمكنك كتابة تعليمات واضحة مثل لا تعدل ملفات قاعدة البيانات، أو لا تغير واجهات عامة، أو توقف

 قبل إضافة أي تبعية جديدة.

كما تستطيع بعض الأدوات قراءة تعليمات مستودع دائمة أو تعليمات خاصة بمسارات معينة.

غيت هب مثلا يدعم تعليمات على مستوى المستودع وتعليمات مرتبطة بمسارات محددة، بينما يقرأ Codex، وكيل كوديكس، تعليمات المشروع ويعمل أيضا ضمن حدود للصلاحيات والكتابة تحددها بيئة التنفيذ.

لكن هناك فرق مهم بين التعليمات والصلاحيات.

التعليمات توجه النموذج، وقد لا تنفذ بالطريقة نفسها في كل مرة.

أما قيد الكتابة في بيئة معزولة فهو حاجز تقني يمنع التعديل خارج المسارات المسموح بها.

إذا كان الملف حساسا جدا فلا تعتمد على جملة في الموجه وحدها.

استخدم الأداة التي تسمح بتحديد مجموعة الملفات، أو صلاحيات كتابة محدودة، أو بيئة معزولة، أو خطوة موافقة قبل تجاوز الحدود.

المقال القريب في أرشيف تقني1 يشرح كيف تراجع كودا أنشأه وكيل برمجي من دون قراءة كل سطر.

أما هنا فالسؤال أسبق من ذلك، لماذا دخل هذا الملف إلى التعديل أصلا.

ابدأ بقائمة الملفات المتغيرة.

Git Status، حالة غيت، يعرض حالة شجرة العمل والملفات التي تغيرت.

ثم استخدم Git Diff، فروق غيت، لرؤية ما تغير داخل الملفات التي تحتاج إلى تفسير.

لا تبدأ بسؤال هل الكود جميل.

ابدأ بسؤال لماذا هذا الملف موجود في الحزمة.

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

أو تغيير لا تجد له علاقة كافية بالمهمة.

إذا لم تستطع وضع الملف في سبب واضح فلا تقبله تلقائيا.

اطلب من الوكيل شرح حاجته، أو أعد المهمة بنطاق أضيق، أو استرجع الملف وحده ثم شغل الاختبارات

 لترى هل كانت الحاجة إليه حقيقية.

استخدم اختبار سبب الملف قبل قبول التعديل

استخدم اختبار سبب الملف لمعرفة ما إذا كان التعديل ضروريًا للمهمة أم توسعًا غير مبرر من الوكيل.

ابدأ بالصلة.

ما الجزء من طلبك الذي يحتاج هذا الملف تحديدا.

ثم افحص المصدر.

هل عدله الوكيل مباشرة، أم تغير نتيجة أداة شغلها أثناء العمل.

بعد ذلك افحص الدليل.

هل يوجد خطأ مترجم أو اختبار أو اعتماد برمجي يبرر التعديل، أم أن السبب مجرد تفضيل تحسيني.

ثم افحص الحد.

هل كانت تعليمات المستودع أو المهمة تسمح بهذا النوع من التغيير.

وأخيرا افحص القابلية للعكس.

إذا استعدت هذا الملف وحده إلى حالته السابقة، هل تفشل الميزة أو الاختبارات ذات الصلة.

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

الهدف من الاختبار ليس إجبار الوكيل على لمس ملف واحد دائما.

الهدف أن يصبح لكل ملف إضافي سبب يمكن الدفاع عنه ومراجعته.

أفضل وكيل ليس الذي يعدل أكثر بل الذي يبرر نطاقه

الوكلاء البرمجيون مفيدون لأنهم يستطيعون الانتقال بين الملفات وتشغيل الأدوات ومتابعة أثر التغيير من دون أن تحدد لهم كل سطر مسبقا.

لو منعتهم دائما من لمس أي ملف إضافي فقد تحولهم إلى محرر موضعي وتفقد جزءا من فائدتهم.

لكن الطرف الآخر أخطر.

قبول كل توسع باعتباره دليلا على أن الوكيل فهم المعمارية يحول الاستقلالية إلى ثقة عمياء.

الوكيل لا يملك حق تغيير المشروع لمجرد أنه وجد شيئا يمكن تحسينه.

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

دع الوكيل يتوسع عندما يستطيع ربط التوسع بهدف المهمة أو بنتيجة اختبار واضحة، واطلب منه التوقف عندما يصبح السبب تحسينا جانبيا أو تخمينا.

اقرأ ايضا :كيف تختار مشروعًا برمجيًا يثبت مهارتك حتى لو فكرته مألوفة

عندما ترى ملفا لم تذكره في طلبك لا تسأل فقط لماذا لم يلتزم الوكيل.

اسأل ما الدليل الذي جعل هذا الملف جزءا من الحل.

إذا كان الدليل قويا فالتعديل الإضافي قد يكون علامة على تكامل الحل.

وإذا لم يوجد دليل واضح فالاتساع نفسه هو المشكلة التي يجب تصحيحها.