شِعرية التطوير بالوكلاء الذكيين: كيف تكتب الكود مع الوكلاء حين تُنتج السهولة تعقيدًا

السهولة في مقابل البساطة

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

الفرق الأساسي هو بين السهل (easy، وهو مفهوم ذاتي يعتمد على الخبرة) والبسيط (simple، وهي خاصية موضوعية للنظام). فاللغة الروسية سهلة لمتحدثيها الأصليين، لكنها صعبة بالنسبة إلى الأجنبي. أما التعقيد فهو تشابك جوانب مستقلة، أي "تعدد الأجزاء" بمعناه الحرفي. وقد يكون مبدأ DRY رائحة كود سلبية (code smell)، لكن التكرار يُبسّط النظام في بعض الأحيان ويقلل من الاقتران بين أجزاء الكود.

الترميز الحدسي (vibe coding) مع الوكلاء الذكية سهل للغاية، لكن الأنظمة الناتجة غالبًا ما تكون معقدة. ويتحمل المطور المسؤولية الكاملة عن الكود الذي تُنتجه نماذج اللغة الكبيرة، وكلما زاد تعقيد الكود، زادت صعوبة فهمه، وقلّت الموثوقية والضمانات المتعلقة بوقت الوصول إلى السوق (time-to-market) واتفاقيات مستوى الخدمة (SLA).

هل تفهم نماذج اللغة الكبيرة التعقيد؟

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

قائمة الأبحاث: • τt-Bench: تُؤتمت الوكلاء الذكية كتابة الكود، لكن ليس التفكير الهندسي. فعندما يفشل اختبار، يُصحح الوكيل الاختبار نفسه لا الكود. ويتجاهل الوكيل متطلبات بيئة الإنتاج، وقابلية إعادة الاستخدام، والحدود البنيوية للنظام.

• SlopCodeBench: تُنشئ نماذج اللغة الكبيرة أكوادًا أطول بمقدار 2.3 مرة مقارنة بالبشر. ويبلغ التراجع وفق مقياس تآكل البنية (structural erosion، وهو تراكم التعقيد داخل الدوال) نحو 6 أضعاف.

وكان أفضل نموذج في التجارب هو GPT-5.5. • Estimating problem difficulty: يبلغ معامل الارتباط بين تقييمات نماذج اللغة الكبيرة وتقييمات البشر لصعوبة المهام 0.

8 (وفق معامل بيرسون). • Can LLMs Estimate Student Struggles: لا تتكيف النماذج مع خبرة الشخص المحدد، ولا تتوقع الصعوبات الشخصية التي قد يواجهها. • Rethinking Code Complexity: دراسة للتعقيد من خلال عمق التداخل والتفرّع في الكود.

• Beyond Strict Rules: تستطيع نماذج DeepSeek-R1 وGPT-5 mini وLlama-3.3 وQwen2.5-Code اكتشاف روائح الكود (code smell) البسيطة، لكنها تُفوّت الروائح الأكثر تعقيدًا التي يراها البشر بوضوح.

• The Modular Imperative: يُقسّم نموذج Claude Sonnet 4 الكود عبر ملفات متعددة ويكتب عن فصل الاهتمامات (separation of concerns)، لكنه في الوقت نفسه يربط الكيانات بشكل ضمني ويُعقّد النظام.

التوازن بين التحكم والاستقلالية

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

يفترض الكاتب وجود نقطة مثالية، حيث تُعطي الاستثمارات الإضافية من الجهد عائدًا أقل فأقل (قانون تناقص الغلة). فعلى سبيل المثال، إذا كتبت قالبًا (template) لخمسين اختبارًا متشابهًا، فستبذل جهدًا كبيرًا، لكن الوكيل سيعيد صياغة بقية الاختبارات بنفسه بالقياس عليها — وكانت القيمة الحقيقية تكمن في أول 20% من الجهد المبذول.

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

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