أصبحت وكلاء الذكاء الاصطناعي مفيدة في صيانة برمجيات الأبحاث
يشير تقرير ميداني جديد من OpenAI وشركاء أكاديميين إلى استخدام عملي وأقل بريقًا لأنظمة البرمجة بالذكاء الاصطناعي: إصلاح وتحديث البرمجيات المهملة التي يقوم عليها جزء كبير من البحث العلمي. لا يقدّم التقرير هذه الأنظمة بوصفها مفكرين علميين مستقلين. بل يوضح أنها تعمل كعمال برمجيات سريعين يمكنهم إعادة هيكلة الشيفرة، واستبدال الأدوات القديمة، ونقل الأطر البرمجية، وفي بعض الحالات تقديم مكاسب أداء كبيرة للغاية.
هذا التمييز مهم. فقد بدأت كثير من أدوات البحث كشيفرات كُتبت لدعم ورقة علمية واحدة أو سير عمل ضيق داخل مختبر. ومع مرور الوقت، أصبحت تلك الأدوات جزءًا من خطوط عمل علمية أوسع رغم أنها لم تُبنَ مع مراعاة الصيانة طويلة الأمد أو الاختبار أو سهولة النقل. وعندما يغادر المؤلفون الأصليون وتندر التمويلات، تبقى المختبرات معتمدة على قواعد شيفرة هشة لكنها ما تزال حيوية.
تشير الحالات الواردة في التقرير إلى أن وكلاء البرمجة قد يكونون مناسبين جدًا لهذا النوع من الأعمال المتراكمة. فهم قادرون على قراءة قواعد شيفرة كبيرة، واقتراح الترقيات، والترجمة من إطار أو لغة إلى أخرى، وتوليد البنية المحيطة مثل أنظمة البناء، وخطوات التثبيت، والاختبارات. لكن التقرير يرسم أيضًا حدًا واضحًا لما يمكن لهذه الأنظمة فعله وما لا يمكنها فعله. قد تتمكن من إعادة كتابة البرمجيات بسرعة، لكنها لا تُعد حكمًا موثوقًا على ما إذا كان السلوك العلمي للنظام المعاد كتابته صحيحًا بالفعل.
من تنظيف البناء إلى إعادة الكتابة الكاملة
يغطي التقرير ثماني دراسات حالة، معظمها في علم الأحياء. ويتراوح العمل من مهام صيانة محدودة نسبيًا إلى عمليات إعادة كتابة كبيرة لبرمجيات علمية متقادمة.
تناولت إحدى الأمثلة الأبسط cyvcf2، وهي مكتبة بايثون تُستخدم لقراءة البيانات الجينية. في تلك الحالة، استبدل GPT-5.5 إعدادات بناء وتثبيت قديمة بأخرى أكثر حداثة. هذا النوع من العمل غالبًا ما يكون مملًا لكنه مهم: فإذا أصبحت البرمجيات صعبة التثبيت أو الترجمة، فقد تظل ذات صلة علمية بينما تصبح هشة تشغيليًا.
أما المشروع الأكثر تعقيدًا فتمحور حول MHCflurry، وهو نموذج مناعة يُستخدم للتنبؤ بالأهداف التي ستتعرف عليها الخلايا المناعية. ووفقًا للتقرير، تناوب Claude Code وCodex بين أدوار المطور والمراجع أثناء نقل نحو 10,000 سطر من الشيفرة من TensorFlow إلى PyTorch. وهذا من أنواع النقل التي تؤجلها كثير من الفرق لسنوات لأنه مكلف ومحفوف بالمخاطر وسهل الإفساد.

