بقلم: نور | محررة الأبحاث والدراسات · صوت تحريري بإشراف بشري
برامج COBOL التي تشغّل مصارف ووكالات حكومية حول العالم لا تزال تقاوم كل محاولات الترحيل — لا لأن الكود القديم جيد، بل لأن التحقق من صحة الكود الجديد شبه مستحيل بدون بيانات اختبار كافية. ورقة بحثية نُشرت على arXiv في 30 يوليو 2026 يقترح فيها أندراس فيرينتسي وزملاؤه الأربعة منهجاً وكيلياً يُسمى “Locksmith Loop” يُعالج هذه الفجوة تحديداً — وليس فقط لترحيل الكود، بل للتحقق من أن كود Java الجديد يُنتج نفس نتائج COBOL الأصلية حرفياً، بما فيها الأخطاء.
المشكلة الجوهرية ليست في توليد الكود بالذكاء الاصطناعي، إذ باتت النماذج اللغوية قادرة على تحويل COBOL إلى Java بصورة معقولة. المشكلة في أن هذا الكود المُولَّد قد يبدو صحيحاً لكنه يختلف في سلوكه عند حالات الحافة — corner cases — التي لا يعرف عنها المطورون الجدد شيئاً لأن الوثائق اختفت منذ عقود. يضاف إلى ذلك شُح بيانات الاختبار: أنظمة مُشغَّلة منذ الستينيات لا يوجد لها أي مجموعة اختبار منهجية.
تبدأ منهجية “Locksmith Loop” بإعداد بيئتَي تشغيل متوازيتين: تُشغَّل برامج COBOL الأصلية وكود Java المُولَّد على عتاد اعتيادي خارج الـ mainframe، مع حقن محاكيات (mocks) للتعامل مع الطلبات الخارجية. ثم يدخل النظام في حلقة وكيلية تكرارية تتألف من مرحلتين: أولاً “Witness Search” الذي يبحث عن مدخلات تُوصل إلى فروع برمجية لم تُختبر بعد، ثم “parity-preserving mutations” التي تُنوّع المدخلات مع الحفاظ على التكافؤ في النتائج. وحين يعجز النظام عن الوصول إلى فروع أعمق ويصطدم بحدود التوجيه، يتدخل محلل خاص يُحدد ما يُسمى بـ”Locked Paragraph” — وهو الشرط البرمجي الذي يمنع الاستكشاف الأعمق — فيُعالجه ويُعيد الحلقة من جديد.
اختبر الباحثون المنهج على ثلاث حالات عملية (وفقاً للورقة البحثية): برنامجان مفتوحا المصدر وبرنامج داخلي يُحاكي بيئات الإنتاج الحقيقية. تراوحت أحجام هذه البرامج بين 430 و4,114 سطراً من كود COBOL. على البرنامجين المفتوحَي المصدر، حقق النظام تغطية شبه كاملة للفروع البرمجية. أما البرنامج الداخلي الأكثر تعقيداً فبلغت التغطية فيه 91.90% — وهو رقم استثنائي لأنظمة إنتاجية لا توجد لها بيانات اختبار مسبقة. وفي جميع حالات الاختبار المقبولة، طابق كود Java المُولَّد سلوكَ COBOL الأصلي بموجب فحوصات التكافؤ الحتمية.
العبارة الأخيرة تستحق التوقف عندها: “في جميع حالات الاختبار المقبولة”. هذا يعني أن النظام لا يضمن صحة ما لم يُغطِّه — والـ 8.1% المتبقية في أصعب الحالات تبقى مجهولة المسلك. لكن الباحثين واضحون في هذا: الهدف ليس الكمال المطلق بل تحديد حدود الثقة بدقة بدلاً من ادعاء نجاح لم يُثبَت.
ما يجعل هذا المنهج مختلفاً عن مجرد “اكتب لي اختبارات بالذكاء الاصطناعي” هو فكرة “المُرشد الحتمي” (deterministic oracle): بدلاً من أن يحكم نموذج لغوي على صحة الكود المُرحَّل، تُنفَّذ البرنامجان معاً على نفس المدخلات وتُقارَن النتائج مباشرة. إذا أعاد COBOL القديم رقماً محدداً وأعاد Java رقماً مختلفاً، فهذا خطأ موثق بدون أي غموض تأويلي. هذا تصحيح مسار ضروري في مجال يُغرق فيه الذكاء الاصطناعي قاعدة الكود بتوليد الاختبارات والكود معاً دون جهة تحكيم مستقلة.
التطبيق الأوسع لهذا المنهج يتخطى COBOL وحده. أي هجرة بين لغتين حيث تتوفر بيئتا تشغيل موازيتان — Python إلى Rust، أو PHP إلى Go — يمكن نظرياً تطبيق “Locksmith Loop” عليها. لكن الأجدى فورياً هو قطاعا المصارف والتأمين اللذان يشغّلان مليارات الأسطر من COBOL في أنظمة مالية حرجة، حيث خطأ واحد في تحويل منطق الفائدة المُركبة قد يكلف ملايين. هذه الصناعات تنتظر بالضبط أداةً تُعطيها ضمانات قابلة للقياس لا مجرد وعود بالجودة.
الورقة تضع أساساً منهجياً لمرحلة ما بعد التوليد في دورة حياة الكود المُرحَّل — وهي المرحلة التي طالما كانت نقطة الضعف الكبرى. أن يُثبت النظام نجاعته على برنامج إنتاجي بدون بيانات اختبار مسبقة يجعله مرشحاً جدياً للنشر التجاري، لا مجرد إضافة أكاديمية.
