لماذا وكلاء البرمجة غبيون إلى هذا الحد؟

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

كنت أعتقد أنه بعد ستة أشهر ستصبح الوكلاء مبهرة تقنيًا بقدر النماذج اللغوية الكبيرة التي تعمل بداخلها. لكن وكلاء البرمجة ظلوا ضعفاء. لقد تقدم التطوير المدعوم بالذكاء الاصطناعي بوضوح، لكن النماذج هي التي تتحمل العبء الأكبر، بينما يظل الوكلاء عنق الزجاجة. والفرق مهم: فالنموذج، مثل GPT Astra أو Claude Sonnet أو GLM-5.3، يولّد النص والشيفرة، أما الوكيل، مثل Claude Code من Anthropic أو Codex من OpenAI، فهو البرنامج الذي يربط ذلك النموذج بقواعد الشيفرة وأنظمة الحاسوب. وكما تقول إحدى المقارنات، فالنموذج هو الدماغ والوكيل هو الجسد.

أكبر الشكاوى تتعلق بسوء إدارة الوكلاء للمهام. في أحد الأمثلة، احتاج تطبيق ويب مفتوح المصدر إلى ميزة حماية بكلمة مرور تبلغ نحو 1.5 ألف سطر. قسّم الوكيل العمل إلى 10 مهام فرعية ثم نفذها واحدة تلو الأخرى، رغم أنه كان يمكن تشغيلها بالتوازي على حاسوب مصمم للتعدد في المهام. يؤدي Claude Code قدرًا قليلًا من تعدد المهام فقط، إذ ينتظر انتهاء الوكلاء الفرعيين واختبارات الطرف إلى الطرف قبل أن يتابع.

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

المصدر: Hacker News · لخّصه HeadlinesBriefing