أكثر الأمثلة طموحًا المبرزة في النص الأصلي هو rustar-aligner، وهو إعادة كتابة بلغة Rust لأداة STAR، وهي أداة واسعة الاستخدام لمحاذاة قراءات التسلسل إلى مواقع الجينوم. يحتوي STAR على أكثر من 20,000 سطر من C وC++ ولم يعد يخضع لصيانة نشطة، رغم أنه لا يزال جزءًا من كثير من خطوط البحث. إعادة بناء أداة كهذه ليست مجرد تمرين برمجي. إنها تنطوي على خطر إدخال تغييرات دقيقة قد تغيّر التحليلات اللاحقة إذا اختلفت النتائج.
مكاسب الأداء حقيقية، لكن الثقة يجب أن تُكتسب
المكاسب المبلّغ عنها كبيرة بما يكفي لتفسير اهتمام المختبرات. يذكر النص الأصلي أن الجهود التي قادتها وكلاء البرمجة حققت تسريعًا بأكثر من 60 مرة في بعض الحالات. أوضح مثال هو RustQC، الذي جمع 15 أداة منفصلة لمراقبة الجودة في برنامج واحد. وعلى مجموعة بيانات كبيرة، انخفض زمن التشغيل من 15 ساعة و34 دقيقة إلى 14 دقيقة و54 ثانية. وبالنسبة للباحثين العاملين على مجموعات بيانات بيولوجية ضخمة، يمكن لمثل هذا الانخفاض أن يغيّر بشكل ملموس عدد مرات تشغيل التحليلات وسرعة التكرار التجريبي.
لكن السرعة ليست هي القصة الأساسية. السؤال الأهم هو ما إذا كانت الأدوات المعاد كتابتها ما تزال تتصرف مثل الأصلية بطرق ذات معنى علمي.
في حالة rustar-aligner، قارن الفريق بين النسخة المعاد كتابتها وSTAR باستخدام 10,000 قراءة تسلسلية قصيرة من خلايا الخميرة. بالنسبة للقراءات أحادية الطرف، طابقت الأداة الجديدة STAR في 99.815 بالمئة من الحالات. وبالنسبة للقراءات ثنائية الطرف، وصل التطابق إلى 99.883 بالمئة. ولم تقتصر المقارنة على المواقع المحاذاة في الجينوم، بل شملت أيضًا عدة حقول إخراج رئيسية تُنتج لكل قراءة. ويضيف النص الأصلي أن أياً من الأداتين لم ينجح في محاذاة قراءات فشلت الأخرى في محاذاتها.
هذه أرقام توافق قوية، لكنها تُظهر أيضًا القيد الجوهري للبرمجيات العلمية المولدة بالذكاء الاصطناعي. يمكن للنموذج أن ينتج شيفرة مقنعة وحتى اختبارات تبدو معقولة، لكن البشر ما زالوا بحاجة إلى تعريف معنى التكافؤ، واختيار المعايير الصحيحة، وفحص الحالات الحدّية، وتحديد ما إذا كانت الانحرافات مهمة علميًا.

عنق الزجاجة يتحول من البرمجة إلى المراجعة
قد يكون هذا هو الاستنتاج الأهم في التقرير. إذا واصلت وكلاء البرمجة التحسن، فقد لا يعود الوقت الخام للتنفيذ هو المورد الأندر في برمجيات الأبحاث. قد يصبح عنق الزجاجة الحقيقي هو التحقق الخبير.
في هذا العالم، لا تسلّم المختبرات البرمجيات إلى وكيل ثم تقبل النتيجة. بدلًا من ذلك، تشرف على سير عمل ينتج فيه النموذج تطبيقات مرشحة بسرعة عالية بينما يقضي خبراء المجال وقتهم في فحص المخرجات، وإعادة إنتاج السلوك السابق، والتأكد من أن أي افتراضات علمية لم تُهرَّب إلى داخل إعادة الكتابة. يتغير سير العمل، لكن الحاجة إلى الإشراف الخبير لا تختفي.
وهذا مهم بشكل خاص في بيئات البحث لأن صحة الشيفرة ليست إلا طبقة واحدة من المشكلة. فقد تكون إعادة الهيكلة نظيفة نحويًا وأسرع حسابيًا، ومع ذلك تبقى خاطئة علميًا إذا غيّرت السلوك العددي أو المعلمات الافتراضية أو الافتراضات الخفية. لذلك فإن تحذير التقرير من أن هذه الأنظمة لا تستطيع الحكم على صحة العلم ليس مجرد تنبيه. إنه شرط لاستخدامها بمسؤولية.
ما الذي قد يعنيه ذلك للبنية التحتية العلمية
إذا عممت النتائج، فقد تصبح وكلاء البرمجة أدوات بنية تحتية قيّمة للأوساط الأكاديمية. تعتمد الحقول العلمية كثيرًا على برمجيات مهمة جدًا بحيث لا يمكن تجاهلها، لكنها ممولة بشكل غير كافٍ بحيث لا يمكن تحديثها يدويًا. وقد تكون أنظمة الذكاء الاصطناعي فعالة بشكل خاص في فجوة الصيانة تلك، حيث لا تكون المشكلة اختراع علم جديد، بل تحويل الشيفرة القديمة الهشة إلى صيغ أسهل للتشغيل والمراجعة والتوسعة.
الوعد كبير: عمليات نقل أسرع، أداء أفضل، سلاسل أدوات مُنعشة، وقواعد شيفرة مهجورة أقل. أما المقابل فهو أن الثقة لا تزال يجب أن تُبنى بالطريقة البطيئة. لا يمكن قبول البرمجيات العلمية لأنها تبدو جيدة أو لأن ترجمتها تنجح بلا أخطاء. يجب اختبارها على أحمال عمل حقيقية، والحكم عليها من قبل أشخاص يفهمون العلم كما يفهمون الشيفرة.
وهذا يجعل التقرير الميداني أقل قصة عن الاكتشاف الآلي وأكثر عن تقسيم العمل. قد يتولى الذكاء الاصطناعي جزءًا أكبر من أعمال تحديث البرمجيات، بينما يظل الباحثون مسؤولين عن تحديد ما إذا كانت الأنظمة الناتجة تستحق أن تكون جزءًا من السجل العلمي.
هذه المقالة مبنية على تقرير The Decoder. اقرأ المقال الأصلي.
Originally published on the-decoder.com

