خمس ممارسات لاستخدام وكلاء البرمجة بالذكاء الاصطناعي لتحسين هندسة البرمجيات

يمكن لوكلاء البرمجة بالذكاء الاصطناعي أن يساعدوا فرق البرمجيات في معالجة مشكلات معمارية تتجاوز مجرد كتابة الكود، لكن فائدتهم تعتمد على وضوح الأهداف والقيود التي يحددها الفريق. فالمقال المنشور في InfoQ، من إعداد Pierre Pureur وKurt Bittner وTodd Miller ومراجعة Daniel Bryant، يحذر من أن تزويد الوكيل بمتطلبات وظيفية فقط لا يضمن بنية قابلة للتوسع أو آمنة أو سهلة الصيانة.

ويستند النهج المقترح إلى متطلبات سمات الجودة (Quality Attribute Requirements أو QARs)، مثل الأداء والأمان وقابلية التوسع، وإلى توضيح المفاضلات التي ينبغي أن يراعيها الوكيل. كما يشدد المقال على ضرورة اختبار ما ينتجه الوكيل بقياسات واضحة، بدلاً من الاكتفاء بفحص الكود أو الثقة في توصياته.

1. توثيق الخدمات القديمة قبل الاعتماد عليها

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

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

2. البحث عن العيوب المعمارية

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

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

3. تدقيق الأمان مع عزل الوكيل

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

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

4. إنشاء أساس معماري للنماذج الأولية

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

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

5. توليد معماريات أولية قابلة للاختبار

يقترح المقال استخدام الوكيل لإنشاء Minimum Viable Architectures أو MVAs، بحيث لا تقتصر على كود يثبت الوظائف، بل تتضمن أيضاً الاختبارات وبيانات الاختبار وبيئة التشغيل اللازمة للتحقق من QARs. ويمكن للوكيل توليد أدوات الاختبار وإعدادات الحاويات، لكن الفريق يجب أن يتأكد من أن الاختبارات تقيس فعلاً السمات المطلوبة.

كما ينبغي تقييم قدرة الـMVA على استيعاب حالات التغيير المعمارية، لأن توسيع بنية مولدة آلياً قد يصبح مكلفاً إذا لم تكن مصممة للتطور.

ما الذي يتغير عملياً؟

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