أعادت GitHub بناء runtime الذي يقف خلف GitHub Copilot CLI وتطبيق Copilot وCopilot SDK، بعدما كان يعتمد على TypeScript وNode.js ومحرك V8. النتيجة، وفقاً للمادة المنشورة على مدونة GitHub، أكثر من 800,000 سطر Rust مخصص للإنتاج، أُنجز معظمها بمساعدة وكلاء الذكاء الاصطناعي عبر 128 طلب سحب دُمجت تدريجياً في الفرع الرئيسي.
يقول الكاتب إن العمل اكتمل خلال بضعة أشهر وبمشاركة مطور واحد أساساً، بالتوازي مع استمرار بقية الفريق في تطوير قدرات runtime وتوسيع نطاق استخدامه. وتذكر GitHub أن الأداء تحسن «بمقادير كبيرة» بعد الانتقال، من دون تقديم أرقام تفصيلية في الجزء المتاح من المادة لقياس هذا التحسن.
المشكلة لم تكن في واجهة سطر الأوامر وحدها
لا يقتصر Copilot runtime على تشغيل CLI. فهو طبقة مشتركة تستخدمها إصدارات ومنتجات متعددة، تشمل GitHub Copilot CLI وتطبيق Copilot وCopilot SDK، إضافة إلى VS Code وVisual Studio وCloud Agent وCopilot Code Review وCopilot Cowork وCopilot Studio وتطبيقات Excel وOutlook وPowerPoint وWord.
في التصميم السابق، كان runtime وواجهة CLI متداخلين إلى حد كبير. وعندما احتاجت المنتجات إلى وصول برمجي، بُني SDK عملياً فوق CLI، مع تشغيل عملية Node.js منفصلة والتواصل معها عبر JSON-RPC. كان هذا النهج سريعاً ومرناً، لكنه فرض كلفة تشغيلية على كل تطبيق مستهلك.
كان إنشاء CopilotClient جديد يعني تشغيل عملية إضافية تستضيف Node.js وV8، وتحليل كود JavaScript الناتج من TypeScript، وتحمل الذاكرة المرتبطة بالمحرك. كما كانت حوادث التعطل في Node.js قادرة على إنهاء الجلسة، بينما احتاجت التطبيقات إلى مراقبة عمليتين على الأقل. ووفق المادة، تحملت حزم SDK المكتوبة بـ C# وTypeScript وPython وRust وGo وJava نحو 100 ميغابايت من مجموعة الذاكرة العاملة كحد أدنى للruntime الإضافي، حتى عندما لم تكن تحتاج إلى Node.js لشيء آخر.
لماذا اختيرت Rust؟
حددت GitHub أهدافاً واضحة للطبقة الجديدة: فصل runtime عن واجهة TUI، تقليل الاعتماديات والكلفة التشغيلية، تمكين الدمج داخل العملية نفسها، وتحسين قابلية التوسع والاعتمادية. كما احتاجت إلى واجهة C ABI تسمح باستخدام runtime من إصدارات SDK الستة عبر آليات FFI المختلفة.
تقول المادة إن Rust ساعدت على تحقيق هذه المتطلبات، إلى جانب توفير سلسلة أدوات تدعم وضعاً أمنياً أحدث وتقليلاً لمخاطر سلسلة التوريد ودعماً أكبر للشفرة الصحيحة بحكم التصميم. لكنها تؤكد في الوقت نفسه أن التجربة ليست توصية بتحويل كل مشروع TypeScript كبير إلى Rust؛ فالاختيار نتج عن متطلبات محددة تتعلق ببدء التشغيل والذاكرة والتضمين وقابلية التنبؤ باستهلاك الموارد.
استبدال تدريجي بدلاً من إعادة كتابة شاملة
لم تنفذ GitHub المشروع عبر فرع طويل العمر أو عملية تحويل واحدة في نهاية الطريق. اختارت أسلوباً داخل الفرع الرئيسي، يُستبدل فيه كل مكون TypeScript بمكون Rust على حدة. يضيف كل طلب سحب طبقة ربط رفيعة تستدعي Rust ويحذف التنفيذ القديم في التغيير نفسه، بحيث يبقى الفرع قابلاً للشحن وتُختبر الشفرة الجديدة مباشرة داخل النظام.
- استمر العمل المعتاد لبقية المطورين من دون إيقاف المشروع.
- أصبح كل تغيير أصغر وأسهل للمراجعة من إعادة كتابة شاملة.
- شُغلت اختبارات النهاية إلى النهاية الخاصة بـ CLI وSDK مع كل خطوة.
- كُشفت الانحدارات وأُصلحت أثناء الترحيل بدلاً من تأجيلها إلى لحظة التحويل النهائي.
رفضت GitHub أيضاً إبقاء نسختين متوازيتين من كل مكون لفترة طويلة. فالمستودع كان يشهد مئات طلبات السحب أسبوعياً، وكان الحفاظ على تنفيذين بلغتين ومجموعتي اعتماديات سيزيد التعقيد. وتصبح المقارنة بين نسختين أكثر صعوبة في المكونات التي تدير حالة قابلة للتغيير، مثل تنسيق الجلسات، لأنها تتعامل مع الاستدعاءات الراجعة وتتصل بأجزاء واسعة من النظام.
ما الذي تكشفه الأرقام؟
بدأ التقدير الأولي في مايو 2026 عند نحو 130,000 سطر TypeScript، لكنه لم يعكس حجم العمل الفعلي. فالمكونات التي كانت محسوبة ضمن طبقة TUI نُقلت لاحقاً إلى runtime، كما استمر وصول كود TypeScript جديد بالتزامن مع الترحيل. لذلك مرّ نحو 430,000 سطر TypeScript فعلياً بعملية النقل.
خلال الفترة نفسها دخل إلى المشروع نحو 300,000 سطر إنتاجي من TypeScript وأزيل نحو 430,000، بينما دخل نحو 1,200,000 سطر Rust وأزيل نحو 365,000. وتوضح هذه الأرقام أن ثبات حجم TypeScript الظاهر في المستودع لم يكن يعني غياب التقدم، بل كان يخفي حركة كبيرة من الإضافة والحذف وإعادة توزيع المسؤوليات.
لماذا يهم هذا الخبر؟
القيمة العملية للتجربة لا تكمن في استخدام Rust وحده، بل في طريقة إدارة إعادة كتابة طبقة أساسية يتشاركها عدد كبير من المنتجات. فالاستبدال الذري لكل مكون، مع إبقاء الفرع قابلاً للشحن وتشغيل الاختبارات باستمرار، يقلل مخاطر «التحويل الكبير» ويجعل التراجع أو تحديد موضع الخلل أكثر وضوحاً.
في المقابل، لا تثبت المادة أن هذا الأسلوب يناسب كل مؤسسة أو أن وكلاء الذكاء الاصطناعي قادرون وحدهم على ضمان جودة إعادة كتابة بهذا الحجم. كما أن الجزء المتاح لا يقدم قياسات منشورة للاستهلاك قبل وبعد، ولا يوضح التكلفة البشرية التفصيلية للمراجعة أو الاختبارات أو معالجة الانحدارات. لذلك يبقى الدرس الأوضح متعلقاً بالهندسة التدريجية وفصل الطبقات، لا باعتبار Rust أو الوكلاء حلاً عاماً لكل عمليات الترحيل.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.