تقييم خط أنابيب نقل المواصفات">المرحلة الأولى: تقييم خط أنابيب نقل المواصفات
في البداية، تم اختبار خط أنابيب نقل يعتمد على المواصفات عبر 1,006 ملف PL/SQL. من بين هذه الملفات، تم تجديد 623 بنجاح، في حين أن 380 من السكريبتات الناتجة قدّمت تنفيذًا ناجحًا في PostgreSQL 16.
تجارب عبر الوكلاء">المرحلة الثانية: تجارب عبر الوكلاء
ثم تم إجراء تجارب عبر الوكلاء باستخدام مجموعة بيانات تتضمن 1,802 سكريبت من Oracle وجميع مراسلاته في PostgreSQL. شملت هذه التجارب أدوات مثل Amazon Kiro وGoogle Gemini وGitHub Copilot، بالإضافة إلى Claude Code وCursor في التقييم الأولي.
نتائج مثيرة للاهتمام">نتائج مثيرة للاهتمام
أظهرت النتائج التي تم الحصول عليها أن حجم المواصفات وحده لا يمكن أن يتنبأ بجودة التنفيذ. إذ اكتشف الباحثون أن النقل بين الوكلاء يمكن أن يؤدي إلى تدهور كبير يعتمد على الوكيل. على سبيل المثال، كانت الحالة الأضعف عندما استهلك Gemini مباشرةً specification من Kiro، محققةً معدل Token F1 بلغ 0.035.
ورغم أن تحسين الكتابة ساهم في تحسين جودة Gemini، إلا أن الضغط (compression) لم يوفر فائدة شاملة. كذلك، كانت الاستراتيجيات المعتمد عليها في إدراج البيانات المدعومة بمعالجة أكثر الطرق شيوعًا في Pareto frontiers لكل من Gemini وCopilot.
استنتاجات مهمة">استنتاجات مهمة
تشير النتائج إلى أنه يجب عدم التعامل مع المواصفات في سير العمل المتباين كأشياء محايدة بين الوكلاء. بل من الأهمية بمكان التفكير بوضوح في قابلية نقل المواصفات، والتفسير الخاص بالوكيل، والجدارة بالاسترجاع في هندسة البرمجيات متعددة الوكلاء.
هل تعتقد أن قدرتنا على نقل المواصفات بين الوكلاء ستغير طريقة تطوير البرمجيات بشكل جذري؟ شاركونا آراءكم في التعليقات!