يكتب الوكيل الشيفرة — فمن يراجع عمله؟

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

في 4 فبراير 2026، أعلنت GitHub عن إتاحة Claude وCodex للمعاينة العامة بوصفهما وكيلين للبرمجة. وذكرت الشركة أنه يمكن إسناد المهام إلى الوكلاء من خلال issues وطلبات الدمج، ثم مراجعة مسودة PR التي أعدوها. وهذا يؤكد أن هذا السيناريو أصبح متاحًا في واجهة التطوير، لكنه لا يثبت توفير الوقت أو تحسين جودة الشيفرة.

لذلك لا يقتصر السؤال على قدرة الوكيل على كتابة الشيفرة. المهم هو العمل الذي يتعين على الإنسان إنجازه حول المهمة المفوّضة: وضع القيود، ومتابعة سير العمل، وتقييم النتيجة.

الإشراف ليس مجرد مراجعة نهائية

في بحث أولي نُشر على arXiv في 21 سبتمبر 2026، يقترح الباحثون النظر إلى الإشراف على وكيل البرمجة باعتباره عملية متتابعة. ويستند بحث العمل الكامن وراء التفويض إلى ملاحظات ومخططات لسير العمل لدى 19 مطورًا خبيرًا. ويصف المؤلفون سبع مراحل للإشراف، ثم يطبقون هذا الإطار على نقاشات عامة للمطورين في Reddit.

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

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

تجارب المجتمع ليست إحصاءات

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

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

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

مسودة PR ليست طلب دمج مقبولًا بعد

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

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

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

ما الذي يمكن استنتاجه؟

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

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

أما السؤال العملي للفريق فهو أكثر تحديدًا: ما التغييرات التي يمكن للوكيل إعدادها بمفرده، وما الذي ينبغي التحقق منه قبل الدمج، ومن المسؤول عن ضمان أن تحل النتيجة المهمة الأصلية؟ لا يلغي التفويض هذا العمل الهندسي، بل يغير موضع بدايته ومحور تركيزه.