وكلاء البرمجة في المحرر: أين يفيدون فعلًا وأين يكلّفون وقتًا
الوكيل الذي يكتب ملفات كاملة يبدو مذهلًا في العرض ومتعبًا في مشروع حقيقي. هذا تقسيم عملي للمهام التي يجيدها والمهام التي تراجعها أطول من كتابتها.
الإجابة المختصرة
الوكيل يجيد المهام الميكانيكية الواسعة: إعادة التسمية عبر المشروع، كتابة الاختبارات لشيفرة قائمة، ترجمة نمط من ملف إلى عشرة ملفات مشابهة، وقراءة شيفرة لا تعرفها. ويكلّف وقتًا في القرارات المعمارية وفي أي شيء يعتمد على سياق غير مكتوب في المستودع — لأن مراجعة نتيجته عندها أطول من كتابتها.
في هذه الصفحة
السؤال الذي يستحق الطرح ليس "هل الوكيل جيد؟" بل متى تكون مراجعة ما ينتجه أقصر من كتابته بنفسك؟ هذا هو الميزان الوحيد الذي يهم في مشروع حقيقي.
المهام التي يربح فيها بوضوح
العمل الميكانيكي الواسع. إعادة تسمية عبر خمسين ملفًا، تحويل نمط قديم إلى جديد، إضافة معالجة أخطاء في كل نقطة استدعاء. المراجعة هنا سريعة لأن التغييرات متشابهة، والخطأ إن وقع يتكرّر بشكل ظاهر لا خفي.
الاختبارات لشيفرة قائمة. كتابة اختبارات لدالة موجودة عمل يعرف الوكيل مدخلاته ومخرجاته. وقيمة المراجعة عالية: اختبار خاطئ يفشل فورًا.
قراءة شيفرة لا تعرفها. "اشرح لي كيف تمرّ هذه الطلبية من الواجهة إلى قاعدة البيانات" أسرع من التتبّع اليدوي، ولا خطر فيه لأنك لا تعدّل شيئًا.
الترجمة بين الصيغ. JSON إلى نوع TypeScript، مخطط قاعدة بيانات إلى نموذج، استجابة API إلى واجهة. عمل متكرّر وممل ونتيجته قابلة للتحقّق فورًا.
المهام التي يخسر فيها
القرارات المعمارية. الوكيل سيقترح بنية، وستكون معقولة، ولن تعرف ما الذي استبعده ولماذا. تكلفة القرار المعماري تُدفَع لسنة، ومراجعته تتطلّب أن تفكّر في البدائل بنفسك — أي أن تعمل العمل كاملًا ثم تقارن.
كل ما يعتمد على سياق غير مكتوب. "لماذا هذا الحقل اسمه هكذا"، "لماذا لا نلمس هذه الوحدة"، "العميل الفلاني له حالة خاصة". هذه المعرفة في رؤوس الناس لا في المستودع، والوكيل يقرأ المستودع فقط.
التصحيح العميق. الوكيل ممتاز في اقتراح فرضيات وسيّئ في إثباتها. الخلل الذي يظهر مرة كل ألف طلب يحتاج قياسًا وتتبّعًا، لا اقتراحًا آخر.
التغييرات الصغيرة في شيفرة تعرفها جيدًا. كتابة ثلاثة أسطر بنفسك أسرع من وصفها ثم قراءتها ثم تعديلها.
الوكيل يزيح تكلفة الكتابة ويترك تكلفة المراجعة كما هي. لذلك يربح كلّما كثر ما يكتبه وقلّ ما تحتاج التفكير فيه.
ما الذي يرفع جودة النتيجة فعلًا
اكتب سياق المشروع في المستودع. ملف يشرح البنية والاصطلاحات والقرارات المتخذة يفيد الوكيل والمطور الجديد معًا. هذه أفضل استثمار لأنها تفيد مرتين.
اطلب خطة قبل الشيفرة. "ما الملفات التي ستتغيّر ولماذا؟" قبل "نفّذ". قراءة خطة من عشرة أسطر أرخص بكثير من مراجعة تغيير في عشرة ملفات، وهي المكان الذي تكتشف فيه أن الوكيل فهم المهمة خطأ.
اجعل التحقّق آليًا. اختبارات ومدقّق أنواع ومدقّق أسلوب. الوكيل الذي يستطيع تشغيلها يصحّح نفسه؛ وبدونها تصير أنت أداة التحقّق.
قسّم المهمة. طلب واحد كبير ينتج تغييرًا كبيرًا يصعب مراجعته. خمسة طلبات صغيرة تنتج خمس مراجعات سهلة.
المراجعة تبقى مسؤوليتك
الشيفرة التي تدمجها شيفرتك، مهما كتبها. وثلاثة أشياء تستحق التدقيق أكثر من غيرها فيما ينتجه الوكيل:
- معالجة الأخطاء. غالبًا موجودة شكلًا وناقصة معنى — تلتقط الاستثناء وتبتلعه.
- الحالات الحدّية. القوائم الفارغة، القيم المعدومة، الأرقام السالبة. النموذج يكتب للمسار السعيد.
- الاعتماديات الجديدة. الوكيل يضيف مكتبة بسهولة أكبر مما ينبغي. كل اعتمادية جديدة قرار يبقى بعدها.
وأخيرًا: لا تدمج شيفرة لا تفهمها. ليس لأنها ستكون خاطئة بالضرورة، بل لأنك ستكون أنت من يصلحها في الثالثة صباحًا.
أسئلة شائعة
- هل يستبدل الوكيل المطوّر؟
- لا، لأنه يزيح تكلفة الكتابة ولا يزيح تكلفة القرار والمراجعة. في المهام التي معظمها كتابة يربح كثيرًا، وفي المهام التي معظمها تفكير لا يقدّم شيئًا.
- كيف أحسّن نتائج الوكيل في مشروعي؟
- اكتب سياق المشروع في المستودع نفسه، واطلب خطة قبل التنفيذ، واجعل الاختبارات ومدقّق الأنواع قابلين للتشغيل من قِبله ليصحّح نفسه.
- ما أخطر ما ينتجه الوكيل؟
- معالجة أخطاء موجودة شكلًا وناقصة معنى، وحالات حدّية غير مغطاة، واعتماديات جديدة أُضيفت بسهولة أكبر مما ينبغي.
- هل أراجع كل سطر؟
- راجع كل ما ستدمجه. إن كان التغيير أكبر من أن يُراجَع، فالمشكلة في حجم الطلب لا في المراجعة — قسّمه.
المصادر
- Model Context Protocol — Anthropic
- Language Server Protocol Specification — Microsoft
نشرته
MrBebo
محتوى تقني عربي يقدمه بهاء طه حول البرمجة، الذكاء الاصطناعي، Web2 وWeb3، تطوير التطبيقات، بناء المنتجات وأدوات المطورين.
عن المدوّنة
