دمج وكيل الذكاء الاصطناعي Devin من Cognition في منصة MongoDB: تسريع عمليات الترحيل بمعدل 4 إلى 5 أضعاف

قامت Cognition وMongoDB بربط الوكيل البرمجي الذكي Devin بمنصة Application Modernization Platform (AMP)، وهي أداة تابعة لـ MongoDB مخصصة لترحيل التطبيقات القديمة إلى سحابة Atlas. أُطلق على المنتج اسم Devin for MongoDB Modernizations، وهو متاح حاليًا لعملاء الشركتين. وفي الاختبارات المشتركة المبكرة، تقلصت المهام التي كانت تستغرق من خمس إلى ست ساعات لتصل إلى ما يزيد قليلًا عن ساعة واحدة، ما يعني تنفيذها بسرعة تفوق المعدل المعتاد بنحو 4 إلى 5 أضعاف. وتقدم الشركتان وعدًا طموحًا: ترحيل تطبيقات تراكمت على مدى عقود في غضون أشهر بدلًا من سنوات.

أين تتعثر عمليات الترحيل في الواقع؟

كانت الصياغة في الإعلان كاشفة بوضوح: نادرًا ما تتعثر عمليات الترحيل إلى MongoDB بسبب قاعدة البيانات نفسها. المشكلة الحقيقية تكمن في «التوصيلات البرمجية» المعقدة المحيطة بالأكواد القديمة؛ أي آلاف الاستعلامات، والإجراءات المخزنة (stored procedures)، وطبقات الوصول إلى البيانات التي تشابكت مع منطق الأعمال عبر السنين. ولا تستطيع البرمجيات النصية التلقائية البسيطة (scripts) تفكيك ذلك، إذ يتطلب الأمر فهم الغاية من كتابة كل استعلام بهذه الطريقة المحددة وتحديد ما قد يتعطل عند استبداله.

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

كيف يتقاسم Devin وAMP المهام؟

تعتمد المعمارية على توزيع المسؤوليات بين مكون غير حتمي (non-deterministic) وآخر حتمي (deterministic). في مسألة ترحيل البيانات، يُعد خطر حدوث الهلوسة أمرًا غير مقبول بالمرة؛ لذا يتولى نقل وتدقيق كل سجل داخل MongoDB أدوات AMP المجربة. أما الكود البرمجي الذي يتطلب مرونة، فقد أُوكل إلى الوكيل. يتصل Devin مباشرة بأدوات AMP ويدير العملية من البداية إلى النهاية بتنسيق كامل، ليرى العميل عملية ترحيل موحدة ومتسقة، بدلًا من مجموعة نصوص برمجية وتسليم يدوي مشتت بين الفرق.

أبرز النقاط الواردة في الإعلان:

• دور Devin: التخطيط وإعادة كتابة منطق الأعمال وطبقات الوصول إلى البيانات.
• دور AMP: النقل الحتمي للسجلات والتحقق من صحتها داخل MongoDB Atlas.
• ما يتبقى للبشر: تصميم نموذج البيانات المستهدف وتحديد تسلسل إجراءات التحويل النهائي (cutover).
• نتائج الاختبارات الأولية: تقليص مدة المهمة من 5–6 ساعات إلى ما يزيد قليلًا عن ساعة واحدة.
• التوفر: متاح فورًا لعملاء MongoDB وCognition، مع نشر الوثائق الرسمية لربط Devin بـ MongoDB.

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

ما نعرفه عن النتائج وما لم يُكشف عنه

المعيار الوحيد الذي نُشر حتى الآن يستند إلى «اختبارات مشتركة أولية». ولم تُكشف المنهجية المتبعة: إذ لا نعلم ما الذي عُدّ «مهمة»، وما طبيعة قواعد الأكواد التي أُجري الاختبار عليها، وكيف حُسب الوقت المخصص لمراجعة المهندسين البشريين. كما نُشرت المادة عبر مدونة منصة Windsurf التابعة لـ Cognition، ما يعني أنها مادة تسويقية للجهة المطورة وليست تقييمًا مستقلًا.

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

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

كيف تطبق ذلك عمليًا؟

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

حدد مسبقًا نموذج البيانات المستهدف وخطة التحويل النهائي (cutover): فهذه القرارات تقع على عاتق فريقك بالكامل وتحدد مدى قدرة الوكيل على تسريع الإنجاز فعليًا. وافحص بدقة آلية تحقق AMP من السجلات؛ فمدى شمولية هذه الفحوصات هو ما يحدد الثقة في النتيجة النهائية أكثر من أي أرقام ترويجية في بيان الإعلان.